What this prompt does
This prompt runs a structured Solidity security audit so nothing gets hand-waved before a contract holds real value. You describe the [contract_type], the [value_at_risk], its [deployment_status], and its [dependencies], and it works through seven categories: reentrancy in [external_call_functions], access control and [centralization_risks], arithmetic and casting between [cast_types], oracle manipulation in [oracle_usage], DoS vectors, front-running, and a severity-tagged findings report.
The structure works because the failures that actually drain funds are predictable. Reentrancy, missing access control, and oracle manipulation recur in nearly every major exploit, so the prompt forces each onto the table with specific targets — checks-effects-interactions in [shared_state_functions], missing guards on [sensitive_functions], flash-loan vulnerability in [oracle_usage], unbounded loops in [dos_risks], and sandwich exposure in [frontrun_targets] — and demands a proof of concept and recommended fix for each issue. Naming the [value_at_risk], [deployment_status], and [dependencies] up front also calibrates how paranoid the review should be, since a testnet contract preparing for a large mainnet launch deserves the harshest scrutiny.
When to use it
- You are reviewing a contract before it goes near mainnet
- You want a structured audit instead of ad-hoc "looks fine" reading
- You need reentrancy checked against specific
[external_call_functions] - You want
[centralization_risks]surfaced — can the owner drain funds? - You need oracle manipulation in
[oracle_usage]analyzed for flash-loan exposure - You want arithmetic and casting between
[cast_types]checked for silent truncation - You want a severity-tagged findings report you can act on and track
Example output
Expect a findings report organized by the seven audit categories: a reentrancy section examining [external_call_functions] and [shared_state_functions], an access-control map of privileged functions with [centralization_risks] flagged, an arithmetic section checking [cast_types] and precision in [math_functions], an oracle section analyzing [oracle_usage] for manipulation, a DoS section covering [dos_risks], a front-running section on [frontrun_targets] with [frontrun_mitigations], and a consolidated table where each issue has a severity (Critical/High/Medium/Low/Informational), description, proof of concept, and fix. The report is structured so you can triage by severity and track each finding to resolution rather than wading through prose.
Pro tips
- Treat this as one layer, not a replacement for a professional human audit when
[value_at_risk]is high - Make
[external_call_functions]and[shared_state_functions]precise so reentrancy analysis targets real call sites, not generic warnings - Be honest about
[centralization_risks]— an owner who can change the oracle or drain funds is often the biggest real risk - Specify
[oracle_usage]exactly, including whether you use spot price anywhere, since spot price in liquidation logic is a classic flash-loan vector - Call out unsafe
[cast_types]like uint256-to-uint128 for packing, since silent truncation there can corrupt balances - List concrete
[dos_risks]like unbounded loops over depositors so the audit checks gas-limit failure modes - Demand the proof-of-concept for each finding; a severity label without a PoC is hard to prioritize or verify
