The Pre-Mainnet Security Checklist: Don’t Paddle Out Without It

Launch day is exciting. It is also the moment your chain becomes a target. Bridges, admin keys and sequencers are some of the most attractive targets in the entire industry, and many of the largest losses in blockchain history have come from failures in exactly these areas rather than from exotic cryptographic attacks.

This checklist covers the security work every team should complete, or at least consciously decide on, before mainnet. It is not a substitute for professional security help, but it will help you ask the right questions and spot gaps early.

1. Smart contract and protocol audits

Using a standard rollup framework without modification reduces your audit burden, because the core code has been reviewed and is used by many chains. Anything you change or add needs fresh eyes.

• Scope everything custom: custom contracts, precompiles, modified bridge logic, token contracts, governance and any changes to framework code.
• Use reputable auditors with experience in your stack. For high-value systems, consider more than one independent audit.
• Freeze code before audit. Audits of moving targets lose value quickly.
• Fix and re-verify. Ensure auditors review the fixes, and publish final reports.
• Launch a bug bounty. Make rewards meaningful relative to the value at risk, and define clear rules for safe disclosure.

2. Key management

Most chains launch with privileged keys: upgrade keys for contracts, sequencer keys, batch poster and proposer keys, and admin roles for bridges and fee settings. Compromise of these keys can be catastrophic.

• Inventory every privileged key and role. Write down what each can do and who controls it.
• Use multisigs for upgrade and admin functions, with signers who are independent people on separate devices and, ideally, in separate locations or organizations.
• Use hardware security, such as hardware wallets or HSMs, for high-value keys.
• Add timelocks to upgrades so users have time to react to changes.
• Consider a security council with emergency powers that are narrowly scoped and transparent.
• Rehearse signing. Practice routine and emergency multisig operations before you need them.
• Never store production keys in source code, shared drives or chat apps.

3. Bridge security

Bridges concentrate value and complexity, which makes them prime targets. Several of the largest exploits in blockchain history, including attacks on the Ronin, Wormhole and Nomad bridges, involved bridge infrastructure.

• Prefer your framework’s canonical bridge for core deposits and withdrawals, and understand its trust model.
• Vet third-party bridges carefully: how are messages verified, who are the validators or relayers, and how have they been audited?
• Use rate limits and caps during early mainnet phases to limit the impact of any bug.
• Enable pause mechanisms with clear rules about who can trigger them and how they are reversed.
• Monitor bridge flows for unusual withdrawals in real time.

4. Sequencer and node resilience

Most new rollups launch with a single centralized sequencer. That is normal, but you need a plan for when it fails or misbehaves.

• Redundancy and failover: backup sequencers and infrastructure across availability zones or providers.
• Forced inclusion: understand and document how users can submit transactions through the parent chain if the sequencer censors them or goes down.
• Proof system status: know whether fault or validity proofs are live and permissionless on your chain, and communicate this honestly.
• RPC protection: rate limiting and DDoS protection for public endpoints.
• Upgrade discipline: test framework upgrades on testnet first and keep up with security patches.

5. Monitoring and alerting

You cannot respond to what you cannot see. Set up monitoring before you have users, not after.

• Infrastructure health: block production, sequencer lag, batch posting, node sync status and RPC latency.
• On-chain activity: large or unusual transfers, bridge withdrawals, admin function calls and contract upgrades.
• Economic signals: sudden changes in total value locked, oracle prices or liquidity.
• Alert routing: make sure alerts reach a person who is awake and empowered to act, around the clock.
• Public status page: transparency builds trust when things go wrong.

6. Incident response

Every chain will have incidents. The difference between a scare and a disaster is often preparation.

1. Write an incident response plan with severity levels, roles and escalation paths.
2. Prepare a “war room” communication channel and contact list, including auditors, your RaaS provider, bridge partners and major exchanges.
3. Pre-approve emergency actions such as pausing a bridge, and know exactly which keys are needed.
4. Draft communication templates for users and partners so you can publish accurate updates quickly.
5. Commit to post-mortems that explain what happened and what you changed.

7. Operational security for the team

• Enforce strong authentication, including hardware security keys, on all critical accounts.
• Train the team on phishing and social engineering, which remain among the most common attack paths.
• Restrict access to production systems on a need-to-know basis.
• Protect domains, DNS and front-ends, since compromised websites can drain users even when contracts are safe.

Security is not a launch milestone. It is a habit you keep for the life of the chain.

The final pre-mainnet review

Before you open the gates, gather the team and confirm:

• All custom code is audited, fixes are verified and reports are published.
• Every privileged key is inventoried, secured and tested.
• Bridge caps, pause controls and monitoring are live.
• Sequencer failover and forced inclusion are documented.
• Alerts reach on-call people, and the incident plan has been rehearsed.
• Your public documentation honestly describes trust assumptions and the decentralization roadmap.

Find security resources in Tools, study up in our Courses, or let WaveChains help you launch with security built in from day one.