iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Solana program is ready for deployment review when, for every instruction, you can state which accounts it trusts, who is allowed to sign, which programs it calls and with what privileges, how state is allowed to change, and who can change the deployed code later. The checks below follow those six questions. They are drawn from Solana’s official developer documentation, including the security checklist in its migration guide, the cross-program invocation (CPI) documentation, the program deployment documentation, and the verified-builds documentation.
Scope of this checklist
Solana’s security checklist sits inside a migration guide written for developers moving from EVM chains, and it is framed as a security checklist for EVM developers. Several of its items, however, concern Solana-specific mechanics such as account ownership, PDA signing, and loader-v3 upgrade authority, so they apply to any native Solana program regardless of background. The list is not exhaustive for every protocol, token standard, framework, or threat model. Treat it as a floor for review, not a substitute for analysis of your own design.
Account validation
Most Solana program bugs begin with an instruction that trusts an account it should have checked. For each instruction, build an inventory of every account it receives and record the following for each one:
Free tools Windows power users keep installed
One-click scans. No signup required.
- Owner: the program that must own the account.
- Address or PDA derivation: the fixed address, or the seeds and bump used to derive the expected PDA.
- Data type or discriminator: the expected account type, and the check that confirms it.
- Data length: the minimum or exact size the program expects before it deserializes data.
- Mutability: whether the instruction may write to the account.
- Relationship to other accounts: for example, that a vault’s token account belongs to the configuration account named in the same instruction.
Validate the set as a whole. Checking each account in isolation misses cases where every individual account is valid but the combination is not, such as a valid vault paired with a valid but unrelated configuration account.
#1 Best Overall
- 🪙 Compact and Sleek Design: Measuring 1.57 inches in diameter and 0.12 inches thick, this gold-plated coin is the perfect size for display or carrying as a token of Solana’s blockchain innovation.
- ✨ Gold-Plated Finish: Crafted with a radiant gold-plated coating that exudes elegance and durability.
- 💡 Iconic Solana Logo: One side features the recognizable Solana emblem, symbolizing decentralized technology and progress.
- 🔄 Geometric Pattern Design: The reverse boasts an intricate geometric design, reflecting the precision and beauty of blockchain technology.
- 🛡️ Protective Plastic Case: Includes a clear coin case to shield against scratches, dust, and fingerprints, keeping your collectible pristine.
Duplicate mutable accounts
Where the design requires two distinct accounts, such as a source balance and a destination balance, or separate vault and fee accounts, reject the case where both arguments refer to the same account. Otherwise one write can silently overwrite the other, or the instruction can credit and debit the same state.
Initialization and reinitialization
Review every initialization path and ask whether it can run against an account that already exists. Pay particular attention to helpers that create accounts only when they are missing, including use of init_if_needed in Anchor-style code. A path that accepts an existing account as if it were new can reset ownership fields, counters, or configuration that users depend on.
Authorization
Solana has no implicit msg.sender. Nothing in the runtime tells your program who initiated a call beyond the transaction’s signatures and the accounts passed in. Each privileged action therefore needs an explicit check:
- Require the authority as a signer, and confirm the signer key matches the stored authority for that account.
- Alternatively, validate a PDA authority by re-deriving its address from the intended seeds, and confirm that the PDA belongs to the calling program.
- Do not accept an authority simply because an account claims to be one. Compare it against state the program controls.
Cross-program invocation (CPI) boundaries
Every CPI hands control to another program with whatever privileges you pass along. Treat each call as a trust boundary and review it in four parts.
Pin the target program ID
Call only the program ID you intend. The official security checklist warns against allowing attacker-supplied accounts to substitute a CPI target. If the program ID is passed in as an account, the instruction must verify that the account’s address equals the expected program ID before invoking it.
Review the account list and privileges
Go through the full account list handed to the callee. For each account, confirm whether it is signed and whether it is writable, and confirm that the callee needs that privilege. A signer that is forwarded to a program that does not need it becomes an unnecessary authority grant.
Rank #3
Check PDA signing seeds
When your program signs on behalf of a PDA, confirm that the seeds used are the intended seeds and that the PDA belongs to the calling program. Seeds that differ in ordering, or that omit a discriminating value, can derive an address that another party also controls.
Treat external behavior as part of the trust boundary
The behavior of the callee, including token-program variants, is part of your instruction’s trust boundary. If your instruction depends on a token program’s transfer semantics, document the variant you expect and reject others.
State transitions and closure
Most account state moves through a small number of transitions: creation, update, and closure. Review each one.
- Creation: see the initialization checks above, and confirm the account cannot be created twice under the same seeds.
- Update: confirm that each update checks the caller’s authority and the current state, not only the new values.
- Closure: the closing instruction must drain lamports from the account and mark its state as closed, so the account cannot be revived later in the same transaction. Closing by draining lamports alone leaves the data intact, and that data can be used again if the account is refunded within the transaction.
Arithmetic and bounds
Use checked arithmetic for counters, balances, fee calculations, and any other value derived from state. In Rust, that means methods such as checked_add, checked_sub, and checked_mul, which return an Option the program must handle, instead of operators that can wrap or panic depending on build settings. Pair arithmetic checks with explicit bounds, such as a maximum number of entries or a maximum fee rate, so that an overflow is not the only thing standing between a value and a bad state.
Token flows
For instructions that move tokens, check three things before deployment:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →- Mint address: the mint the program accepts is the one it intends, usually fixed in configuration rather than taken from the caller.
- Decimals: the program’s arithmetic assumes a decimal scale, and it should either read decimals from the mint or reject mints that do not match.
- Token-program variant: the instruction should accept only the token program it was written for.
Upgrade authority: a security decision
A program deployed with a loader-v3 upgrade authority can be replaced while that authority is set. Setting the authority to None makes the program immutable and removes the ability to deploy future updates. Solana’s program deployment documentation describes this as a deliberate choice, and the choice should be made before launch, not left as a default. You can check the current authority of a deployed program with the Solana CLI command solana program show <PROGRAM_ID>, which lists the upgrade authority.
Best Value
- Solana crypto SOL clothes with Thank Me vintage Sunset SOL coin token design for Solana coin Cryptocurrency fan who solana lovers for family and friends and make a perfect one for dad, mom, men, women, boys, girls and kids who favorite Solana Blockchain
- Sunset vintage retro Solana coin t for blockchain lovers And love Solana Crypto currency or enjoy investing of BTC, ETH, SOL coin token hodler. This SOL Token t is a Great choice for birthday, father's day, mother's day, Christmas, Thanksgiving, Halloween
- Lightweight, Classic fit, Double-needle sleeve and bottom hem
Retain or revoke
The main real choice is whether to keep the upgrade authority or revoke it. The table compares the two.
| Consideration | Keep upgrade authority | Revoke (set to None) |
|---|---|---|
| Can bugs be fixed in place? | Yes, by deploying an upgrade with the authority key | No; a fix requires a new program and a migration plan |
| What users can infer from the deployed code | The code can change at any time by whoever holds the key | The deployed code cannot be replaced by an upgrade |
| Main operational risk | Compromise or loss of the authority key lets someone change the code | A defect found later cannot be patched in the existing program |
| Key-handling requirement | Define who holds the key, how it is stored, and how transfers are authorized | Confirm the revocation is final before executing it |
Decide this against your project’s risk model. A team that expects to iterate on logic needs a controlled upgrade path, with the authority key held and transferred under a written process. A team that prioritizes immutability should revoke only after the code has been reviewed to its satisfaction, because the revocation cannot be reversed.
Verified builds: provenance, not a safety certificate
A verified build lets anyone check that the bytecode deployed on chain matches a public source repository at a specific commit. Solana’s verified-builds documentation describes it this way: “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.”
Use this to give users a reproducible link between the deployed program and its source, and follow the official verified-build workflow when you deploy or upgrade. Re-verify after each deployment or upgrade as the current official workflow directs. Do not describe verification as an audit or a security guarantee. It confirms correspondence between source and deployment, and nothing more.
Verification and the upgrade-authority decision are separate questions. A verified program that retains its upgrade authority tells users what the code was when it was verified, but not what it will become. Record both facts, and the date of each verification, in your release notes.
Sources
- Solana developer guide: migration security checklist
- Solana documentation: cross-program invocation
- Solana documentation: program deployment
- Solana documentation: verifying programs
These sources are current as of the date of publication. Check them again before each release, because Solana’s tooling and documentation change over time.
Quick 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.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute
