Solidity Security Audit Skill

Purpose

Perform professional-grade smart contract security audits following methodologies established by the world's leading Web3 security firms. Produce actionable, severity-classified findings with remediation guidance.

Context Gathering — When Code Arrives Without Scope

Trigger: User pastes Solidity code (one function, one file, or a repo link) with no additional context — no chain, no Solidity version, no stated scope, no prior audit info.

Do NOT start auditing immediately. Missing context causes wrong severity ratings, irrelevant findings (e.g., flagging L2 issues on mainnet-only code), and wasted effort. Ask the following questions in a single message before proceeding.

Required Context (block until answered)

Ask these as a short numbered list — not a form, not a table:

Before I start the audit, I need a few details:

1. **Scope** — Is this the full codebase, a single contract, or a specific function?
   (Full codebase = I'll check cross-contract interactions; single function = focused review)

2. **Solidity version** — What compiler version are you targeting?
   (Affects: overflow behavior, PUSH0 compatibility, transfer()/send() deprecation in 0.9.0)

3. **Target chain(s)** — Where will this deploy?
   (Mainnet, L2 like Arbitrum/Base/zkSync, multi-chain, or unknown)

4. **Previous audits** — Has this code been audited before? Any known issues or recent changes?
   (If yes → Re-audit mode; if no → Full Audit)

5. **Protocol type** — What does this protocol do?
   (e.g., lending, AMM, vault, bridge, governance — determines which checklist to load)

Defaults If User Cannot Answer

If the user says "just check it" or provides no answers, assume these safe defaults and state them explicitly at the start of the audit:

Fast Path — Single Function Paste

When a user pastes an isolated function (≤30 lines, no visible contract state or constructor), skip the context questions and do a Quick Scan directly. State:

"Reviewing this function in isolation. For a full audit including state variables, access control, and cross-contract interactions, share the full contract."

Then output: severity-tagged bullet list (Critical/High only unless none found, then include Medium).

Audit Mode Selection

Before starting, identify the audit mode:

For severity classification guidance at any point, consult references/severity-decision-tree.md.

Contest Mode

Activate when the user mentions: "Code4rena", "C4", "Sherlock", "Immunefi", "Cantina", "CodeHawks", "Cyfrin", "warden submission", "Watson submission", "bug bounty submission", "audit contest", "audit competition", "contest finding", or "submit to contest".

Step 0 — Identify the Platform

Once identified, apply the exact submission format from references/report-template.md → Contest Submission Format.

Step 1 — Scope Verification

Before any review:

• Read the contest README, scope.txt, and known issues list in the contest repo
• Mark all out-of-scope contracts — findings there are immediately invalid
• Note "Admin is trusted" and other protocol assumptions that eliminate entire bug classes
• Check if a bot race report has been submitted (C4 bots claim floating pragma, missing zero-checks, unchecked returns — avoid these)

Step 2 — Priority Stack (Contest ROI)

Contests reward unique, high-impact findings. Allocate review time accordingly:

Highest ROI → spend 70% of time here:

• Reentrancy (all variants, especially cross-function and read-only)
• Oracle manipulation (spot price, TWAP bypass, stale feeds)
• Access control gaps on privileged functions
• Business logic errors (incorrect fee math, state machine violations, off-by-one)
• Economic attacks (flash loan vectors, slippage, MEV)

Medium ROI → spend 25%:

• Integer precision / rounding direction
• Missing input validation (zero-address, bounds — only if exploitable, not bot-fodder)
• DoS vectors (unbounded loops, griefing with real impact)
• Signature replay / EIP-712 errors

Low ROI — skip unless trivial to add:

• Gas optimizations (only if contest has a Gas pool)
• Code style, naming (NC / Info → no payout on most platforms)
• Findings already listed as known issues

Step 3 — Validity Pre-Check

Before writing each finding, apply this filter:

Is there a working attack path an external actor can execute?
├─ No → Invalid (likely rejected)
│
Is the root cause inside the contest scope?
├─ No → Out of scope (invalid)
│
Does the impact require a trusted role (admin, owner)?
├─ Yes, and admin is listed as trusted → Low at best (often invalid)
│
Can the impact be quantified in USD?
├─ Yes → always include the estimate (judges weight concrete impact)
├─ No → describe the qualitative harm precisely
│
Is there a working PoC?
├─ H/M without PoC → likely downgraded or rejected
├─ Build a Foundry test before writing the report

Step 4 — Platform-Specific Rules

Code4rena:

• Each H/M = separate GitHub issue; QA findings bundled in one QA report
• Duplicate = same root cause (not same symptom) → split reward pool
• Unique findings with PoC earn the most; first-mover advantage on uncommon bugs
• Link every finding to exact GitHub permalink (commit hash, not branch)
• Use diff format in mitigations when possible

Sherlock:

• Strict pre-conditions template required: "Internal pre-conditions" + "External pre-conditions"
• admin is trusted = admin-abuse findings are invalid (not even Low)
• "Loss of 1 wei" alone = invalid; needs meaningful dollar impact or significant disruption
• Escalation period: Watson escalation reviewed by Senior Watsons; escalate if you believe judge is wrong
• Valid states must persist after the PoC transaction (not reset by next block)

Immunefi:

• Bug bounty: disclose privately first; no public disclosure until patched
• Critical/High require a working PoC; Medium may be accepted with clear description
• Impact must be real: "theoretical" or "best