Treat each accepted mint's extensions as part of your protocol's security model. A successful transfer does not by itself prove that accounting, permissions, and withdrawal behavior are correct.
Inventory the token behavior you support
Solana's Token Extensions Program adds optional mint and account features beyond the original token program. Transfer fees and transfer hooks can affect how an integration processes tokens. Sources 1 and 2 describe the extension model and hook integration. Build an explicit acceptance policy for your application rather than treating every mint as behaviorally interchangeable.
Example: crediting the requested amount
Consider a vault that asks for a transfer of 100 units and credits 100 units internally. For a supported fee-charging mint, verify that the credited amount reflects the assets actually received under the chosen accounting model. Then test the corresponding withdrawal. Define who bears fees on both directions and whether a fee change can leave the vault unable to honor an existing balance.
Follow every account used by a hook
A transfer-hook integration must resolve the extra accounts expected by the hook. The official integration guide explains how these accounts participate in constructing a transfer. For review, provide the supported hook programs, the account-resolution path, and the validation performed before invoking other programs. Test a missing account, an unexpected account, and a change in the hook configuration.
Review authority changes as state transitions
Build a table of mint, freeze, fee, delegate, and upgrade authorities relevant to the supported extensions. Ask whether the protocol intentionally trusts each authority, and what happens to deposited assets if behavior changes. A mint accepted at onboarding can require a different risk decision later; describe whether the integration detects, restricts, or accepts that change.
Do not stop at a happy-path deposit
Test direct and routed transfers, withdrawals after configuration changes, rejected hooks, and mixtures of original-token and extension-token accounts. Track balances before and after each operation. Decide whether unsupported configurations should fail during onboarding or at execution, and ensure the failure cannot leave internal state committed without the intended asset movement.
Audit preparation for Solana teams
Provide program IDs, Anchor or native Rust code, accepted mint configurations, PDA relationships, test fixtures, and deployment authorities. Include the frontend or SDK account builder when it is essential to the intended flow. The scope should explain both the program's assumptions and how transactions satisfy them.
Review Checklist
- Verify received amounts for fee-charging assets.
- Reject unexpected token programs and mismatched mint accounts.
- Exercise hook failures and withdrawals after authority-controlled changes.
Sources and Further Reading
The linked sources describe the standards or research discussed above. Review scenarios are practical planning examples, not findings from an audit of a specific project.
Discuss Your Audit Scope
Start with your email and a short project description. Technical details can follow. Request a smart contract audit quote or review public CTDSEC audit examples.