Solana’s execution model is fast, parallel, and very different from EVM chains. That speed comes with a new set of failure modes. “Token audits” on Solana therefore need to look beyond surface-level checks. They must verify the token’s mint configuration, the way your programs use SPL Token or Token-2022, the safety of cross-program calls, and the operational controls around upgrades and keys. Done well, an audit prevents catastrophic bugs (like infinite mints), reduces governance and upgrade risk, and boosts credibility with users, exchanges, and partners.

This piece lays out a pragmatic, research-backed view of Solana token audits: the architecture auditors examine, the classes of vulnerabilities they try to catch, the extensions that need special scrutiny, and the governance decisions that can make or break trust. Along the way, we use concrete examples from real incidents and official guidance so you can align your implementation and your audit scope with what actually matters.

1) What a “token” is on Solana (and why that matters in audits)

On Solana, a “token” is not a monolithic contract. It’s state held across two canonical programs:

1. SPL Token (Token Program) — the original, battle-tested program used by most fungible tokens and NFTs. Its program id (Tokenkeg…) is not upgradeable.

2. Token-2022 (Token Extensions Program) — a superset of SPL Token that adds optional extensions like transfer fees, transfer hooks, permanent delegates, confidential transfers, default frozen accounts, and more. It’s widely audited and actively developed. Many wallets, DEXes, and infra now support it.

Every holder’s balance sits in a Token Account (often an Associated Token Account, ATA) derived deterministically from owner + mint + token program id. That last term is easy to miss: if you use Token-2022, you must pass the Token-2022 program id when deriving or verifying ATAs—or you’ll point at the wrong address and break assumptions. Auditors check this religiously.

Audit takeaway: many Solana “token bugs” aren’t in the token program at all—they’re in your program’s use of it: wrong program id, weak account validation, or dangerous extensions you didn’t fully model.

2) Core code-level checks auditors perform on Solana token integrations

Solana token development programs are attacker-supplied-accounts by default. Auditors therefore focus on proving that you only act on the exact accounts and authorities you intend. Expect scrutiny in at least these areas:

a) Account identity & ownership checks

1. Verify each passed account is the expected PDA or address: require_keys_eq! or Anchor has_one constraints; confirm owner is the right program (e.g., SPL Token or Token-2022).

2. Confirm token accounts match both the expected mint and authority (mint authority, freeze authority). Don’t assume “the wallet is the owner”; prove it in code.

b) Signer & privilege checks

Use explicit signer constraints (#[account(signer)], Signer types) for any action that changes state or moves funds. Anchor reduces boilerplate, but you still need to assert relationships between accounts and signers.

c) Program-id pinning for CPIs

When invoking other programs (Token, Associated Token, Metadata, etc.), verify you’re calling the real program id—never a user-supplied one. This avoids “arbitrary CPI” attacks where a malicious program is invoked in place of the real one.

d) ATA derivation and Token-2022 support

Derive and check ATAs with the correct token program id. Mixing SPL Token and Token-2022 breaks invariant checks and can strand balances. Auditors test both happy and unhappy paths.

e) Reallocation (realloc) safety

If you resize accounts (common with Anchor’s realloc), bound the new size, zero-init new bytes where required, and set the payer correctly. Audit findings often flag unchecked realloc growth or missing zeroing which can leak or corrupt state.

f) Signature verification via syscalls

If you verify off-chain signatures in-program (ed25519/secp256k1) using the instructions sysvar, ensure you’re reading this transaction’s verification instruction and validating arguments. Auditors look for brittle instruction-index assumptions.

g) Arithmetic & bounds

Overflow/underflow is rarer in Rust with checked types, but rounding and rate caps still bite tokenomics. Auditors cross-check fee math and supply caps against whitepaper invariants.

h) Rent, lamports, and closing semantics

Ensure rent-exemption where expected and safe closing of token accounts to prevent lamport loss or griefing. Anchor helps, but you must still model close-paths.

3) Token-2022 extensions: power tools that demand careful audits

Token-2022 is excellent precisely because it lets you compose features formerly implemented as fragile custom code. The flip side: these extensions carry real authority and operational risk. A thorough token audit will ask “Should we enable this?” and “If yes, how do we bound it?”

Permanent Delegate

What it does: grants a key unlimited delegate rights over all token accounts for the mint (burn or transfer any amount).
Audit focus: who controls it, how it rotates, and how you communicate this to users and integrators. Attackers and scammers have abused delegate-like powers to burn or seize tokens. If you need it (e.g., compliance use cases), wrap it with process controls and public disclosures.

Transfer Fees

What it does: hooks native fee logic into transfers.
Audit focus: fee bounds, rounding, mint authority controls, and any pathways to bypass fees. Real audits have uncovered critical fee-bypass issues in the past.

Transfer Hooks

What it does: lets a custom program run during transfers (think allowlists, loyalty, compliance).
Audit focus: hook program id pinning, extra accounts, reentrancy-like patterns via CPIs, and DoS risks if hooks fail. Compatibility with DEXs/wallets also matters.

Default Account State (Frozen by default)

What it does: forces new token accounts to start frozen.
Audit focus: unfreeze workflows, authority separation, and incident playbooks so you can actually recover from mistakes without freezing the entire holder base unintentionally.

Confidential Transfers (ZK)

What it does: privacy-preserving balances/transfers with ZK proofs.
Audit focus: proof verification, auditor role (if configured), and upgrade posture of the underlying ZK programs. Privacy adds complexity—and complexity adds risk—so auditors go deep on verification assumptions and fallback behavior.

Big picture: Token-2022 has gone through multiple independent audits (Halborn, Zellic, NCC, Trail of Bits, OtterSec), but your threat model still depends on your authority settings and operational process. Audit both.

4) Case studies: what goes wrong without the right checks

Cashio (2022): “infinite mint” via missing validation

A Solana stablecoin, Cashio, lost ~$52M after an attacker bypassed collateral verification and minted unlimited tokens. Root cause: missing owner/validity checks in mint logic—an archetypal “implementation bug” an audit should catch. (Cashio had not undergone a third-party audit.) Lesson: for any mint or mint-adjacent logic in your codebase, assert every account relationship and authority, then try to break it.

Mango Markets (2022): oracle manipulation

Mango’s loss (>$110M) stemmed from economic design: the protocol used an oracle and collateral model that allowed a trader to pump the MNGO price off-protocol and borrow against the inflated value. Not a line-by-line bug (mostly)—but still in audit scope as a systems and market risk. Token audits that touch lending, staking, or DEX logic must include manipulation scenarios, not just Rust safety.

Bottom line: audits must cover both implementation risks (e.g., missing authority checks) and economic risks (e.g., oracle or liquidity assumptions). Solana’s exploit history shows both classes matter.

5) Upgradeability, governance, and key management: the trust layer

Even flawless code can be undone by sloppy upgrade controls. Auditors ask:

1. Who holds the program upgrade authority? Best practice is a well-documented multisig (e.g., Squads) or DAO governance once mature. Confirm the authority on-chain, and plan an eventual path to renouncing or decentralizing it.

2. How are upgrades executed? Many teams temporarily move authority to a hot key to deploy, then move it back—dangerous if mishandled. Have a hardened, reviewed procedure. The Solana community has flagged “set-upgrade-authority” foot-guns; automation via multisig or CI actions reduces risk.

3. Is the token program itself upgradeable? SPL Token is not (owned by BPF Loader 2), while Token-2022 is maintained under active security review. Your audit should document these facts for stakeholders.

4. Is emergency control scoped? If you enable freeze, clawback, or permanent delegate, define who can use them, under what process, and what gets logged/announced. Users and integrators must know the rules.

Auditors also review DAO setups (e.g., SPL Governance/Realms) when they control upgrades or treasuries: voting thresholds, council powers, and how minor program updates are handled.

6) What “good” Solana token audits actually do

Different firms use different playbooks, but you’ll see common phases:

1. Threat modeling & scoping
   Map token flows (minting, burning, transfers), authority surfaces (mint/freeze/permanent delegate), and integrations (DEXs, bridges, wallets). Include market and oracle assumptions if your token is embedded in lending or AMM logic.

2. Manual code review
   Most time is spent here: auditors read every line, write proofs of invariants, and try to violate them. They check Anchor constraints, custom validation, CPI calls, instruction data parsing, and extension configurations.

3. Property-based testing & fuzzing
   They add tests to assert invariants (e.g., “supply can never exceed cap,” “fees never exceed max,” “hook cannot bypass policy”), then fuzz inputs and account sets.

4. Adversarial integration testing
   They compose your token with third-party programs (DEXs, vaults, bridges), try mis-deriving ATAs (wrong program id), and simulate high-load/low-liquidity scenarios. If you use Token-2022 hooks or ZK, they test failure modes and DoS conditions.

5. Operational review
   Key storage, upgrade process, multisig setup, alerting, and runbooks. Many credible reports now include explicit operational findings.

