Short answer: A DeFi pre-launch security checklist is the set of code, configuration, and operational checks a team completes before deploying to mainnet. Code review and audits matter, but many losses come from what surrounds the code: misconfigured oracles, single-key admin roles, botched deployments, leaked keys, and no plan for the first incident. The 15 steps below cover all of it, roughly in the order you will need them.
Before anyone external reads your code, walk it against the classes that cause most losses: reentrancy, access control, oracle manipulation, precision loss, flash-loan amplification, and unsafe token integrations such as fee-on-transfer tokens. Remove debug code, test-only functions, and hardcoded addresses that belong in configuration.
Owner: Development team · When: Before scoping an external review
Cover the happy path, then the edges: zero and maximum amounts, rounding in both directions, unauthorized callers, paused states, and first-depositor scenarios. Line coverage is a floor, not a goal — branch coverage on value-moving functions is what matters.
Owner: Development team · When: Continuous; final check two weeks before launch
Write down the rules your protocol must never break — total shares backed by assets, no user withdraws more than they are owed, solvency after liquidation — and encode them as invariant tests in Foundry or properties in Echidna. Run long campaigns before each review. See the smart contract security tools comparison for how the tools differ, and the Slither, Mythril, and Echidna workflow for commands.
Owner: Development / security lead · When: Start early; long runs before each review
Run Slither on every pull request and fail on new high-severity findings once the baseline is triaged. Our CI security setup has working GitHub Actions workflows.
Owner: DevOps / development · When: From the first commit you intend to ship
Engage reviewers early enough to fix what they find and have the fixes re-checked. Scope explicitly: which contracts, which commit, which integrations, and which assumptions are out of scope. Complex protocols often combine a firm audit with a competitive review or a formal verification engagement for the highest-value invariants. Compare providers in our guide to smart contract audit firms and budget with the audit pricing pages.
Owner: Protocol lead · When: Book 6–12 weeks ahead; freeze code before the review starts
Use established feeds where they exist and validate what you read: check updatedAt against a staleness bound appropriate to each feed's heartbeat, reject zero or negative answers, and on L2s check the sequencer uptime feed. Avoid spot prices from a single DEX pool for anything that can be manipulated within one transaction. Test the failure modes — stale feed, paused feed, extreme moves.
Owner: Smart contract lead · When: Before the external review, so reviewers see the final integration
Admin roles should be held by a multisig (for example a Safe), not an EOA, with signers on independent devices. Put parameter changes and upgrades behind a timelock such as OpenZeppelin's TimelockController so users can react. Inventory every privileged function and document who can call it — reviewers and users will ask. Consider a separate, narrowly scoped guardian role that can pause but not upgrade or move funds.
Owner: Protocol lead / governance · When: Three weeks before launch; test on testnet
List every external dependency and integration: libraries such as OpenZeppelin, the tokens you accept, the protocols you call. Pin versions, check for published advisories, and review how you behave if an integrated protocol pauses, upgrades, or returns unexpected values.
Owner: Development lead · When: Four weeks before launch
Confirm fee math and recipients, and that every user can always withdraw what they are owed — including when the protocol is paused, if that is your intended design. Stuck-funds bugs are as damaging to trust as exploits.
Owner: Product / development · When: Two weeks before launch
Deploy with scripts (Foundry or Hardhat), never by hand. Rehearse the full sequence on a testnet and on a mainnet fork, including constructor arguments, initialization calls, role assignments, and ownership transfers. Uninitialized proxies and forgotten role transfers are a recurring source of incidents.
Owner: DevOps / release manager · When: Rehearse multiple times in the final three weeks
Run the deployed system on a public testnet with real users and integrators. Watch gas costs, front-end behavior, and edge cases that internal testing missed. Consider a bug bounty that opens on testnet and continues on mainnet, for example through Immunefi.
Owner: Release manager · When: Two to four weeks before launch
Verify all contracts on the block explorer, publish deployment addresses, and document privileged roles and upgrade procedures. Transparent configuration lets users and researchers check your claims.
Owner: DevOps · When: At deployment
Deployer and signer keys belong on hardware wallets. Limit who holds them, document recovery, and never reuse deployer keys for day-to-day operations. Operational hot keys (keepers, relayers) should hold only the permissions and balances they need.
Owner: Security lead · When: Before the first mainnet transaction
Decide what you need to watch on-chain — large withdrawals, oracle deviations, privileged-role calls, paused states — and which tools will watch it. Then test the alerts end to end: fire a test event and confirm the right person gets paged.
Owner: Operations · When: One week before launch
Write the runbook before you need it: who can pause, how signers are reached at 3 a.m., who talks to users, exchanges, and integrators, and where you will coordinate. Know about resources such as SEAL 911 for emergency help from security researchers. Run a drill.
Owner: Security lead / operations · When: Drill at least once before launch
| # | Step | Owner | When |
|---|---|---|---|
| 1 | Internal review against known classes | Dev team | Before external review |
| 2 | Test suite with branch coverage | Dev team | Continuous |
| 3 | Invariants and fuzzing | Dev / security | Early, long runs before review |
| 4 | Automated analysis in CI | DevOps | From first commit |
| 5 | External review | Protocol lead | Book 6–12 weeks ahead |
| 6 | Oracle integration checks | Contract lead | Before review |
| 7 | Multisig, timelock, role inventory | Governance | 3 weeks out |
| 8 | Dependency and integration review | Dev lead | 4 weeks out |
| 9 | Fee and withdrawal paths | Product / dev | 2 weeks out |
| 10 | Scripted, rehearsed deployment | Release manager | Final 3 weeks |
| 11 | Public testnet and bug bounty | Release manager | 2–4 weeks out |
| 12 | Verification and docs | DevOps | At deployment |
| 13 | Key management | Security lead | Before first mainnet tx |
| 14 | Tested monitoring and alerts | Operations | 1 week out |
| 15 | Incident response plan and drill | Security / ops | Before launch |
Firepan covers part of steps 1 and 4: repository analysis that combines deterministic checks, HOUND AI review, and best-effort Slither corroboration, with findings tied to files and code paths. Connected GitHub repositories can trigger repeatable analysis on the events you configure. It is not a substitute for an external review of protocol design, or for the on-chain, oracle, multisig, and infrastructure monitoring in step 14 — configure and test those separately. You can start with a free public-repository scan.
Getting ready for a review? See how to prepare for a smart contract audit and smart contract audit cost.
Q: Can I skip the external audit if my automated tools are clean?
A: Not for a protocol holding meaningful value. Automated tools catch known patterns and broken invariants you wrote down; they do not judge business logic, economic design, or integration assumptions. Clean tool output is a prerequisite for a productive review, not a replacement for one.
Q: How long does pre-launch security take?
A: For a non-trivial protocol, plan on two to four months from code freeze to mainnet once you include external review, fixes, re-review, and a testnet period. Booking reviewers early is usually the critical path.
Q: Which checklist items are most often skipped?
A: The operational ones: rehearsed deployment scripts, tested alerting, key management, and an incident drill. They feel less urgent than code review, but misconfigured deployments and compromised keys cause serious losses.
Q: How much does this checklist cost?
A: The largest variable is external review, which depends on scope, complexity, and provider. See the audit pricing pages for current, sourced ranges. Most of the remaining steps are team time and open-source tooling.
Q: Do I need a timelock?
A: For any upgradeable contract or adjustable parameter that can affect user funds, a timelock gives users time to see and react to changes. Pair it with a narrowly scoped pause role for emergencies.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Understand unsafe price-feed consumption, stale and low-liquidity data, oracle trust assumptions, and practical review and mitigation techniques.
Understand missing and incorrect smart contract authorization checks, how to review privileged paths, and how to test role boundaries.
Copy-paste GitHub Actions workflows for Solidity security: Slither with SARIF code scanning, Foundry invariant tests, and Echidna fuzzing — plus how to set failure thresholds without drowning in noise.
An honest, side-by-side comparison of the 9 leading smart contract audit firms in 2026 — CertiK, OpenZeppelin, Trail of Bits, Cyfrin, Sherlock, Spearbit, Hacken, Quantstamp, and QuillAudits — on pricing, model, and what each does best.
Firepan Sentinel, GoPlus, Token Sniffer, Honeypot.is, RugCheck, De.Fi, and Bubblemaps compared: what each rug pull checker looks at, which chains it covers, and how to combine them.