Interactive Solana launch checklist

Most Solana losses in 2026 traced to who could sign, not to a bug in an instruction. Write down every authority, who holds it, and how it changes hands.

• Every upgrade, mint, freeze, and admin authority is listed with its holder and a rotation procedure.
• Privileged authorities sit behind a multisig with a stated threshold, and the signers are named people, not shared accounts.
• Durable nonces, delegated signers, and session keys are either unused or documented with their expiry.
• A compromised-key runbook exists: who revokes, who pauses, and in what order.
• The upgrade authority is either burned on purpose or protected, and the choice is recorded with its reasoning.

Checks that a third-party audit will run first. Passing them before the audit makes it shorter and cheaper; failing them after launch is an incident.

• Every account is validated for owner, signer, writable, and expected PDA seeds; no instruction trusts a passed-in account.
• Arithmetic on balances uses checked operations, and overflow paths are tested.
• Cross-program invocations name the program id they expect and verify it.
• Economic invariants (total supply, vault balance equals claims, fee bounds) are written as tests, not comments.
• Close-account and reinitialization paths cannot be replayed to drain or revive state.
• An independent review is scheduled, with time reserved for remediation and re-review.

A correct program with a flaky client still loses users. These checks cover the path between a click and a confirmed slot.

• Priority fees are set from recent fee data, not a constant, and have a ceiling.
• Transactions are idempotent on retry: a resend after a timeout cannot double-settle.
• Confirmation is tracked to the commitment level the product needs, and the UI shows the difference between sent, confirmed, and finalized.
• RPC has a fallback provider, and the failover was exercised, not just configured.
• Compute budget and account-size limits were tested at the largest realistic input.

Launch is the start of operating cost. These checks decide whether the first incident is a page or a surprise.

• Alerts exist for failed transactions, authority use, vault balance drift, and RPC error rate, and someone is named to receive each one.
• Indexing and reconciliation can rebuild state from the chain, and the rebuild was run once.
• A pause or circuit-breaker path exists for the actions that move value, and it was tested on devnet.
• Logs and dashboards show the questions support will ask on day one: which transaction, which account, which error.
• Secrets, deploy keys, and RPC credentials live in a managed store with rotation, not in a repository or a laptop.

The last five checks are about people and sequence rather than code.

• A written launch sequence names each step, its owner, its verification, and its rollback.
• The program was deployed and exercised on devnet or a mainnet fork with the exact launch sequence.
• Value is capped for the first window (deposit limits, allowlists, or a soft launch) and the cap has a planned removal date.
• Public addresses, program ids, and verifiable builds are published so users and auditors can check what is live.
• The incident channel, the on-call person, and the communication template exist before the first user arrives.