6. Clear findings with impact & likelihood
   Good reports categorize by severity, explain exploitability, and provide concrete remediations—then verify fixes.

7) A practical audit checklist for Solana tokens

Use this to prepare your code and to guide your auditor:

Mint & authorities

1. Document decimals, hard caps, and supply sources.

2. Prove who holds mint and freeze authority; rotate or nuke as appropriate post-launch.

3. If using permanent delegate, define rotation, monitoring, and public disclosures.

Accounts & derivations

1. For every token account you touch, assert account.mint == expected_mint and account.owner == expected_owner.

2. Derive ATAs with the correct program id (SPL vs Token-2022). Include negative tests for the wrong id.

Token-2022 extensions

1. For transfer fees: cap math, rounding, and fee-exempt paths.

2. For transfer hooks: program id pinning, extra metas validation, failure policy & DoS analysis.

3. For confidential transfers: proof verification, auditor role, and upgrade posture.

Instruction & CPI safety

1. Pin program ids for all CPIs (Token, ATA, Metadata, custom hooks).

2. Validate signers and bump seeds; assert PDAs with seeds/bump and owner constraints.

Realloc & state growth

1. Bound realloc sizes; zero-init; set payer; test shrinking/expanding.

2. Add property tests for serialization changes across versions.

Governance & upgrades

1. Move upgrade authority to a multisig (or DAO when ready).

2. Script and review the full upgrade flow; avoid ad-hoc hot-key transfers.

3. Publish a public “security & controls” page stating who can freeze/upgrade and how emergencies work.

8) How to choose an auditor (and set them up to succeed)

Look for a track record on Solana and clear methodology. Trail of Bits, OtterSec, Zellic, Halborn, NCC, and others publish Solana-specific research and reports; reading those gives you a sense of the depth you should expect. Avoid one-size-fits-all EVM checklists; Solana has different foot-guns.

Before the engagement:

1. Ship invariants with code. Write down what must hold true (supply caps, fee limits, who can freeze, etc.). Auditors turn these into tests.

2. Max out test coverage. Include negative tests: wrong token program id, wrong mint, forged PDA bumps, malicious hooks.

3. Provide diagrams and scripts. Give runbooks for upgrades, key rotations, and emergency freezes.

4. Stage realistic scenarios. If your token plugs into lending or DEXs, stage low-liquidity environments and oracle delays—ask the auditor to try to manipulate them.

9) Continuous assurance: audits are a starting line, not a finish line

Security on Solana evolves fast. In addition to periodic audits:

1. Monitor authorities and mints. Alert if mint/freeze/permanent delegate authorities change or are exercised.

2. Track extension compatibility. Hooks and fees can break dApp UX; integrate with major wallets/DEXs and test against their Token-2022 support.

3. Adopt defense-in-depth. Bug bounties, multisig-gated upgrades, staged rollouts, and “canary” mints in devnet.

4. Stay current with incident write-ups. Many issues repeat across protocols; study them and harden before they hit you.

10) Putting it together: a model audit scope for a Solana token

A strong statement of work will read something like this:

1. Architecture & threat model review of token lifecycle and authorities (mint/freeze/permanent delegate), with explicit analysis of Token-2022 extensions in use.

2. Manual code review of all program logic touching token accounts, including ATA derivation with the correct program id, CPI pinning, signer/owner checks, and PDAs.

3. Property tests & fuzzing for supply invariants, fee bounds, and extension semantics; realloc safety tests with zero-init and size caps.

4. Adversarial integration tests across wallets and DEXs (including Token-2022 paths), plus economic stress tests if used in markets or lending.

5. Governance & operations review of upgrade authority (multisig/DAO), documented upgrade runbooks, rotation procedures, and public-facing security disclosures.

Conclusion

On Solana, “token security” is half program correctness and half operational control. The code must prove, at every step, that the right account performed the right action through the right program id, with clear limits on supply and fees. And your organization must prove it can’t silently change the rules without oversight. That’s why serious Solana token audits dig into both: they validate account and signer checks, CPI hardening, realloc safety, and Token-2022 extension semantics—and they also verify who can freeze, seize, or upgrade, and how.

Incidents like Cashio’s infinite mint highlight how a single missing validation can zero a token; Mango shows that clean code can still fail if the economic model invites manipulation. A good audit treats both as first-class risks. If you pick an experienced Solana auditor, prepare thoroughly, and keep monitoring after launch, you can ship tokens that hold up under real adversaries—and earn user trust where it counts: in production.