Playbook3 sections · 2 min readBy Dezső Mező · Published October 3, 2026.mdSolanaAnchorRustAuditing
Solana's account model is genuinely different: programs are stateless, accounts carry the state, and the runtime trusts you to check who owns what. These are the checks that keep ending up in post-mortems.
01Owner checks are your job
Deserialising an account proves its shape, not its owner. Any program can create an account with an identical layout and hand it to yours. Anchor's owner constraint exists for exactly this; Account<T> does it implicitly, AccountInfo does not.
02Signers are not implied
A field that says admin is data, not a signature. Every privileged instruction needs a Signer on the authority account — the common audit failure is an authority read from the account's data with nothing checking the signature against it.
03Rent, realloc and the account that grew
Reallocating an account changes its lamport balance requirement, and failing to top up rent on realloc is a silent outage for your own users. Size accounts for the data they will actually hold on first write.
What to take away
- Check the owner, not just the shape.
- Privileged calls need a Signer constraint, not an admin field.
- Budget rent when you realloc, not after.
- Fuzz instruction sequences — state bugs hide between calls.
More from the lab
Browse all entries
What Solana RPC actually costs once the prototype works
What custom software actually costs
Custom software or off the shelf — the honest test
Self-hosted n8n or Zapier — where the bill actually differs
Want this looked at on your own system?Start a conversation
