DEV Community: JakeMalarczyk

Solana audit readiness checklist: 12 things to prepare before the audit starts

JakeMalarczyk — Sun, 01 Nov 2026 13:12:04 +0000

An audit is billed in engineer-days. Every day an auditor spends setting up your project or guessing what a function should do is a day not spent looking for bugs. These 12 items are what a well-prepared team hands over before the start date.

Code

[ ] Freeze a tagged commit. Keep new features on a separate branch until the report is final.
[ ] Finish the features in scope. Cut unlaunched features from scope.
[ ] Clean the build: compiles from a clean checkout with pinned Rust, Solana and Anchor versions, and no failing tests.

Documentation

[ ] Write a short spec: for each instruction, what it does, who may call it, which accounts it touches and what it must never allow.
[ ] List your invariants (for example: total supply equals the sum of balances, only the authority can move funds, debt never exceeds collateral).
[ ] Draw the trust model: which keys exist, who holds them, what the upgrade authority can do, which off-chain services the program relies on.

Tests

[ ] Ship tests that run in one command.
[ ] Cover the failure paths: wrong signer, wrong owner, wrong account, zero and maximum amounts.
[ ] Add fuzzing or property tests where money moves.

Process

[ ] Agree scope and exclusions in writing: programs, commit, what is out of scope (frontend, keepers, oracles, key management) and whether the fix review is included.
[ ] Name a developer on call who answers auditor questions within hours.
[ ] Plan the fix window: reserve your engineers for the days after the first report.

Do the spec and invariants first. Writing them often exposes a design problem before anyone is paid to find it.

Full article with FAQ: https://orivions.com/blog/solana-audit-readiness-checklist
All three checklists on GitHub: https://github.com/JakeMalarczyk/solana-security-checklists

Anchor security checklist: 16 checks before your Solana audit

JakeMalarczyk — Sun, 01 Nov 2026 13:11:54 +0000

Anchor turns account validation into declarations, which removes whole classes of bugs. But Anchor only checks what you tell it to check. Run these 16 checks on any Anchor program before sending it to an auditor. This list is preparation for an audit, not a replacement for one.

Accounts and signers

[ ] Use Signer for every account that must authorize the instruction. A plain account or UncheckedAccount is not checked for a signature.
[ ] Tie stored authorities to the signer with has_one or an explicit constraint, for example #[account(mut, has_one = authority)].
[ ] Justify every UncheckedAccount and AccountInfo: validate owner, key or data yourself.
[ ] Prevent the same account being passed twice into two mutable slots, for example from.key() != to.key().

PDAs and initialization

[ ] Validate PDAs with seeds and bump in the account constraint, and store the canonical bump.
[ ] Design seeds so users cannot collide: include the user or the parent account.
[ ] Avoid init_if_needed unless you have a reason, and check it cannot reset balances or owners.
[ ] Close accounts with the close constraint instead of draining lamports by hand.

Tokens and CPIs

[ ] Constrain token accounts by mint and authority (token::mint, token::authority or associated token constraints).
[ ] Use Program<> or Interface<> types for programs you call, so the program ID is checked.
[ ] Decide on Token-2022 support explicitly and review extensions such as transfer fees and transfer hooks.
[ ] Scope PDA signer seeds tightly: separate PDAs for vaults, authorities and configuration.

Math, upgrades and testing

[ ] Use checked arithmetic and keep overflow-checks = true in the release profile. Round in the protocol's favour.
[ ] Validate remaining_accounts by hand: Anchor does no validation on them.
[ ] Plan account layout changes before upgrades: version accounts or reserve space, use realloc carefully.
[ ] Test the failure paths (wrong signer, wrong mint, duplicated accounts, zero and maximum amounts) and fuzz the rest, for example with Trident.

What to do with the results

Fix what you find, write down the invariants your program must always keep, and send both to your auditor with a frozen commit. Before mainnet, also go through the pre-launch checklist in the GitHub repository below.

Full article with FAQ: https://orivions.com/blog/anchor-security-checklist
All three checklists on GitHub: https://github.com/JakeMalarczyk/solana-security-checklists

Solana pre-launch security checklist: 15 checks before mainnet

JakeMalarczyk — Sun, 01 Nov 2026 13:11:36 +0000

An audit is necessary, but it is not a launch plan. Many incidents have nothing to do with a clever exploit in the program: a leaked upgrade key, a compromised frontend, an unaudited last-minute change, or nobody noticing a drain for hours. These 15 checks cover what usually goes wrong around the code. Assign a name to each line: a check without an owner is a check nobody did.

Keys and authorities

[ ] 1. Move the program upgrade authority to a multisig (signers on separate devices, never the development agency).
[ ] 2. Decide your upgrade policy in public: upgradeable, behind a timelock or immutable.
[ ] 3. Review token mint and freeze authorities. Revoke what you do not need, document what you keep and why.
[ ] 4. Audit every admin instruction (fees, pauses, parameters, withdrawals): right signer, controlled by the multisig.

Code and deployment

[ ] 5. Deploy exactly the audited commit. Anything changed after the audit is unaudited code.
[ ] 6. Publish a verifiable build so anyone can confirm the on-chain program matches your public source.
[ ] 7. Test failure paths: wrong signer, wrong owner, duplicated accounts, zero and maximum amounts.
[ ] 8. Rehearse the launch on devnet with production settings, including multisig steps.
[ ] 9. Plan account migrations before you need them: reserve space or version your accounts.

Operations

[ ] 10. Set up monitoring and alerts for unusual outflows, failed transaction spikes, admin instructions and authority changes.
[ ] 11. Use more than one RPC provider, with a fallback and rate limits.
[ ] 12. Protect the frontend and domain: registrar lock, two-factor authentication, restricted deploy access, pinned third-party scripts.
[ ] 13. Write an incident response plan: who can pause, how they reach each other, who talks to users, which partners to call.
[ ] 14. Launch a bug bounty sized relative to the funds at risk.
[ ] 15. Cap risk at launch with deposit caps or rate limits, and raise them as confidence grows.

Verify that deployed code matches the audited code

Build the audited commit and compare it with the program on chain using solana-verify get-program-hash and solana-verify verify-from-repo. Once remote verification succeeds, explorers such as Solana Explorer, SolanaFM and Solscan show the program as verified.

Full article with FAQ: https://orivions.com/blog/solana-pre-launch-security-checklist
All three checklists on GitHub: https://github.com/JakeMalarczyk/solana-security-checklists