The smart contract security checklist an AI dApp builder cannot skip

01

Write down what is at risk

A contract that stores votes has a different risk profile from one that moves customer funds. List the assets, privileged roles, upgrade powers and external dependencies before writing a security prompt. Ask who can pause, withdraw, change fees, swap an oracle, upgrade implementation code or alter an allowlist. If the answer is “admin,” define who controls that account and how it is recovered.

Ethereum’s smart contract security guidance emphasizes that contracts are public, interactions can be adversarial and failures may be hard to reverse. The first review should therefore be a threat model, not a linter report.

02

Review the boundaries people overlook

Permission checks must live in contract or trusted server logic, not just behind a hidden frontend button. External calls can introduce reentrancy and unexpected behaviour. Oracle data can be stale or manipulated, and a price shown in a UI is not necessarily the value the contract uses. Upgradeability can fix errors, but it also creates an authority that must be constrained and disclosed.

Use the OWASP Smart Contract Security Verification Standard as a review framework. It does not certify your contract; it gives you a structured set of questions about architecture, access control, arithmetic, external interactions and deployment. Turn those questions into tests tied to your actual contract.

• Can an unprivileged account reach a privileged function?
• Can callbacks or external calls change state in an unexpected order?
• What happens with stale, missing or extreme oracle data?
• Can a paused system still let users exit safely?
• Does an upgrade or admin key have a documented owner and delay?

03

Ask AI for tests that try to disprove the design

Do not stop at a happy-path test that deposits and withdraws once. Ask for invariant tests: total liabilities cannot exceed assets; one user cannot withdraw another user’s funds; a rejected signature changes no state; a duplicate event does not pay twice. Fuzz boundary inputs and test the role transitions that happen rarely but matter most.

A stronger prompt is: “Review this contract as an adversary. List assets, roles, external dependencies and invariants. Write failing tests for the highest-risk scenarios before suggesting patches. Do not claim an audit or security guarantee. Explain which findings need a human reviewer.” That turns the AI into a useful assistant while keeping its limitations visible.

04

Separate app security from contract security

Even a carefully reviewed contract can sit behind a compromised web interface. Check that the frontend displays the correct chain, contract address and transaction destination. Protect API keys and admin tools. Make the deployment process reproducible, pin important dependencies and verify the deployed address against the reviewed source.

If the app uses a price feed, read the provider’s guidance for that specific feed and network. Chainlink documents feed data and usage; your product still needs to handle stale updates and the consequences of an unavailable answer. Security is a system property, not one Solidity file.

05

Go live with a limit and a response plan

A bounded pilot gives the team a chance to observe real behaviour with limited exposure. Decide who monitors events, how incidents are reported, when to pause, and how users will hear about a problem. If a contract will hold meaningful value, independent review should be part of the launch decision. A code generator cannot confer that assurance.

The most useful release note is candid: what was tested, what was reviewed independently, which network and contract address are live, and what remains unknown. Users deserve that clarity more than a generic “audited by AI” badge.

06

What should a non-developer ask before approving a launch?

Ask for a short, readable explanation of what the contract controls, who can change it, which assets it can move and what a user can recover if something fails. Ask to see the exact address and network, not a screenshot of source code alone. Ask which tests failed before repair and which risks remain after the repair. If those answers cannot be produced, postpone the launch.

Security work also has a time dimension. A contract may be reviewed today and depend on a feed, multisignature or upgrade key that changes tomorrow. Put those dependencies on an operational checklist with named owners. Record emergency contacts and the steps for communicating with affected users. None of this is glamorous, but a practical response plan matters more than a security adjective in marketing copy.