A pre-launch checklist for shipping smart contracts to mainnet

Shipping a smart contract is not like shipping a web app. There is no hotfix at 2am — once value is locked in an immutable contract, mistakes are expensive and public. Here is the checklist we run before anything reaches mainnet.

1. Access control is explicit

Every privileged function should answer one question without ambiguity: who can call this, and what happens if that key is compromised?

• Owner/admin roles are documented and minimized.
• Multi-sig on anything that can move funds or upgrade logic.
• No forgotten onlyOwner left on a function that should be public — or vice versa.

2. The tests model real adversaries

Happy-path tests are table stakes. We write tests for the attacker:

• Reentrancy on every external call.
• Integer edges and rounding direction.
• Failure modes when a dependency (oracle, bridge, token) misbehaves.

3. There is a monitoring plan before launch

You cannot watch a contract you haven't instrumented. We wire up event indexing and alerts before launch so the first anomaly shows up on a dashboard, not in a user's angry message.

4. The upgrade path is tested, not theoretical

If the contract is upgradeable, the upgrade has been rehearsed on a fork. If it's immutable, the migration story is written down. Either way, "what do we do when we find a bug" has an answer before launch, not after.

Contract flows, wallet UX, permissions, and monitoring planned before launch.

5. A human read the wallet UX

Most "smart contract bugs" users hit are actually wallet-UX bugs: a confusing approval, an unclear gas estimate, a signature request with no context. We walk the full flow as a first-time user before we call it done.

Launching something on-chain? Talk to us about your build.