[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6E5SWCS3ZEX53VJSVKRFSPA":3,"skill-same:01M6E5SWCS3ZEX53VJSVKRFSPA":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6E5SWCS3ZEX53VJSVKRFSPA","solidity-audit",null,"Security audit and code review checklist. Covers 30+ vulnerability types with real-world exploit cases (2021-2026) and EVMbench Code4rena patterns. Use when conducting security audits, code reviews, or pre-deployment security assessments.","ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",66,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002F0xlayerghost\u002Fsolidity-agent-kit\u002Fsolidity-audit\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"solidity","solidity audit","audit","deployment","code","review checklist","security","code review checklist","code review","security audit","vulnerability","use","exploit","checklist","patterns","world","review","2026-11-10 10:12:30",false,"---\nname: solidity-audit\ndescription: \"Security audit and code review checklist. Covers 30+ vulnerability types with real-world exploit cases (2021-2026) and EVMbench Code4rena patterns. Use when conducting security audits, code reviews, or pre-deployment security assessments.\"\n---\n\n# Solidity Security Audit Checklist\n\n## Language Rule\n\n- **Always respond in the same language the user is using.** If the user asks in Chinese, respond in Chinese. If in English, respond in English.\n\n> **Usage**: This skill is for security audits and code reviews. It is NOT auto-invoked — call `\u002Fsolidity-audit` when reviewing contracts for vulnerabilities.\n\n## Contract-Level Vulnerabilities\n\n### 1. Reentrancy\n\n| Variant | Description | Check |\n|---------|-------------|-------|\n| Same-function | Attacker re-enters the same function via fallback\u002Freceive | All external calls after state updates (CEI pattern)? |\n| Cross-function | Attacker re-enters a different function sharing state | All functions touching shared state protected by `nonReentrant`? |\n| Cross-contract | Attacker re-enters through a different contract that reads stale state | External contracts cannot read intermediate state? |\n| Read-only | View function returns stale data during mid-execution state | No critical view functions used as oracle during state transitions? |\n\n**Case**: [GMX v1 (Jul 2025, $42M)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-gmx-hack-july-2025) — reentrancy in GLP pool on Arbitrum, attacker looped withdrawals to drain liquidity.\n\n### 2. Access Control\n\n| Check | Detail |\n|-------|--------|\n| Missing modifier | Every state-changing function has explicit access control? |\n| Modifier logic | Modifier actually reverts on failure (not just empty check)? |\n| State flag | Access-once patterns properly update storage after each user? |\n| Admin privilege scope | Owner powers are minimal and time-limited? |\n\n**Case**: [Bybit (Feb 2025, $1.4B)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-bybit-hack-february-2025) — Safe{Wallet} UI injected with malicious JS, hijacked signing process. Not a contract flaw, but access control at the infrastructure layer.\n\n### 3. Input Validation\n\n| Check | Detail |\n|-------|--------|\n| Zero address | All address params reject `address(0)`? |\n| Zero amount | Fund transfers reject zero amounts? |\n| Array bounds | Paired arrays validated for matching length? |\n| Arbitrary call | No unvalidated `address.call(data)` where attacker controls `data`? |\n| Numeric bounds | Inputs bounded to prevent dust attacks or gas griefing? |\n\n### 4. Flash Loan Attacks\n\n| Variant | Mechanism | Defense |\n|---------|-----------|---------|\n| Price manipulation | Flash-borrow → swap to move price → exploit price-dependent logic → repay | TWAP oracle with min-liquidity check |\n| Governance | Flash-borrow governance tokens → vote → repay in same block | Snapshot voting + minimum holding period + timelock ≥ 48h |\n| Liquidation | Flash-borrow → manipulate collateral value → trigger liquidation | Multi-oracle price verification + circuit breaker |\n| Combo (rounding) | Flash-borrow → manipulate pool → micro-withdrawals exploit rounding → repay | Minimum withdrawal amount + virtual shares |\n\n**Cases**:\n- [Cream Finance (Oct 2021, $130M)](https:\u002F\u002Frekt.news\u002Fcream-rekt-2\u002F) — flash loan + yUSD oracle manipulation + missing reentrancy guard\n- [Abracadabra (Mar 2025, $13M)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-abracadabra-money-hack-march-2025) — state tracking error in cauldron, self-liquidation + bad loan\n- [Bunni (Sep 2025, $8.4M)](https:\u002F\u002Fwww.theblock.co\u002Fpost\u002F369564\u002Fbunni-smart-contract-rounding-error) — flash loan + pool price manipulation + rounding error micro-withdrawals\n\n### 5. Oracle & Price\n\n| Check | Detail |\n|-------|--------|\n| Single oracle dependency | Using multiple independent price sources? |\n| Stale price | Checking `updatedAt` timestamp and rejecting old data? |\n| Spot price usage | Never using raw AMM reserves for pricing? |\n| Minimum liquidity | Oracle reverts if pool reserves below threshold? |\n| Price deviation | Circuit breaker if price moves beyond threshold vs last known? |\n| Chainlink round completeness | Checking `answeredInRound >= roundId`? |\n\n**Case**: [Cream Finance (Oct 2021, $130M)](https:\u002F\u002Frekt.news\u002Fcream-rekt-2\u002F) — attacker manipulated yUSD vault price by reducing supply, then used inflated collateral to drain all lending pools.\n\n### 6. Numerical Issues\n\n| Type | Description | Defense |\n|------|-------------|---------|\n| Primitive overflow | `uint256 a = uint8(b) + 1` — reverts if b=255 on Solidity ≥0.8 | Use consistent types, avoid implicit narrowing |\n| Truncation | `int8(int256Value)` — silently overflows even on ≥0.8 | Use `SafeCast` library for all type narrowing |\n| Rounding \u002F precision loss | `usdcAmount \u002F 1e12` always rounds to 0 for small amounts | Multiply before divide; check for zero result |\n| Division before multiplication | `(a \u002F b) * c` loses precision | Always `(a * c) \u002F b` |\n\n**Case**: [Bunni (Sep 2025, $8.4M)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-bunni-hack-september-2025) — rounding errors in micro-withdrawals exploited via flash loan.\n\n### 7. Signature Issues\n\n| Type | Description | Defense |\n|------|-------------|---------|\n| ecrecover returns address(0) | Invalid sig returns `address(0)`, not revert | Always check `recovered != address(0)` |\n| Replay attack | Same signature reused across txs\u002Fchains | Include `chainId` + `nonce` + `deadline` in signed data |\n| Signature malleability | ECDSA has two valid (s, v) pairs per signature | Use OpenZeppelin `ECDSA.recover` (enforces low-s) |\n| Empty loop bypass | Signature verification in for-loop, attacker sends empty array | Check `signatures.length >= requiredCount` before loop |\n| Missing msg.sender binding | Proof\u002Fsignature not bound to caller | Always include `msg.sender` in signed\u002Fproven data |\n\n### 8. ERC20 Compatibility\n\n| Issue | Description | Defense |\n|-------|-------------|---------|\n| Fee-on-transfer | `transfer(100)` may deliver \u003C100 tokens | Check balance before\u002Fafter, use actual received amount |\n| Rebase tokens | Token balances change without transfers | Never cache external balances; always read live |\n| No bool return | Some tokens (USDT) don't return bool on transfer | Use `SafeERC20.safeTransfer` |\n| ERC777 hooks | Transfer hooks can trigger reentrancy | Use `ReentrancyGuard` on all token-receiving functions |\n| Zero-amount transfer | `transferFrom(A, B, 0)` — address poisoning | Reject zero-amount transfers |\n| Approval race | Changing allowance from N to M allows spending N+M | Use `safeIncreaseAllowance` \u002F `safeDecreaseAllowance` |\n\n### 9. MEV \u002F Front-Running\n\n| Type | Description | Defense |\n|------|-------------|---------|\n| Sandwich attack | Attacker front-runs buy + back-runs sell around victim | Slippage protection + deadline parameter |\n| ERC4626 inflation | First depositor donates to inflate share price, rounding out later depositors | Minimum first deposit or virtual shares (ERC4626 with offset) |\n| Approval front-run | Attacker spends old allowance before new allowance tx confirms | Use `increaseAllowance` not `approve` |\n| Unrestricted withdrawal | Attacker monitors mempool for withdraw tx, front-runs with own | Require commit-reveal or auth binding |\n\n### 10. Storage & Low-Level\n\n| Issue | Description |\n|-------|-------------|\n| Storage pointer | `Foo storage foo = arr[0]; foo = arr[1];` — does NOT update arr[0] |\n| Nested delete | `delete structWithMapping` — inner mapping data persists |\n| Private variables | All contract storage is publicly readable via `eth_getStorageAt` |\n| Unsafe delegatecall | Delegatecall to untrusted contract can `selfdestruct` the caller |\n| Proxy storage collision | Upgrade changes parent order → variables overwrite each other (use storage gaps) |\n| msg.value in loop | msg.value doesn't decrease in loop — enables double-spend |\n\n### 11. Contract Detection Bypass\n\n| Method | How it works |\n|--------|-------------|\n| Constructor call | Attack from constructor — `extcodesize == 0` during deployment |\n| CREATE2 pre-compute | Pre-calculate contract address, use as EOA before deploying |\n\n### 12. Proxy & Upgrade Vulnerabilities\n\n> Source: [EVMbench Paper §4.2, Appendix H](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf) \u002F [Code4rena 2024-07-basin H-01](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-07-basin)\n\n| Check | Detail |\n|-------|--------|\n| `_authorizeUpgrade` access control | UUPS `_authorizeUpgrade` must have `onlyOwner` modifier? |\n| Permissionless factory\u002Fregistry | Can attacker use permissionless factory (e.g. Aquifer `boreWell`) to satisfy upgrade checks? |\n| `upgradeTo` modifier | Overridden `upgradeTo`\u002F`upgradeToAndCall` retains `onlyProxy` modifier? |\n| Initializer protection | `initializer` modifier prevents re-initialization? Implementation calls `_disableInitializers()`? |\n| Storage layout compatibility | Upgrade-safe storage layout (storage gaps or ERC-7201 namespace)? |\n\n**Case**: [Code4rena 2024-07-basin H-01](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-07-basin) (via [EVMbench Paper Fig.12, p.19](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)) — `_authorizeUpgrade` only checked delegatecall and Aquifer registration but lacked `onlyOwner`, allowing anyone to upgrade a Well proxy to a malicious implementation and drain funds. Oracle patch: add a single `onlyOwner` modifier.\n\n### 13. Trust Boundary & Protocol Composability\n\n> Source: [EVMbench Paper §4.2.1, Fig.6](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf) \u002F Code4rena [2024-04-noya H-08](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-04-noya), [2024-07-benddao](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-07-benddao)\n\n| Check | Detail |\n|-------|--------|\n| Cross-vault trust isolation | Registry\u002FRouter relay calls verify vault-level authorization? |\n| Trusted sender abuse | Functions like `sendTokensToTrustedAddress` verify source vault, not just router identity? |\n| Flash loan + routing combo | Can attacker use flash loan callback to make router impersonate arbitrary vault? |\n| Collateral ownership verification | Liquidation\u002Fstaking operations verify actual NFT\u002Fcollateral owner? |\n| Cross-contract state dependency | Multi-contract interactions free from intermediate state dependencies? |\n\n**Cases**:\n- [Code4rena 2024-04-noya H-08](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-04-noya) (via [EVMbench Paper §4.2.1, Fig.6, p.8-9](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)) — PositionRegistry + BalancerFlashLoan pipeline lacked vault-level auth; keeper used flash loan to make router impersonate any vault, draining cross-vault funds via `sendTokensToTrustedAddress`\n- [Code4rena 2024-07-benddao](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-07-benddao) (via [EVMbench Paper Fig.13, p.19](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)) — `isolateLiquidate` did not verify NFT ownership, allowing attacker to pass others' tokenIds for liquidation\n\n### 14. State Ordering & Counter Manipulation\n\n> Source: [EVMbench Paper Appendix H.1, Fig.19-21](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf) \u002F [Code4rena 2024-08-phi H-06](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-08-phi)\n\n| Check | Detail |\n|-------|--------|\n| Counter\u002FID increment order | `credIdCounter++` or similar ID increments happen before external calls? |\n| Auto-buy in create | `create()` functions with auto `buy()` calls execute only after ID\u002Fstate fully initialized? |\n| Refund timing | ETH refund (excess) happens after all state updates complete? |\n| Bonding curve metadata overwrite | Can attacker reenter to modify bonding curve\u002Fpricing params — buy cheap, switch to expensive curve, sell high? |\n\n**Case**: [Code4rena 2024-08-phi H-06](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-08-phi) (via [EVMbench Paper Appendix H.1, p.25-28](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)) — `_createCredInternal` called `buyShareCred` before incrementing `credIdCounter`; `_handleTrade` refunded excess ETH before updating `lastTradeTimestamp`. Attacker reentered to accumulate shares on cheap curve, overwrote metadata to expensive curve, sold to drain all contract ETH. Fix: add `nonReentrant` to `buyShareCred`\u002F`sellShareCred`.\n\n## Infrastructure-Level Vulnerabilities\n\n### 15. Frontend \u002F UI Injection\n\nAttackers inject malicious code into the dApp frontend or signing interface.\n\n**Defense**: Verify transaction calldata matches expected function selector and parameters before signing. Use hardware wallet with on-device transaction preview. Audit all frontend dependencies regularly.\n\n**Case**: [Bybit (Feb 2025, $1.4B)](https:\u002F\u002Fwww.nccgroup.com\u002Fresearch-blog\u002Fin-depth-technical-analysis-of-the-bybit-hack\u002F) — malicious JavaScript injected into Safe{Wallet} UI, tampered with transaction data during signing.\n\n### 16. Private Key & Social Engineering\n\nCompromised keys remain the #1 loss source in 2025-2026.\n\n**Defense**: Store keys in HSM or hardware wallet. Use multisig (≥ 3\u002F5) for all treasury and admin operations. Never share seed phrases with any \"support\" contact. Conduct regular social engineering awareness training.\n\n**Case**: [Step Finance (Jan 2026, $30M)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-step-finance-hack-january-2026) — treasury wallet private keys compromised via device breach.\n\n### 17. Cross-Chain Bridge\n\n| Check | Detail |\n|-------|--------|\n| Inherited code | Audit all bridge logic inherited from third-party frameworks |\n| Message verification | Cross-chain messages validated with proper signatures and replay protection? |\n| Liquidity isolation | Bridge funds separated from protocol treasury? |\n\n**Case**: [SagaEVM (Jan 2026, $7M)](https:\u002F\u002Fwww.theblock.co\u002Fpost\u002F386638\u002Fsagaevm-suffers-exploit) — inherited vulnerable EVM precompile bridge logic from Ethermint.\n\n### 18. Legacy \u002F Deprecated Contracts\n\nOld contracts with known bugs remain callable on-chain forever.\n\n**Defense**: Permanently `pause` or migrate funds from deprecated contracts. Monitor old contract addresses for unexpected activity. Remove mint\u002Fadmin functions before deprecation.\n\n**Case**: [Truebit (Jan 2026, $26.4M)](https:\u002F\u002Fwww.coindesk.com\u002Fmarkets\u002F2026\u002F01\u002F09\u002Ftruebit-token-tru-crashes-99-9-after-usd26-6m-exploit-drains-8-535-eth) — Solidity 0.6.10 contract lacked overflow protection, attacker minted tokens at near-zero cost.\n\n## Automated Analysis with Slither MCP (if available)\n\nWhen `slither` MCP is configured, run automated analysis BEFORE the manual checklist below:\n\n### Recommended Audit Flow\n\n```\nStep 1: slither MCP automated scan\n        → get_detector_results(path, impact=\"High\")\n        → get_detector_results(path, impact=\"Medium\")\nStep 2: Review Slither findings — triage true positives vs false positives\nStep 3: Manual checklist below — catch what Slither misses (business logic, economic attacks)\nStep 4: Cross-reference — Slither + manual findings combined into final report\n```\n\n### Slither MCP Tools\n\n| Tool | Usage | Complements |\n|---|---|---|\n| `get_contract_metadata` | Extract functions, inheritance, flags | Manual access control review |\n| `get_function_source` | Get exact source code with line numbers | Faster than grep for locating code |\n| `find_implementations` | Find all implementations of a function signature | Cross-contract reentrancy analysis |\n| `get_detector_results` | Run 90+ security detectors, filter by impact\u002Fconfidence | Automated version of manual checklist |\n| `get_detector_metadata` | List available detectors with descriptions | Understanding what's being checked |\n\n### What Slither Catches vs What It Misses\n\n| Slither Catches Well | Manual Review Still Needed |\n|---|---|\n| Reentrancy patterns | Business logic flaws |\n| Unprotected functions | Economic attack vectors (flash loan combos) |\n| Unused state variables | Cross-protocol composability risks |\n| Shadowing issues | Oracle manipulation scenarios |\n| Incorrect ERC20 interface | Trust boundary architecture issues |\n| Dead code | MEV\u002Ffront-running specific to business logic |\n\n**Key Principle**: Slither provides ground truth via static analysis — reduces false negatives on known vulnerability patterns. But it cannot reason about protocol-level economic attacks — that's where the manual checklist below is essential.\n\n**Graceful degradation**: If slither MCP is not configured, skip this section and proceed directly to the manual checklist. All checklist items remain valid and self-contained.\n\n## Audit Execution Checklist\n\nWhen conducting a security audit, check each item:\n\n**Reentrancy:**\n- [ ] All functions with external calls use `nonReentrant`\n- [ ] CEI pattern followed — no state reads after external calls\n- [ ] View functions not used as oracle during state transitions\n\n**Access Control:**\n- [ ] Every state-changing function has explicit access modifier\n- [ ] Modifiers actually revert (not silently pass)\n- [ ] Admin privileges are minimal and documented\n\n**Input & Logic:**\n- [ ] No unvalidated arbitrary `call` \u002F `delegatecall`\n- [ ] No `tx.origin` for authentication\n- [ ] Array lengths validated for paired inputs\n- [ ] No division-before-multiplication precision loss\n\n**Token Handling:**\n- [ ] All ERC20 ops use `SafeERC20`\n- [ ] Fee-on-transfer tokens handled (balance diff check)\n- [ ] Rebase token balances not cached\n- [ ] Zero-amount transfers rejected\n\n**Price & Oracle:**\n- [ ] No raw spot price usage\n- [ ] Stale price check (`updatedAt` \u002F `answeredInRound`)\n- [ ] Minimum liquidity threshold enforced\n- [ ] Price deviation circuit breaker\n\n**Signature & Crypto:**\n- [ ] `ecrecover` result checked against `address(0)`\n- [ ] Signed data includes `chainId`, `nonce`, `msg.sender`, `deadline`\n- [ ] Using OZ `ECDSA` (low-s enforced)\n- [ ] MerkleProof leaves bound to `msg.sender`\n\n**Flash Loan Defense:**\n- [ ] Governance: snapshot voting + holding period + timelock\n- [ ] Price: TWAP or multi-oracle, not single-block spot\n- [ ] Vault: minimum first deposit or virtual shares (ERC4626)\n\n**Proxy & Upgrade ([EVMbench](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)):**\n- [ ] UUPS `_authorizeUpgrade` has `onlyOwner` — [EVMbench\u002Fbasin H-01]\n- [ ] `upgradeTo`\u002F`upgradeToAndCall` retains `onlyProxy` — [EVMbench\u002Fbasin H-01]\n- [ ] Implementation constructor calls `_disableInitializers()` — [EVMbench\u002Fbasin H-01]\n- [ ] Storage layout upgrade-compatible (storage gaps or ERC-7201) — [EVMbench\u002Fbasin H-01]\n\n**Trust Boundary & Composability ([EVMbench](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)):**\n- [ ] Router\u002FRegistry relay calls verify source vault\u002Fcontract authorization — [EVMbench\u002Fnoya H-08]\n- [ ] Liquidation operations verify actual collateral ownership — [EVMbench\u002Fbenddao]\n- [ ] Flash loan callback paths cannot be abused to penetrate trust boundaries — [EVMbench\u002Fnoya H-08]\n- [ ] No intermediate state dependencies in multi-contract interactions — [EVMbench\u002Fnoya H-08]\n\n**State Ordering ([EVMbench](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)):**\n- [ ] Counter\u002FID increments complete before external calls — [EVMbench\u002Fphi H-06]\n- [ ] ETH refunds execute after all state updates — [EVMbench\u002Fphi H-06]\n- [ ] Auto-operations in create functions (auto-buy etc.) execute after full initialization — [EVMbench\u002Fphi H-06]\n\n**Infrastructure:**\n- [ ] Third-party dependencies audited (bridge code, inherited contracts)\n- [ ] No deprecated contracts still callable with admin\u002Fmint functions\n- [ ] Multisig on all treasury and admin wallets\n- [ ] Frontend transaction verification (calldata matches expected)\n\n## AI Agent Audit Methodology\n\n> Source: [EVMbench (OpenAI\u002FParadigm, Feb 2026)](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf) — evaluated AI agents on 120 high-severity vulnerabilities from 40 Code4rena audit repositories across Detect\u002FPatch\u002FExploit modes.\n\n### Audit Strategy\n\n1. **Coverage over depth**: scan ALL in-scope files; do not stop after finding the first vulnerability [EVMbench §5, p.10]\n2. **Three-phase audit**: Detect (identify vulnerabilities) -> Patch (write fix) -> Exploit (build PoC) [EVMbench §3.2, p.5]\n3. **Incremental output**: write findings continuously during audit to preserve progress [EVMbench Appendix G, Fig.18, p.24]\n4. **Systematic category scan**: check by vulnerability class (reentrancy, access control, numerical, oracle...) rather than intuition [EVMbench §3.1, p.4]\n5. **Verify fixes**: after patching, confirm original tests still pass AND exploit is no longer viable [EVMbench §3.2.2, p.5]\n\n### High-Frequency Vulnerability Patterns (Code4rena Data)\n\n> Source: EVMbench Table 4 (p.17) — 40 audit repositories\n\n- Missing access control (upgradeability, liquidation, admin functions) — basin H-01, munchables, benddao\n- Reentrancy + state ordering errors (refund before state update) — phi H-06, noya H-08\n- Flash loan trust boundary penetration (exploiting router\u002Fregistry trust propagation) — noya H-08\n- Signature replay \u002F front-running (checkpoint bypass, session signature replay) — sequence H-01, H-02\n- Numerical precision \u002F rounding (bonding curve, micro-withdrawals) — abracadabra H-02, size H-02\n\n### Key Findings\n\n> Source: EVMbench Paper §4.1 (p.7), Fig.7 (p.10), Fig.10 (p.18), Fig.11 (p.19)\n\n- With mechanism hints, Patch success rate jumps from ~40% to ~94% [Fig.7] — agents know how to fix but struggle to find vulnerabilities\n- Most vulnerabilities require ≤5 lines of code to fix [Fig.10, p.18]\n- Most exploits require only 1-3 transactions [Fig.11, p.19]\n- Agents whose finding count is closest to actual vulnerability count score highest (quality > quantity) [Fig.5, p.8]\n\n## 2021-2026 Incident Quick Reference\n\n| Date | Project | Loss | Attack Type | Root Cause | Source |\n|------|---------|------|-------------|------------|--------|\n| Oct 2021 | Cream Finance | $130M | Flash loan + oracle | yUSD vault price manipulation via supply reduction | [rekt.news](https:\u002F\u002Frekt.news\u002Fcream-rekt-2\u002F) |\n| Feb 2025 | Bybit | $1.4B | UI injection \u002F supply chain | Safe{Wallet} JS tampered via compromised dev machine | [NCC Group](https:\u002F\u002Fwww.nccgroup.com\u002Fresearch-blog\u002Fin-depth-technical-analysis-of-the-bybit-hack\u002F) |\n| Mar 2025 | Abracadabra | $13M | Logic flaw | State tracking error in cauldron liquidation | [Halborn](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-abracadabra-money-hack-march-2025) |\n| Jul 2025 | GMX v1 | $42M | Reentrancy | GLP pool cross-contract reentrancy on Arbitrum | [Halborn](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-gmx-hack-july-2025) |\n| Sep 2025 | Bunni | $8.4M | Flash loan + rounding | Rounding direction error in withdraw, 44 micro-withdrawals | [The Block](https:\u002F\u002Fwww.theblock.co\u002Fpost\u002F369564\u002Fbunni-smart-contract-rounding-error) |\n| Oct 2025 | Abracadabra #2 | $1.8M | Logic flaw | cook() validation flag reset, uncollateralized MIM borrow | [Halborn](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-abracadabra-hack-october-2025) |\n| Jan 2026 | Step Finance | $30M | Key compromise | Treasury wallet private keys stolen via device breach | [Halborn](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-step-finance-hack-january-2026) |\n| Jan 2026 | Truebit | $26.4M | Legacy contract | Solidity 0.6.10 integer overflow in mint pricing | [CoinDesk](https:\u002F\u002Fwww.coindesk.com\u002Fmarkets\u002F2026\u002F01\u002F09\u002Ftruebit-token-tru-crashes-99-9-after-usd26-6m-exploit-drains-8-535-eth) |\n| Jan 2026 | SagaEVM | $7M | Supply chain \u002F bridge | Inherited Ethermint precompile bridge vulnerability | [The Block](https:\u002F\u002Fwww.theblock.co\u002Fpost\u002F386638\u002Fsagaevm-suffers-exploit) |\n\n","# Solidity Security Audit Checklist\n\n## Language Rule\n\n- **Always respond in the same language the user is using.** If the user asks in Chinese, respond in Chinese. If in English, respond in English.\n\n> **Usage**: This skill is for security audits and code reviews. It is NOT auto-invoked — call `\u002Fsolidity-audit` when reviewing contracts for vulnerabilities.\n\n## Contract-Level Vulnerabilities\n\n### 1. Reentrancy\n\n| Variant | Description | Check |\n|---------|-------------|-------|\n| Same-function | Attacker re-enters the same function via fallback\u002Freceive | All external calls after state updates (CEI pattern)? |\n| Cross-function | Attacker re-enters a different function sharing state | All functions touching shared state protected by `nonReentrant`? |\n| Cross-contract | Attacker re-enters through a different contract that reads stale state | External contracts cannot read intermediate state? |\n| Read-only | View function returns stale data during mid-execution state | No critical view functions used as oracle during state transitions? |\n\n**Case**: [GMX v1 (Jul 2025, $42M)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-gmx-hack-july-2025) — reentrancy in GLP pool on Arbitrum, attacker looped withdrawals to drain liquidity.\n\n### 2. Access Control\n\n| Check | Detail |\n|-------|--------|\n| Missing modifier | Every state-changing function has explicit access control? |\n| Modifier logic | Modifier actually reverts on failure (not just empty check)? |\n| State flag | Access-once patterns properly update storage after each user? |\n| Admin privilege scope | Owner powers are minimal and time-limited? |\n\n**Case**: [Bybit (Feb 2025, $1.4B)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-bybit-hack-february-2025) — Safe{Wallet} UI injected with malicious JS, hijacked signing process. Not a contract flaw, but access control at the infrastructure layer.\n\n### 3. Input Validation\n\n| Check | Detail |\n|-------|--------|\n| Zero address | All address params reject `address(0)`? |\n| Zero amount | Fund transfers reject zero amounts? |\n| Array bounds | Paired arrays validated for matching length? |\n| Arbitrary call | No unvalidated `address.call(data)` where attacker controls `data`? |\n| Numeric bounds | Inputs bounded to prevent dust attacks or gas griefing? |\n\n### 4. Flash Loan Attacks\n\n| Variant | Mechanism | Defense |\n|---------|-----------|---------|\n| Price manipulation | Flash-borrow → swap to move price → exploit price-dependent logic → repay | TWAP oracle with min-liquidity check |\n| Governance | Flash-borrow governance tokens → vote → repay in same block | Snapshot voting + minimum holding period + timelock ≥ 48h |\n| Liquidation | Flash-borrow → manipulate collateral value → trigger liquidation | Multi-oracle price verification + circuit breaker |\n| Combo (rounding) | Flash-borrow → manipulate pool → micro-withdrawals exploit rounding → repay | Minimum withdrawal amount + virtual shares |\n\n**Cases**:\n- [Cream Finance (Oct 2021, $130M)](https:\u002F\u002Frekt.news\u002Fcream-rekt-2\u002F) — flash loan + yUSD oracle manipulation + missing reentrancy guard\n- [Abracadabra (Mar 2025, $13M)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-abracadabra-money-hack-march-2025) — state tracking error in cauldron, self-liquidation + bad loan\n- [Bunni (Sep 2025, $8.4M)](https:\u002F\u002Fwww.theblock.co\u002Fpost\u002F369564\u002Fbunni-smart-contract-rounding-error) — flash loan + pool price manipulation + rounding error micro-withdrawals\n\n### 5. Oracle & Price\n\n| Check | Detail |\n|-------|--------|\n| Single oracle dependency | Using multiple independent price sources? |\n| Stale price | Checking `updatedAt` timestamp and rejecting old data? |\n| Spot price usage | Never using raw AMM reserves for pricing? |\n| Minimum liquidity | Oracle reverts if pool reserves below threshold? |\n| Price deviation | Circuit breaker if price moves beyond threshold vs last known? |\n| Chainlink round completeness | Checking `answeredInRound >= roundId`? |\n\n**Case**: [Cream Finance (Oct 2021, $130M)](https:\u002F\u002Frekt.news\u002Fcream-rekt-2\u002F) — attacker manipulated yUSD vault price by reducing supply, then used inflated collateral to drain all lending pools.\n\n### 6. Numerical Issues\n\n| Type | Description | Defense |\n|------|-------------|---------|\n| Primitive overflow | `uint256 a = uint8(b) + 1` — reverts if b=255 on Solidity ≥0.8 | Use consistent types, avoid implicit narrowing |\n| Truncation | `int8(int256Value)` — silently overflows even on ≥0.8 | Use `SafeCast` library for all type narrowing |\n| Rounding \u002F precision loss | `usdcAmount \u002F 1e12` always rounds to 0 for small amounts | Multiply before divide; check for zero result |\n| Division before multiplication | `(a \u002F b) * c` loses precision | Always `(a * c) \u002F b` |\n\n**Case**: [Bunni (Sep 2025, $8.4M)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-bunni-hack-september-2025) — rounding errors in micro-withdrawals exploited via flash loan.\n\n### 7. Signature Issues\n\n| Type | Description | Defense |\n|------|-------------|---------|\n| ecrecover returns address(0) | Invalid sig returns `address(0)`, not revert | Always check `recovered != address(0)` |\n| Replay attack | Same signature reused across txs\u002Fchains | Include `chainId` + `nonce` + `deadline` in signed data |\n| Signature malleability | ECDSA has two valid (s, v) pairs per signature | Use OpenZeppelin `ECDSA.recover` (enforces low-s) |\n| Empty loop bypass | Signature verification in for-loop, attacker sends empty array | Check `signatures.length >= requiredCount` before loop |\n| Missing msg.sender binding | Proof\u002Fsignature not bound to caller | Always include `msg.sender` in signed\u002Fproven data |\n\n### 8. ERC20 Compatibility\n\n| Issue | Description | Defense |\n|-------|-------------|---------|\n| Fee-on-transfer | `transfer(100)` may deliver \u003C100 tokens | Check balance before\u002Fafter, use actual received amount |\n| Rebase tokens | Token balances change without transfers | Never cache external balances; always read live |\n| No bool return | Some tokens (USDT) don't return bool on transfer | Use `SafeERC20.safeTransfer` |\n| ERC777 hooks | Transfer hooks can trigger reentrancy | Use `ReentrancyGuard` on all token-receiving functions |\n| Zero-amount transfer | `transferFrom(A, B, 0)` — address poisoning | Reject zero-amount transfers |\n| Approval race | Changing allowance from N to M allows spending N+M | Use `safeIncreaseAllowance` \u002F `safeDecreaseAllowance` |\n\n### 9. MEV \u002F Front-Running\n\n| Type | Description | Defense |\n|------|-------------|---------|\n| Sandwich attack | Attacker front-runs buy + back-runs sell around victim | Slippage protection + deadline parameter |\n| ERC4626 inflation | First depositor donates to inflate share price, rounding out later depositors | Minimum first deposit or virtual shares (ERC4626 with offset) |\n| Approval front-run | Attacker spends old allowance before new allowance tx confirms | Use `increaseAllowance` not `approve` |\n| Unrestricted withdrawal | Attacker monitors mempool for withdraw tx, front-runs with own | Require commit-reveal or auth binding |\n\n### 10. Storage & Low-Level\n\n| Issue | Description |\n|-------|-------------|\n| Storage pointer | `Foo storage foo = arr[0]; foo = arr[1];` — does NOT update arr[0] |\n| Nested delete | `delete structWithMapping` — inner mapping data persists |\n| Private variables | All contract storage is publicly readable via `eth_getStorageAt` |\n| Unsafe delegatecall | Delegatecall to untrusted contract can `selfdestruct` the caller |\n| Proxy storage collision | Upgrade changes parent order → variables overwrite each other (use storage gaps) |\n| msg.value in loop | msg.value doesn't decrease in loop — enables double-spend |\n\n### 11. Contract Detection Bypass\n\n| Method | How it works |\n|--------|-------------|\n| Constructor call | Attack from constructor — `extcodesize == 0` during deployment |\n| CREATE2 pre-compute | Pre-calculate contract address, use as EOA before deploying |\n\n### 12. Proxy & Upgrade Vulnerabilities\n\n> Source: [EVMbench Paper §4.2, Appendix H](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf) \u002F [Code4rena 2024-07-basin H-01](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-07-basin)\n\n| Check | Detail |\n|-------|--------|\n| `_authorizeUpgrade` access control | UUPS `_authorizeUpgrade` must have `onlyOwner` modifier? |\n| Permissionless factory\u002Fregistry | Can attacker use permissionless factory (e.g. Aquifer `boreWell`) to satisfy upgrade checks? |\n| `upgradeTo` modifier | Overridden `upgradeTo`\u002F`upgradeToAndCall` retains `onlyProxy` modifier? |\n| Initializer protection | `initializer` modifier prevents re-initialization? Implementation calls `_disableInitializers()`? |\n| Storage layout compatibility | Upgrade-safe storage layout (storage gaps or ERC-7201 namespace)? |\n\n**Case**: [Code4rena 2024-07-basin H-01](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-07-basin) (via [EVMbench Paper Fig.12, p.19](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)) — `_authorizeUpgrade` only checked delegatecall and Aquifer registration but lacked `onlyOwner`, allowing anyone to upgrade a Well proxy to a malicious implementation and drain funds. Oracle patch: add a single `onlyOwner` modifier.\n\n### 13. Trust Boundary & Protocol Composability\n\n> Source: [EVMbench Paper §4.2.1, Fig.6](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf) \u002F Code4rena [2024-04-noya H-08](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-04-noya), [2024-07-benddao](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-07-benddao)\n\n| Check | Detail |\n|-------|--------|\n| Cross-vault trust isolation | Registry\u002FRouter relay calls verify vault-level authorization? |\n| Trusted sender abuse | Functions like `sendTokensToTrustedAddress` verify source vault, not just router identity? |\n| Flash loan + routing combo | Can attacker use flash loan callback to make router impersonate arbitrary vault? |\n| Collateral ownership verification | Liquidation\u002Fstaking operations verify actual NFT\u002Fcollateral owner? |\n| Cross-contract state dependency | Multi-contract interactions free from intermediate state dependencies? |\n\n**Cases**:\n- [Code4rena 2024-04-noya H-08](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-04-noya) (via [EVMbench Paper §4.2.1, Fig.6, p.8-9](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)) — PositionRegistry + BalancerFlashLoan pipeline lacked vault-level auth; keeper used flash loan to make router impersonate any vault, draining cross-vault funds via `sendTokensToTrustedAddress`\n- [Code4rena 2024-07-benddao](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-07-benddao) (via [EVMbench Paper Fig.13, p.19](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)) — `isolateLiquidate` did not verify NFT ownership, allowing attacker to pass others' tokenIds for liquidation\n\n### 14. State Ordering & Counter Manipulation\n\n> Source: [EVMbench Paper Appendix H.1, Fig.19-21](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf) \u002F [Code4rena 2024-08-phi H-06](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-08-phi)\n\n| Check | Detail |\n|-------|--------|\n| Counter\u002FID increment order | `credIdCounter++` or similar ID increments happen before external calls? |\n| Auto-buy in create | `create()` functions with auto `buy()` calls execute only after ID\u002Fstate fully initialized? |\n| Refund timing | ETH refund (excess) happens after all state updates complete? |\n| Bonding curve metadata overwrite | Can attacker reenter to modify bonding curve\u002Fpricing params — buy cheap, switch to expensive curve, sell high? |\n\n**Case**: [Code4rena 2024-08-phi H-06](https:\u002F\u002Fcode4rena.com\u002Freports\u002F2024-08-phi) (via [EVMbench Paper Appendix H.1, p.25-28](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)) — `_createCredInternal` called `buyShareCred` before incrementing `credIdCounter`; `_handleTrade` refunded excess ETH before updating `lastTradeTimestamp`. Attacker reentered to accumulate shares on cheap curve, overwrote metadata to expensive curve, sold to drain all contract ETH. Fix: add `nonReentrant` to `buyShareCred`\u002F`sellShareCred`.\n\n## Infrastructure-Level Vulnerabilities\n\n### 15. Frontend \u002F UI Injection\n\nAttackers inject malicious code into the dApp frontend or signing interface.\n\n**Defense**: Verify transaction calldata matches expected function selector and parameters before signing. Use hardware wallet with on-device transaction preview. Audit all frontend dependencies regularly.\n\n**Case**: [Bybit (Feb 2025, $1.4B)](https:\u002F\u002Fwww.nccgroup.com\u002Fresearch-blog\u002Fin-depth-technical-analysis-of-the-bybit-hack\u002F) — malicious JavaScript injected into Safe{Wallet} UI, tampered with transaction data during signing.\n\n### 16. Private Key & Social Engineering\n\nCompromised keys remain the #1 loss source in 2025-2026.\n\n**Defense**: Store keys in HSM or hardware wallet. Use multisig (≥ 3\u002F5) for all treasury and admin operations. Never share seed phrases with any \"support\" contact. Conduct regular social engineering awareness training.\n\n**Case**: [Step Finance (Jan 2026, $30M)](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-step-finance-hack-january-2026) — treasury wallet private keys compromised via device breach.\n\n### 17. Cross-Chain Bridge\n\n| Check | Detail |\n|-------|--------|\n| Inherited code | Audit all bridge logic inherited from third-party frameworks |\n| Message verification | Cross-chain messages validated with proper signatures and replay protection? |\n| Liquidity isolation | Bridge funds separated from protocol treasury? |\n\n**Case**: [SagaEVM (Jan 2026, $7M)](https:\u002F\u002Fwww.theblock.co\u002Fpost\u002F386638\u002Fsagaevm-suffers-exploit) — inherited vulnerable EVM precompile bridge logic from Ethermint.\n\n### 18. Legacy \u002F Deprecated Contracts\n\nOld contracts with known bugs remain callable on-chain forever.\n\n**Defense**: Permanently `pause` or migrate funds from deprecated contracts. Monitor old contract addresses for unexpected activity. Remove mint\u002Fadmin functions before deprecation.\n\n**Case**: [Truebit (Jan 2026, $26.4M)](https:\u002F\u002Fwww.coindesk.com\u002Fmarkets\u002F2026\u002F01\u002F09\u002Ftruebit-token-tru-crashes-99-9-after-usd26-6m-exploit-drains-8-535-eth) — Solidity 0.6.10 contract lacked overflow protection, attacker minted tokens at near-zero cost.\n\n## Automated Analysis with Slither MCP (if available)\n\nWhen `slither` MCP is configured, run automated analysis BEFORE the manual checklist below:\n\n### Recommended Audit Flow\n\n```\nStep 1: slither MCP automated scan\n        → get_detector_results(path, impact=\"High\")\n        → get_detector_results(path, impact=\"Medium\")\nStep 2: Review Slither findings — triage true positives vs false positives\nStep 3: Manual checklist below — catch what Slither misses (business logic, economic attacks)\nStep 4: Cross-reference — Slither + manual findings combined into final report\n```\n\n### Slither MCP Tools\n\n| Tool | Usage | Complements |\n|---|---|---|\n| `get_contract_metadata` | Extract functions, inheritance, flags | Manual access control review |\n| `get_function_source` | Get exact source code with line numbers | Faster than grep for locating code |\n| `find_implementations` | Find all implementations of a function signature | Cross-contract reentrancy analysis |\n| `get_detector_results` | Run 90+ security detectors, filter by impact\u002Fconfidence | Automated version of manual checklist |\n| `get_detector_metadata` | List available detectors with descriptions | Understanding what's being checked |\n\n### What Slither Catches vs What It Misses\n\n| Slither Catches Well | Manual Review Still Needed |\n|---|---|\n| Reentrancy patterns | Business logic flaws |\n| Unprotected functions | Economic attack vectors (flash loan combos) |\n| Unused state variables | Cross-protocol composability risks |\n| Shadowing issues | Oracle manipulation scenarios |\n| Incorrect ERC20 interface | Trust boundary architecture issues |\n| Dead code | MEV\u002Ffront-running specific to business logic |\n\n**Key Principle**: Slither provides ground truth via static analysis — reduces false negatives on known vulnerability patterns. But it cannot reason about protocol-level economic attacks — that's where the manual checklist below is essential.\n\n**Graceful degradation**: If slither MCP is not configured, skip this section and proceed directly to the manual checklist. All checklist items remain valid and self-contained.\n\n## Audit Execution Checklist\n\nWhen conducting a security audit, check each item:\n\n**Reentrancy:**\n- [ ] All functions with external calls use `nonReentrant`\n- [ ] CEI pattern followed — no state reads after external calls\n- [ ] View functions not used as oracle during state transitions\n\n**Access Control:**\n- [ ] Every state-changing function has explicit access modifier\n- [ ] Modifiers actually revert (not silently pass)\n- [ ] Admin privileges are minimal and documented\n\n**Input & Logic:**\n- [ ] No unvalidated arbitrary `call` \u002F `delegatecall`\n- [ ] No `tx.origin` for authentication\n- [ ] Array lengths validated for paired inputs\n- [ ] No division-before-multiplication precision loss\n\n**Token Handling:**\n- [ ] All ERC20 ops use `SafeERC20`\n- [ ] Fee-on-transfer tokens handled (balance diff check)\n- [ ] Rebase token balances not cached\n- [ ] Zero-amount transfers rejected\n\n**Price & Oracle:**\n- [ ] No raw spot price usage\n- [ ] Stale price check (`updatedAt` \u002F `answeredInRound`)\n- [ ] Minimum liquidity threshold enforced\n- [ ] Price deviation circuit breaker\n\n**Signature & Crypto:**\n- [ ] `ecrecover` result checked against `address(0)`\n- [ ] Signed data includes `chainId`, `nonce`, `msg.sender`, `deadline`\n- [ ] Using OZ `ECDSA` (low-s enforced)\n- [ ] MerkleProof leaves bound to `msg.sender`\n\n**Flash Loan Defense:**\n- [ ] Governance: snapshot voting + holding period + timelock\n- [ ] Price: TWAP or multi-oracle, not single-block spot\n- [ ] Vault: minimum first deposit or virtual shares (ERC4626)\n\n**Proxy & Upgrade ([EVMbench](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)):**\n- [ ] UUPS `_authorizeUpgrade` has `onlyOwner` — [EVMbench\u002Fbasin H-01]\n- [ ] `upgradeTo`\u002F`upgradeToAndCall` retains `onlyProxy` — [EVMbench\u002Fbasin H-01]\n- [ ] Implementation constructor calls `_disableInitializers()` — [EVMbench\u002Fbasin H-01]\n- [ ] Storage layout upgrade-compatible (storage gaps or ERC-7201) — [EVMbench\u002Fbasin H-01]\n\n**Trust Boundary & Composability ([EVMbench](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)):**\n- [ ] Router\u002FRegistry relay calls verify source vault\u002Fcontract authorization — [EVMbench\u002Fnoya H-08]\n- [ ] Liquidation operations verify actual collateral ownership — [EVMbench\u002Fbenddao]\n- [ ] Flash loan callback paths cannot be abused to penetrate trust boundaries — [EVMbench\u002Fnoya H-08]\n- [ ] No intermediate state dependencies in multi-contract interactions — [EVMbench\u002Fnoya H-08]\n\n**State Ordering ([EVMbench](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf)):**\n- [ ] Counter\u002FID increments complete before external calls — [EVMbench\u002Fphi H-06]\n- [ ] ETH refunds execute after all state updates — [EVMbench\u002Fphi H-06]\n- [ ] Auto-operations in create functions (auto-buy etc.) execute after full initialization — [EVMbench\u002Fphi H-06]\n\n**Infrastructure:**\n- [ ] Third-party dependencies audited (bridge code, inherited contracts)\n- [ ] No deprecated contracts still callable with admin\u002Fmint functions\n- [ ] Multisig on all treasury and admin wallets\n- [ ] Frontend transaction verification (calldata matches expected)\n\n## AI Agent Audit Methodology\n\n> Source: [EVMbench (OpenAI\u002FParadigm, Feb 2026)](https:\u002F\u002Fcdn.openai.com\u002Fevmbench\u002Fevmbench.pdf) — evaluated AI agents on 120 high-severity vulnerabilities from 40 Code4rena audit repositories across Detect\u002FPatch\u002FExploit modes.\n\n### Audit Strategy\n\n1. **Coverage over depth**: scan ALL in-scope files; do not stop after finding the first vulnerability [EVMbench §5, p.10]\n2. **Three-phase audit**: Detect (identify vulnerabilities) -> Patch (write fix) -> Exploit (build PoC) [EVMbench §3.2, p.5]\n3. **Incremental output**: write findings continuously during audit to preserve progress [EVMbench Appendix G, Fig.18, p.24]\n4. **Systematic category scan**: check by vulnerability class (reentrancy, access control, numerical, oracle...) rather than intuition [EVMbench §3.1, p.4]\n5. **Verify fixes**: after patching, confirm original tests still pass AND exploit is no longer viable [EVMbench §3.2.2, p.5]\n\n### High-Frequency Vulnerability Patterns (Code4rena Data)\n\n> Source: EVMbench Table 4 (p.17) — 40 audit repositories\n\n- Missing access control (upgradeability, liquidation, admin functions) — basin H-01, munchables, benddao\n- Reentrancy + state ordering errors (refund before state update) — phi H-06, noya H-08\n- Flash loan trust boundary penetration (exploiting router\u002Fregistry trust propagation) — noya H-08\n- Signature replay \u002F front-running (checkpoint bypass, session signature replay) — sequence H-01, H-02\n- Numerical precision \u002F rounding (bonding curve, micro-withdrawals) — abracadabra H-02, size H-02\n\n### Key Findings\n\n> Source: EVMbench Paper §4.1 (p.7), Fig.7 (p.10), Fig.10 (p.18), Fig.11 (p.19)\n\n- With mechanism hints, Patch success rate jumps from ~40% to ~94% [Fig.7] — agents know how to fix but struggle to find vulnerabilities\n- Most vulnerabilities require ≤5 lines of code to fix [Fig.10, p.18]\n- Most exploits require only 1-3 transactions [Fig.11, p.19]\n- Agents whose finding count is closest to actual vulnerability count score highest (quality > quantity) [Fig.5, p.8]\n\n## 2021-2026 Incident Quick Reference\n\n| Date | Project | Loss | Attack Type | Root Cause | Source |\n|------|---------|------|-------------|------------|--------|\n| Oct 2021 | Cream Finance | $130M | Flash loan + oracle | yUSD vault price manipulation via supply reduction | [rekt.news](https:\u002F\u002Frekt.news\u002Fcream-rekt-2\u002F) |\n| Feb 2025 | Bybit | $1.4B | UI injection \u002F supply chain | Safe{Wallet} JS tampered via compromised dev machine | [NCC Group](https:\u002F\u002Fwww.nccgroup.com\u002Fresearch-blog\u002Fin-depth-technical-analysis-of-the-bybit-hack\u002F) |\n| Mar 2025 | Abracadabra | $13M | Logic flaw | State tracking error in cauldron liquidation | [Halborn](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-abracadabra-money-hack-march-2025) |\n| Jul 2025 | GMX v1 | $42M | Reentrancy | GLP pool cross-contract reentrancy on Arbitrum | [Halborn](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-gmx-hack-july-2025) |\n| Sep 2025 | Bunni | $8.4M | Flash loan + rounding | Rounding direction error in withdraw, 44 micro-withdrawals | [The Block](https:\u002F\u002Fwww.theblock.co\u002Fpost\u002F369564\u002Fbunni-smart-contract-rounding-error) |\n| Oct 2025 | Abracadabra #2 | $1.8M | Logic flaw | cook() validation flag reset, uncollateralized MIM borrow | [Halborn](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-abracadabra-hack-october-2025) |\n| Jan 2026 | Step Finance | $30M | Key compromise | Treasury wallet private keys stolen via device breach | [Halborn](https:\u002F\u002Fwww.halborn.com\u002Fblog\u002Fpost\u002Fexplained-the-step-finance-hack-january-2026) |\n| Jan 2026 | Truebit | $26.4M | Legacy contract | Solidity 0.6.10 integer overflow in mint pricing | [CoinDesk](https:\u002F\u002Fwww.coindesk.com\u002Fmarkets\u002F2026\u002F01\u002F09\u002Ftruebit-token-tru-crashes-99-9-after-usd26-6m-exploit-drains-8-535-eth) |\n| Jan 2026 | SagaEVM | $7M | Supply chain \u002F bridge | Inherited Ethermint precompile bridge vulnerability | [The Block](https:\u002F\u002Fwww.theblock.co\u002Fpost\u002F386638\u002Fsagaevm-suffers-exploit) |\n\n",{"name":5,"description":7},"main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002F0xlayerghost\u002Fsolidity-agent-kit\u002Fsolidity-audit",24,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub","https:\u002F\u002Fskillshub.wtf","https:\u002F\u002Fgithub.com\u002FComeOnOliver","AI & Blockchain Engineer\r\n","2026-06-24 22:07:19",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill solidity-audit",{"tool":64,"command":65},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill solidity-audit",{"tool":67,"command":68},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill solidity-audit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002F0xlayerghost\u002Fsolidity-agent-kit\u002Fsolidity-audit\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"_AIWF_IMPORT.json","REFERENCE","参考文档",376,"https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fgithub_imports\u002Fpostmortem\u002F_AIWF_IMPORT.json",[79,89,99,108,114,121],{"skillNo":80,"name":81,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":85,"publishedAt":44},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[84],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[86,87,88],"model","model hierarchy","model hierarchy skill",{"skillNo":90,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":95,"publishedAt":44},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[94],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[96,97,98],"MCP","zoom","zoom mcp",{"skillNo":100,"name":101,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":44},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[105,106,107,97],"sdk","zoom apps sdk","apps",{"skillNo":109,"name":110,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":44},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[110],{"skillNo":115,"name":116,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":44},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[119],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[116],{"skillNo":122,"name":123,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":44},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[123]]