Trident Manifest#
Trident supports its own Trident Manifest, called Trident.toml. This section describes all possible configuration fields.
Fuzzing Metrics#
enabled- Trident will show and save statistics after the fuzzing session.dashboard- Trident will save a HTML dashboard after the fuzzing session.json- Trident will save a JSON file after the fuzzing session.
Regression testing#
enabled- Trident will save a JSON file with all monitored states after the fuzzing session.
Regression testing
- Keep in mind that the feature hashes contents of accounts, if the contents are dependant for example on time, the final hash might not be the same as the one from the first fuzzing session.
Fuzzing Coverage#
[fuzz.coverage]
enable = true # default: false
server_port = 58432 # default: 58432
loopcount = 5 # default: 0
format = "json" # default: "json"
attach_extension = true # default: false
The coverage configuration enables code coverage analysis during fuzzing sessions, providing insights into which parts of your program are being tested.
enable- When set totrue, Trident collects code coverage data throughout the fuzzing session and generates a comprehensive report upon completion.server_port- Specifies the HTTP server port used for communication between Trident and the Solana VS Code extension.loopcount- Defines the number of execution flows processed before generating an intermediate coverage data file. Lower values provide more frequent coverage updates at the cost of performance. When set to0, coverage files are only generated at the end of the fuzzing session.format- Determines the output format for coverage reports. Trident supports bothjsonandhtmlformats.attach_extension- Enables real-time coverage visualization in VS Code when the extension is active. This feature requiresloopcountto be greater than0andformatto be set tojson.
Warning
Coverage is only gathered for the programs deployed through an entrypoint!
Entrypoint deployment guide
- Comment out the program in
Trident.toml - Add the program dependency to
Cargo.toml - Add
syscall-v1orsyscall-v2feature depending on the version ofsolana-program. Programs written forsolana-programv1.x should usesyscall-v1, programs written forsolana-programv2.x should usesyscall-v2feature. - Import the programs entrypoint in
test_fuzz.rs - Deploy the entrypoint in
test_fuzz.rsimpl FuzzTest { fn new() -> Self { let mut trident = Trident::default(); // Deploy through the entrypoint let program = TridentEntrypoint::new(example_program::ID, None, processor!(example_entrypoint)); trident.get_client().deploy_entrypoint(program); Self { trident, fuzz_accounts: FuzzAccounts::default(), } } ...
Programs#
- Use dumped program from desired cluster, during fuzzing.
[[fuzz.programs]]
address = "metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s"
upgrade_authority = "account address goes here"
program = "metaplex-program/metaplex-token-metadata.so"
Accounts#
- Use dumped accounts from desired cluster, during fuzzing.
[[fuzz.accounts]]
address = "6YG3J7PaxyMnnbU67ifyrgF3BzNzc7cD8hPkqK6ATweE"
filename = "tests/accounts/core_bridge_mainnet/guardian_set_5_mock.json"