Twenty-six checks a Solana program or app should pass before it holds other people’s money. Use it as a gate, not a guide: every unanswered item is a launch risk with a name.
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.
2. Program safety
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.
3. Transaction reliability
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.
4. Operations
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.
5. Launch day
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.
Solana systems
Work you can check
Historical product records and current public scaffolds show work across Solana applications, wallet integration, xNFT surfaces, and supporting product systems.
Is this checklist a substitute for a security audit?
No. It is the preparation an audit assumes. Passing it reduces the findings an auditor spends time on, and the audit itself must come from an independent reviewer you choose.
How long does it take to close the open checks?
It depends on how many are open and whether the answers exist anywhere yet. When the authorities, invariants, and operating owners are undecided, that is the work of an architecture sprint ($5K-$8K). When the program is live and failing operational checks, it is reliability work.
Architecture and delivery sprint · $5K-$8K
Open checks? Settle them before the launch date.
Send the rights you intend to hold, your system of record, who operates it, and the questions you cannot answer yet. We will tell you whether a sprint can turn that into a scope.