Deploying an unaudited smart contract is like shipping a bank vault with the blueprints taped to the outside. Once it's on-chain, it's immutable — and so are its vulnerabilities.
This checklist covers everything you should verify before submitting your contracts for a professional audit, and before deploying to mainnet.
Code Quality Basics
💡Audit-Ready Code Saves Money
Auditors charge by the hour. Clean, well-documented code means they spend time finding real issues instead of deciphering your logic.
Before thinking about security, make sure your code is audit-ready:
- All tests pass — 100% of your test suite should be green
- High test coverage — Aim for 90%+ line coverage on critical paths
- Clean compilation — Zero warnings from the Solidity compiler
- Consistent formatting — Use Prettier or a standard style guide
- Updated dependencies — OpenZeppelin and other libraries at latest stable versions
- Documentation — NatSpec comments on all public/external functions
The Vulnerability Checklist
Reentrancy
External call triggers fallback
Attacker contract's receive() or fallback() is invoked
Fallback re-enters the function
Before state is updated, the function is called again
State is inconsistent
Balances haven't been deducted yet — funds are drained
Check every external call:
- Do you follow the checks-effects-interactions pattern?
- Are state changes made before external calls?
- Have you considered cross-function and cross-contract reentrancy?
- Are you using
ReentrancyGuardon sensitive functions?
Access Control
- Are admin functions properly restricted?
- Can ownership be transferred safely (two-step process)?
- Are there functions that should be
onlyOwnerbut aren't? - Can privileged roles be revoked or is there a single point of failure?
Integer and Precision Issues
- Are you using Solidity 0.8+ (built-in overflow checks)?
- If using
uncheckedblocks, is it truly safe? - Are there precision loss issues in division operations?
- Do you multiply before dividing (
a * c / b, nota / b * c)?
Oracle and Price Manipulation
🛑Never Use Spot Prices
Using getReserves() or single-block prices from a DEX is an invitation for flash loan attacks. Always use TWAP, Chainlink, or multi-source oracles.
- Are you using time-weighted average prices (TWAP)?
- Can flash loans manipulate your price feeds?
- Do you have circuit breakers for extreme price movements?
- Are oracle responses validated for staleness?
Flash Loan Attacks
- Can any function be exploited within a single transaction?
- Are there governance functions attackable with borrowed voting power?
- Do liquidity checks happen at the right time?
Severity Reference
| Severity | Examples |
|---|---|
| Critical | Reentrancy, access control bypass, fund theft |
| High | Oracle manipulation, unchecked return values, privilege escalation |
| Medium | Front-running, precision loss, DoS vectors |
| Low | Gas optimization, informational findings, best practices |
DeFi-Specific Checks
| Area | What to Check |
|---|---|
| Liquidity pools | Sandwich attack resistance, impermanent loss handling |
| Lending | Liquidation thresholds, bad debt scenarios |
| Staking | Reward calculation precision, withdrawal delays |
| Governance | Timelock implementation, quorum manipulation |
| Bridges | Message verification, replay protection |
Pre-Audit Preparation
Freeze Codebase
No changes during the audit period
Document Everything
Deployment scripts, external deps, economic model
List Known Issues
Tell auditors about intentional trade-offs
When you're ready to submit for a professional audit:
- Freeze the codebase — No changes during the audit
- Provide deployment scripts — Show exactly how contracts are deployed and configured
- Document external dependencies — Which protocols do you integrate with?
- List known issues — If you're aware of trade-offs, tell the auditors
- Describe the economic model — How do tokens flow? What are the incentives?
What Auditors Deliver
- Line-by-line findings with severity ratings
- Proof-of-concept exploits demonstrating each vulnerability
- Economic attack modeling for DeFi-specific risks
- Gas optimization suggestions where applicable
- Remediation recommendations with code examples
- Re-audit verification after you fix the issues
The Bottom Line
⚠️No Checklist Replaces an Audit
Following these steps ensures you get maximum value from a professional audit — and catch the obvious issues before an auditor has to. But only an expert review can catch the complex, protocol-specific vulnerabilities that lead to exploits.
Need a professional smart contract audit? Get a quote — our AI pre-screens your code before human auditors deep-dive into the complex logic.