Before You Launch: The DeFi Mainnet Security Checklist
Mainnet is a live-fire security exercise. The moment contracts go live, your assumptions face adversarial creativity. Attackers don’t need adoption to start. They need a target, a mempool, and time.
A “secure launch” has three outcomes:
- your deployed code matches what was audited and tested
- your blast radius is deliberately limited on day one
- you can detect and contain failure fast, without improvising under pressure
This checklist is built for teams shipping real value. Use it as a pre-launch gate, not a postmortem template.
1) Freeze scope and map the full attack surface
Teams get hurt by what they didn’t include. Before you schedule any audit, write down what “the system” is.
Include:
- Smart contracts: core, periphery, libraries, upgrade modules, governance, pausers
- Deployment and ops code: scripts, migrations, configuration, permission manifests
- Offchain components that influence state: keepers, relayers, oracle pipelines, automation
- App surface: frontend transaction construction, wallet flows, APIs, indexers
- Admin workflows: key custody, signing policies, role transfers, emergency actions
Done means: you can point to every component that can move value or change protocol behavior, and it is explicitly in or out of scope.
2) Audits are non-negotiable, and coverage matters more than the badge
Do not deploy unaudited code that can move funds or change critical parameters. For high-risk systems, one audit pass is rarely enough.
What “good” looks like:
- At least one reputable independent audit on the production version
- A second set of eyes on novel primitives, complex math, and new integrations
- Clear scope that includes upgrade paths, governance controls, and privileged roles
- Audit-to-deploy parity: deployed bytecode matches the final audited commit
- A plan for change: what triggers a re-audit or a targeted re-review
Done means: you can show the audited commit hash, the deployed commit hash, and the diff is empty on critical paths.
3) Testing that matches adversarial reality
Audits reduce risk. Tests keep you honest.
Minimum bar:
- Unit tests for all critical functions and edge conditions
- Integration tests for multi-step user flows and cross-contract interactions
- Fork tests against a mainnet fork to catch real-world state assumptions
- Fuzzing and invariant testing for accounting, permissions, and oracle assumptions
- Negative testing for failure modes: reverts, partial fills, rounding, underflows, stale reads
Done means: you have explicit invariants written down and verified in tests, and you can reproduce your most dangerous scenarios on demand.
4) Model privileges as a graph, then harden it
Most catastrophic losses route through privileges: upgrades, pausers, fee setters, oracle setters, allowlists, treasuries.
Before launch:
- enumerate every privileged action
- document who can perform it, how, and under what constraints
- trace admin transfers and role escalation paths
- remove dead roles and unused admin functions
- set up separation of duties where it matters
Done means: you can answer “what is the shortest path to upgrade, pause, drain, or change oracle sources” without hand-waving.
5) Use multisigs, timelocks, and realistic signer workflows
Controls that look strong on paper fail when the process is messy.
Pre-launch requirements:
- critical privileges behind a multisig with an appropriate threshold
- timelocks for upgrades and high-impact parameter changes
- hardware-backed signing where possible
- explicit signer procedures for “normal,” “urgent,” and “emergency” operations
- a tested recovery plan for signer loss or suspected compromise
Done means: you’ve executed the real workflows on a realistic staging environment, including failure cases.
6) Plan a guarded launch that limits blast radius
A full-open mainnet launch is an avoidable risk. You can prove safety while controlling exposure.
Options that work:
- deposit caps that scale up over time
- pool-by-pool enablement
- allowlists for early access
- circuit breakers tied to invariant breaks
- delayed activation of sensitive features (upgrades, leverage, new collateral types)
A practical rule: align early caps with your maximum acceptable loss, not your growth target.
Done means: you can explain exactly how you prevent a Day 1 bug from becoming a protocol-ending event.
7) Monitoring and alerting from block one
Impact-based alerts fire when funds move. That’s late. You want behavioral signals that show mapping and rehearsal.
Monitor:
- invariant breaks (accounting, collateralization, rate bounds)
- privileged events (role changes, upgrades, pausing, oracle source changes)
- abnormal call patterns (repetitive failures, parameter sweeps, alternating success/revert)
- oracle deviations and thin-liquidity windows
- sudden changes in user flow behavior
Done means: alerts reach a human who can act, with a defined escalation path.
8) Incident response is a launch requirement, not a maturity goal
If you don’t know who can pause at 3AM, you don’t have incident response.
Before launch:
- write a runbook with decision rights, escalation order, and comms ownership
- rehearse a live drill: detect → verify → pause → communicate → remediate
- prepare templates for user comms and stakeholder coordination
- pre-build relationships with key ecosystem partners (infra providers, relevant security contacts)
Done means: you can execute containment in minutes, not hours.
9) Ship incentives that bring the right adversaries early
You want skilled attackers to be paid to disclose, not rewarded to drain.
Before or at launch:
- run a bug bounty with clear scope, severity tiers, and fast triage
- consider a competition for burst coverage on complex systems
- publish a security contact and disclosure process that works
Done means: you can receive, validate, and act on reports without blocking your engineering team.
10) Publish the transparency pack
Trust is earned with evidence.
Publish:
- contract addresses and verification links
- audit reports and remediation notes
- admin controls and upgrade policy
- known risks and assumptions
- a security contact and reporting process
Done means: external reviewers can validate what users are interacting with and how the protocol can change.
One-page launch gate
If you want a single pre-launch “go/no-go” page, use this:
- Audited production commit, with deploy parity on critical contracts
- Tests cover critical flows, with explicit invariants and fuzzing/invariant checks
- Privilege graph documented and hardened, no unknown admin paths
- Multisig + timelock live, signer workflows rehearsed
- Guarded launch plan with caps and circuit breakers
- Monitoring live with behavioral alerts and on-call coverage
- Incident response runbook written and drilled
- Bounty or competition live, with fast triage
- Transparency pack published: addresses, controls, reports, contacts
Need help before you ship?
Cantina supports the full security lifecycle: threat modeling, audits (Web3 and Web2), bug bounties, managed detection and response, and Web3SOC for institutional diligence.
Talk to us about your secure launch plan:.