Treat every account as untrusted input
Solana instructions receive accounts selected by the caller. A review should verify ownership, signer status, writability, executable status, expected program IDs, account discriminators, initialization state, and relationships between accounts. Framework constraints help, but reviewers must confirm that they express the complete business rule rather than only type-level checks.
Account substitution is especially dangerous when two accounts share a compatible layout or when an instruction assumes that a token account, authority, vault, or configuration belongs to the expected market. Validate canonical relationships and reject duplicate or aliased accounts when the logic requires distinct state.
Make PDA authority explicit
For every program-derived address, document seeds, bump handling, namespace, lifecycle, and authority. Seeds should bind state to the correct user, market, mint, or configuration without allowing collisions or cross-context reuse. When a PDA signs a cross-program invocation, the derivation becomes an authorization boundary and should be reviewed like a privileged key.
Initialization and closing paths need equal attention. Prevent reinitialization, verify rent and lamport destinations, clear or invalidate state where needed, and ensure that a closed account cannot be reused to bypass one-time checks.
Review CPI as a trust boundary
Cross-program invocations can transfer authority, tokens, and control flow to another program. Confirm the invoked program ID, validate every account forwarded to it, and understand whether remaining accounts can change semantics. Avoid assuming that a caller-provided program implements the intended interface simply because an instruction succeeds.
Token operations should distinguish the original Token Program from Token-2022 and account for extensions, transfer hooks, withheld fees, frozen accounts, delegated authority, and decimal assumptions. Arithmetic and share calculations should use explicit rounding rules and tested boundary values.
Lock upgrades and operations
Record the program upgrade authority, IDL publication path, deployment key controls, multisig policy, emergency procedures, and plan for authority transfer or revocation. A secure program can still be exposed by an uncontrolled upgrade key or by deployment tooling that publishes a different binary than the reviewed source.
Acceptance evidence should connect source commit, reproducible build, test-validator results, deployed program ID, buffer or deployment transactions, verified program data, final authorities, indexer health, and alerting. Operators need a runbook for RPC degradation, failed transactions, stuck workflows, and emergency pauses.
Test properties, not only examples
Unit and integration tests should cover unauthorized signers, substituted accounts, duplicate accounts, invalid PDA seeds, reinitialization, arithmetic boundaries, token variants, CPI failures, and concurrent state changes. Property-based testing is valuable for conservation, monotonicity, and authorization invariants that should hold across many instruction sequences.