A Solana program is safe to deploy only after someone has checked six things: that every account is the account the instruction expects, that every signer and PDA authority is validated, that cross-program invocations (CPIs) cannot be redirected, that state transitions cannot be replayed or revived, that arithmetic and token inputs are constrained, and that the upgrade authority and the published source match what is on chain. This checklist walks through each area in the order a review should run, with the reason behind every item and the places where the official guidance stops short of a guarantee.
Why Solana reviews start from accounts
On the EVM, a contract can read msg.sender and treat it as the caller. Solana has no implicit equivalent. Every instruction receives an explicit list of accounts, and the program is responsible for deciding whether each account is the one it expects. Most Solana program bugs therefore come down to an account that was accepted without being checked, not to a clever exploit of the runtime. Solana’s official developer guide, which is written for developers migrating from EVM chains and is titled as a security checklist for EVM developers, makes the same point: before deploying a migrated program, check the account model first.
1. Account validation as a connected set
Validate accounts one at a time, then validate how they relate to each other. For each instruction, write down every account and record the following:
- Owner: the program that must own the account.
- Address or PDA derivation: either the exact expected address, or the seeds from which a program-derived address must be derived.
- Data type: the discriminator and the expected data length, so that one account type cannot be passed where another is expected.
- Mutability: whether the instruction writes to it.
- Relationship: which other accounts it must match, such as a vault that must belong to a specific config account.
Once the list exists, check it against the instruction’s purpose. A withdrawal instruction, for example, should fail if the vault it receives is not the vault recorded in the pool account, even if that vault has the right owner and length.
Recommended Free Tools
#1 Best Overall
Two checks catch a large share of the mistakes that follow from this step:
- Require the intended signer, or a PDA that the program has validated, for any authority. A passed-in account that merely claims to be an admin is not an authority.
- Reject duplicate mutable accounts wherever the design needs distinct accounts. If two separate vault or balance accounts are meant to be different, nothing in the instruction should allow the same account to be passed in both positions.
2. Authorization and initialization
Authorization on Solana is an account-level property. Review it along three lines:
- Confirm that each privileged action checks a signer or a validated PDA authority, not only that a stored field equals a value the caller supplied.
- Review initialization helpers for any path that could reinitialize an existing account. This includes any use of
init_if_needed, where an account that already holds state may be accepted as if it were new. - Check that setup instructions cannot be called again by a different party after the intended admin has been configured.
3. CPI boundaries
A CPI hands control to another program, and the trust boundary moves with it. The official CPI documentation at solana.com/docs/core/cpi describes how the caller passes accounts and signing authority into the callee. The checks follow from that model:
- Pin the program ID. The target program must be a fixed, known ID in your code. Solana’s security checklist warns specifically against letting attacker-supplied accounts choose a substitute CPI target. If the program is passed in as an account, compare its address to the constant before invoking it.
- Review the full account list. Look at every account forwarded to the callee and the signer and writable flags attached to each one. Anything marked as signer or writable is something the callee can act on.
- Check PDA signing seeds. When the program signs for a PDA, the seeds must be the intended ones, and the PDA must belong to the calling program. A seed set that is valid for a different program can produce a signature in a context you did not design.
- Treat external behaviour as part of your trust boundary. The callee’s behaviour, and the token-program variant it uses, are part of what your instruction trusts. Document that trust explicitly.
4. Closure, state transitions and arithmetic
- Closure: the close routine must drain lamports and mark the account as closed, so that it cannot be revived later in the same transaction. A closed account that still holds data is a common source of replay-style bugs.
- Reinitialization: confirm that a closed or initialized account cannot be sent back through the setup path.
- Arithmetic: use checked arithmetic for counters, balances, fees and any other value that depends on state. Add explicit bounds where a value has a meaningful maximum, such as a fee rate or a deposit cap.
5. Token flows
Token instructions depend on inputs that look harmless and are not. Before release, check that:
- The mint address is the one the program intends to accept. Do not accept any mint that happens to have the right decimals.
- The decimals match the program’s assumptions, both in calculations and in any conversion between amounts.
- The token-program variant is the one the design expects. Programs that must work with both the original token program and the newer Token-2022 program need to say so, and must test the path they claim to support. Any variant the program does not handle should be rejected.
6. Upgrade authority: a security decision
For a program deployed with the loader-v3 loader, an upgrade authority controls whether the bytecode can change. While an authority is set, the program can be upgraded. The official deployment documentation at solana.com/docs/core/programs/program-deployment describes this model. Setting the authority to None makes the program immutable and removes any future update path.
That is a one-way decision in practice, so the review should answer three questions before deployment:
Rank #4
- Who holds the upgrade authority today, and on what kind of key? A single developer key and a multisig with documented signers carry very different risk.
- How is the key stored, rotated and transferred? Write the process down and confirm it matches the project’s risk model.
- Under what conditions would the team revoke the authority, and what would users lose if it were revoked and a bug was later found?
Retain or revoke: the trade-off in one table
| Question | Keep upgrade authority | Revoke upgrade authority (set to None) |
|---|---|---|
| Can fixes be shipped? | Yes, by whoever controls the authority | No; the update path is removed |
| Who must be trusted? | The authority holder, and the process protecting its key | No upgrade operator; the deployed code is fixed |
| What assurance can users draw? | Depends on key custody and governance, which must be disclosed | Immutability of the deployed code, which is only as good as the code itself |
| Reversibility | Authority can later be revoked | Official guidance treats revocation as final for the program |
The table does not tell you which option is correct. It shows what each choice gives up. A program with a large user balance and no tested fallback may be better served by a retained, well-governed authority, while a narrow program with a thoroughly reviewed design may be better served by revocation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.7. Verified builds: provenance, not a safety certificate
A verified build lets anyone confirm that the bytecode deployed on chain was produced from a specific public source. Solana’s official guide on verifying programs states the limit directly:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11“While a verified build should not be considered more secure than an unverified build, the build enables developers to self verify the source code matches what is deployed onchain.”
In practice, a reproducible verified-build workflow lets users compare the deployed code with the public repository and the exact commit it came from. Re-verify after each deployment or upgrade, following the current official workflow for the toolchain you use. Verification answers one question, whether the source and the deployed bytecode correspond. It does not answer whether the code is secure, and it is not an audit. Say that wording plainly in your public materials, so that users do not read a verified badge as a security assessment.
Running the checklist before deployment
- Inventory every instruction and its accounts, with owner, address or seeds, type, mutability and relationships.
- Confirm a signer or validated PDA for every privileged action, and reject duplicate mutable accounts where distinct accounts are needed.
- Review every initialization path, including any
init_if_neededuse, for reinitialization. - Pin every CPI target to a known program ID and review the signer and writable flags passed to each callee.
- Verify that close routines drain lamports and mark accounts closed, and that arithmetic is checked and bounded.
- Check mint addresses, decimals and token-program variants against the intended design.
- Record who holds the upgrade authority, how the key is stored and transferred, and the conditions for revocation.
- Publish the source, the exact commit and a verified build, with a plain statement that verification is not an audit.
What this checklist does not cover
This list is not exhaustive for every protocol, token standard, framework or threat model. It follows the official Solana documentation, and it does not replace a review of your program’s specific economic design or an independent audit. A specialist security review is a sensible step for any program that holds user funds, and the checklist above gives such a reviewer a concrete starting scope.
The official documentation pages linked above were the reference points for this article. Confirm current behaviour on those pages before you deploy, because the loader, verification workflow and token programs change over time.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
