Tool selection guide
Solana security tools: instruction tests, fuzzing and builds
Solana reviews need explicit account inputs and authorization rules. An instruction may receive the right account address with the wrong signer, owner or writability flags. Choose tools that expose those inputs, and keep binary/source correspondence separate from behavioral testing.
Sources checked . Published example reviewed; no instruction or build was executed.
Use the audit handoff guide to define a Solana audit scope.
Decide what your review needs
- Specify account owners, signers and writable flags for each instruction. Test substitutions that look structurally valid but violate the intended authority.
- Include PDA seed and cross-program invocation assumptions in the review scope. A single-instruction success case is not a full protocol sequence.
- Use stateful generation when the suspected failure needs several instructions or a particular account history.
- Record program ID, deployment slot and upgrade authority when connecting tests to a deployed program. A matching build does not review the upgrade process.
Compare inputs, results and limits
| Tool & access | Input → output | When it fits | Limits & source |
|---|---|---|---|
| Mollusk Solana | Input: A program/instruction with explicit accounts and expected checks Output: Instruction result and account post-state checks | You need focused tests with controlled inputs and assertions about changed accounts. | Compose additional scenarios for interactions across instructions and programs. Documentation reviewed. Official source |
| Trident Solana | Input: Rust fuzzing harness with Solana instructions and account-state generation Output: Campaign outcomes for instruction sequences | You need to explore account interactions and can define valid generation rules. | Meaningful account-state generation and invariants are required to find authorization bugs. Documentation reviewed. Official source |
| solana-verify Solana | Input: Pinned source/build inputs and a program or buffer Output: A comparison between built and deployed binary artifacts | You need source correspondence evidence before interpreting a code review against a deployment. | A matching binary establishes source correspondence, not the absence of vulnerabilities. Documentation reviewed. Official source |
Public artifact walkthrough
Inspect the Mollusk transfer example's post-state checks
Mollusk's README shows a transfer with sender and recipient accounts and checks their resulting lamport balances. The expected changes are separate assertions rather than an inference from a successful return code. For a protocol instruction, extend that idea to the accounts that must not change and to invalid authority inputs. The example's successful transfer does not cover PDA validation or an application's withdrawal permissions.
- List every account supplied to the instruction and the state that the test is allowed to change.
- Add negative cases for a wrong signer, an unexpected owner and a read-only account where writing is required.
- When reviewing deployed code, retain a separate verified-build artifact and its program identity. Do not label that match as a vulnerability test.