If your audit starts next week and you are still planning to clean up later, you are not preparing for an audit. You are buying a very expensive reading-comprehension exercise.
Auditors are paid to be suspicious. If you hand them vague requirements, thin tests, and a repo full of half-finished ideas, they will still find issues. You will just spend more time and money answering basic questions before they can focus on meaningful risk.
If you are still shaping your launch plan, pair this guide with Web3 MVP Checklist and How to Build an MVP Fast.
Auditors will ask what must never happen. That is an invariant: a property that must remain true across state transitions, no matter who calls your contracts, in what order, and with what inputs.
Practical invariant categories (examples)
Supply and accounting
- A user cannot withdraw more than they should.
- Internal accounting matches actual token balances.
- Total supply changes only through explicit mint and burn rules.
Access control
- Only role X can trigger Y.
- Privilege cannot be escalated through callable external hooks.
State machine
- Initialization happens once, then normal operation continues.
- Critical actions stop when paused.
Integrations
- Oracle data is validated for staleness and formatting assumptions.
- Token interactions handle non-standard behavior safely.
If you are building on Ethereum, you get strong tooling and standards, and you inherit years of sharp edges. Name the invariants, then prove them.
Turn invariants into test targets
Write each invariant in plain English, then define:
- Which variables represent it.
- Which functions can violate it.
- Which boundary case is most likely to break it.
- Test approach (scenario, fuzz, invariant test, fork test, or formal check).
Invariant: users are safe is not an invariant. It is a slogan.
