Audit Smart Contracts for Security Vulnerabilities

This is a smart-contract security-audit skill for Solidity and EVM-compatible contracts, covering six critical vulnerability categories - reentrancy, integer overflow and underflow, access-control flaws, front-running and MEV, flash-loan attacks via price-oracle manipulation, and denial-of-service via gas limits or unbounded loops - plus gas-optimization patterns such as using uint256 over smaller uints, packing struct variables, preferring external over public, caching array lengths in loops, and using immutable/constant appropriately. Its canonical reentrancy example contrasts a vulnerable withdraw function against the Checks-Effects-Interactions fix:

// RED FLAG: Reentrancy vulnerability
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] -= amount; // State update after external call
}

// SECURE: Checks-Effects-Interactions pattern
function withdraw(uint amount) external nonReentrant {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount; // State update first
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
}

Use this skill when auditing a Solidity contract for security vulnerabilities and gas efficiency, especially DeFi-specific patterns: oracle price manipulation (recommending multiple oracle sources with deviation checks over a single price feed), unsafe external calls (whitelisting call targets and checking return values), liquidity-pool operations (slippage protection, minimum liquidity, front-running-resistant optimal-amount calculation), and governance timelocks (a minimum delay of 2 days in the example before a queued critical change executes). It also specifies invariant-testing patterns for ERC20 tokens - total supply must equal the sum of holder balances, and no balance may go negative. It is not a general Solidity-development skill - it's scoped to security review and hardening of existing contract logic, so it isn't the right tool for initial contract design or business-logic specification.

Input is Solidity contract code - functions, state variables, contract architecture including inheritance, proxy-upgrade mechanisms, and multi-sig integrations; output is an audit report with findings classified by severity - Critical (funds stolen or permanently locked), High (significant economic impact), Medium (limited or temporary impact), Low (minor issues), and Informational (code quality and optimization) - each following a five-part format: issue description, impact assessment, proof-of-concept code, remediation code changes, and prevention guidance, always tied to specific line numbers and exact code snippets.

Applies to Solidity contracts on EVM-compatible chains, referencing SafeMath or Solidity 0.8+'s built-in overflow protection, nonReentrant guard patterns, and invariant-testing assertions (assertEq, assertGe) consistent with a Foundry-style testing setup.

Smart-contract developers and security auditors reviewing Solidity or DeFi contracts before deployment, who need vulnerability categories, before/after code patterns, and a structured, severity-classified audit report format rather than an ad hoc code review.