Deploy-Day Checklist
Before broadcasting a deploy: verify everything. Bytecode verification, parameter freezes, timelock setup, monitoring, runbooks, and the mistakes that have cost protocols nine figures.
30 min · expert · part of Solidity & Smart Contract Development
Why Deploy-Day Has Its Own Checklist
Deploys are the riskiest event in a smart contract's lifecycle. The code you've spent months auditing is finally exposed to mainnet, where every mistake costs real money and many are unfixable. Almost every nine-figure DeFi exploit in the post-2021 era has had a "we deployed wrong" component — either the deployment script had a bug, or the parameters were wrong, or critical setup steps were skipped, or the deployer's keys were stolen.
This lesson is the checklist. None of these items are clever; all of them have been forgotten by real protocols, with real consequences.
The checklist comes in four phases:
1. **Pre-deploy** — everything you do before broadcasting the deploy transaction.
2. **Deploy** — the actual broadcast, ideally automated and reproducible.
3. **Post-deploy verification** — confirming the contract is in the state you expected.
4. **Monitoring & response** — what runs continuously after launch.
The temptation is always to skip steps under time pressure ("just ship it, we can fix it later"). The lesson from every post-mortem you'll read: there is no "later" for the worst class of bugs.
Also in this lesson
- Pre-Deploy: Lock the Build
- Deploy: Reproducible and Verified
- Post-Deploy: Confirm Everything
- Monitoring and Incident Response
- The Mistakes That Have Cost Protocols Nine Figures
Key terms
- Bytecode Verification
- Confirming the bytecode at a deployed address byte-matches what your build produces. Catches build-config drift, wrong commit deployed, deploy-script bugs. Should be automated in every deploy.
- Front-Run Initialization
- Attack on upgradeable proxies: between deploy and initialize, anyone can call `initialize` and become admin. Prevented by atomic deploy-and-initialize (single transaction), which Foundry's Upgrades plugin does by default.
- Timelock Controller
- A contract that holds admin powers and enforces a delay (typically 24-48 hours) between proposing an action and executing it. Gives users time to exit if they don't trust the proposal. Standard for any non-trivial admin power.
- Multisig (Gnosis Safe)
- A contract that requires M-of-N signatures to execute any transaction. Standard custody for protocol admin keys. The threshold M is a trust-vs-availability trade-off — 3-of-5 is common.
- Bug Bounty
- A pre-arranged reward program for responsibly-disclosed vulnerabilities. Channels white-hat research toward you instead of toward black-market exploit buyers. Should exist before launch, not after the first incident.
- Runbook
- A written incident-response document. Specifies trigger conditions, decision-makers, communication channels, pause/unpause criteria, post-mortem templates. Written before incidents, not during.
- Kill Conditions
- Predefined automated triggers that cause an emergency pause. Examples: TVL drop >X% in an hour, single tx draining >Y% of treasury, oracle staleness >Z minutes. Better than human-paged reaction time.
Continue this lesson — 5 more sections in the CryptoBipto app.
Open lessonEducational only — not financial advice.