What this prompt does
This prompt turns the AI into a senior smart-contract security reviewer and asks for a prioritised pre-deploy checklist tied to your specific contract — not generic boilerplate. Every item must map to a concrete check or test that proves it, which is what makes the output usable as a deployment gate rather than a reading exercise. It covers the categories that actually drain funds: reentrancy, integer overflow/underflow, unchecked external calls, access control, economic and oracle risks, and upgradeability pitfalls.
The placeholders focus the review. [contract] describes the system under review so the model references real functions instead of abstractions, [chain_version] sets the chain and Solidity version (which affects overflow behaviour and tooling), and [criticality] — for example "holds user deposits, high criticality" — calibrates how aggressive the Critical/High/Medium prioritisation should be. The more you tell it about value at risk, the better it ranks what to fix first.
When to use it
- You're running a final gate before a mainnet deploy and want a prioritised, testable checklist.
- You use proxies and need a careful review of storage collisions, pausing, and timelocks.
- You want each finding tied to a one-line check or test rather than vague warnings.
- You're preparing a contract to hand to an external auditor and need to know your coverage gaps.
- You're worried about economic risks like front-running, MEV, or oracle manipulation.
- You need a list of invariants to fuzz before deploy.
Example output
You get a prioritised checklist grouped Critical / High / Medium, where each item carries a one-line check or test that proves it. Sections cover reentrancy and arithmetic safety, access-control and privileged-function exposure, economic and oracle risks (front-running, MEV, slippage), upgradeability and lifecycle (proxy storage collisions, emergency stop, timelocks), observability (events and post-deploy monitoring), and audit readiness (coverage gaps and invariants to fuzz). Because items reference [contract], the checklist reads as a review of your system rather than a generic security article.
Pro tips
- Describe
[contract]in real terms — "an ERC-20 with minting caps and pausability" yields findings about those exact functions, while a vague description produces boilerplate. - Set
[criticality]honestly; "holds user deposits, high criticality" pushes more items into the Critical band where they belong. - Do the upgradeability section (deliverable 4) carefully if you use proxies — storage-layout mistakes are silent until they're catastrophic.
- Match
[chain_version]to your actual compiler; overflow behaviour and available tooling differ across Solidity versions. - Treat this as a complement to a professional audit, not a replacement — it surfaces gaps and invariants to fuzz, which makes the eventual audit cheaper and faster.
- Turn each one-line check into an actual test where you can; a passing test beats a checked box.
