Orivions / Blog / Pre-launch security checklist
Solana pre-launch security checklist: 15 checks before mainnet
By Jakub Malarczyk, Founder, Orivions ·
- Put the upgrade authority and every admin role behind a multisig, never a single hot wallet.
- Deploy exactly the audited commit and publish a verifiable build.
- Revoke token mint and freeze authorities you do not need, and document the ones you keep.
- Set up monitoring, RPC redundancy and an incident response plan before launch day.
- Launch a bug bounty and cap deposits while real usage tests your assumptions.
An audit is necessary, but it is not a launch plan. Many incidents in crypto have nothing to do with a clever exploit in the program itself: a leaked key that held the upgrade authority, a compromised frontend, an unaudited last-minute change, or nobody noticing a drain for hours. These fifteen checks cover what usually goes wrong around the code.
Keys and authorities
1. Move the program upgrade authority to a multisig.
A single hot wallet holding the upgrade authority is a single point of failure. Use a multisig (Squads is the common choice on Solana) with signers on separate devices, and never leave the authority with your development agency.
2. Decide your upgrade policy in public.
Will the program stay upgradeable, sit behind a timelock or become immutable? Users and integrators will ask. Write the answer down before launch.
3. Review token mint and freeze authorities.
If your token is meant to have a fixed supply, revoke the mint authority. If nobody should be able to freeze user balances, revoke the freeze authority. Document whatever you keep and why.
4. Audit every admin instruction.
List every instruction that only an admin can call (fees, pauses, parameter changes, withdrawals) and confirm each one checks the right signer and is controlled by the multisig.
Code and deployment
5. Deploy exactly the audited commit.
Tag the audited commit, confirm all fixes were reviewed, and deploy from that tag. Anything changed after the audit is unaudited code.
6. Publish a verifiable build.
A verifiable build lets anyone confirm the on-chain program matches your public source code. It turns "trust us" into something users and auditors can check.
7. Test failure paths, not just happy paths.
Wrong signer, wrong owner, duplicated accounts, zero amounts, maximum values. Most exploited bugs live in the paths nobody tested.
8. Rehearse the launch on devnet with production settings.
Run the full deployment and initialisation script, including multisig steps, on devnet first. Launch-day mistakes are usually in scripts, not in programs.
9. Plan account migrations before you need them.
If a future upgrade changes an account layout, you need a migration path. Reserve space or version your accounts now; it is far harder later.
Operations
10. Set up monitoring and alerts.
Alert on unusual outflows, failed transaction spikes, admin instructions and authority changes. You want to know about an incident before your users tell you on X.
11. Use more than one RPC provider.
A single RPC endpoint is an availability risk for your frontend and your keepers. Configure a fallback and rate limits.
12. Protect the frontend and domain.
Many drains start with a compromised frontend or DNS, not the program. Enable registrar lock and two-factor authentication, restrict who can deploy the site, and pin third-party scripts.
13. Write an incident response plan.
Who can pause the protocol, how do they reach each other at 3 a.m., who talks to users, and which partners (exchanges, bridges, auditors) need to be called. Decide this while calm.
14. Launch a bug bounty.
An audit covers one commit at one point in time. A public bounty gives researchers a reason to report issues instead of exploiting them. Size rewards relative to the funds at risk.
15. Cap risk at launch.
Deposit caps, rate limits or a guarded launch period limit the damage of an unknown bug while real usage tests your assumptions. Raise limits as confidence grows.
Still choosing an auditor? Start with how to choose a Solana smart contract auditor and what drives audit cost. Terms used here are explained in our Solana glossary.
Frequently asked questions
Who should hold the upgrade authority of a Solana program?
A multisig controlled by several people from your team, not a single hot wallet and never the development agency. When the program is stable, many teams make it immutable or put upgrades behind a timelock.
What is a verifiable build on Solana?
A verifiable build lets anyone confirm that the program deployed on-chain was compiled from a specific public commit of your source code. It builds trust with users and lets auditors confirm that the audited code is the code running on mainnet.
Do I still need a bug bounty after an audit?
For anything holding meaningful user funds, yes. An audit covers one commit at one point in time; a bug bounty gives independent researchers a reason to report issues to you instead of exploiting them.
Need an audit or a security review before mainnet?
Describe your program and launch date. Smart Match suggests verified Solana security firms with a reason for each match. Free for teams.
Find a security partner →Related reading
- How much does a Solana smart contract audit cost? What drives the priceWhat a Solana smart contract audit costs, why quotes for the same project differ, and how to get a better audit for the same budget: scope, complexity, timing and fix reviews.
- How to choose a Solana smart contract auditor: a practical checklistWhat actually matters when picking a Solana auditor: Anchor and native Rust experience, methodology, scope, timelines, red flags in quotes and what a good report looks like.
- Anchor vs native Rust for Solana programs: how to chooseAnchor or native Rust for your Solana program? The real trade-offs in safety, speed of development, compute usage, tooling and hiring, and when each choice makes sense.