test(lk): Lockup Fuzzing test suite by IaroslavMazur · Pull Request #286 · sablier-labs/solsab

IaroslavMazur · 2025-10-29T17:40:54Z

Closes #298

* refactor(lk): stream funder * nitpick comment --------- Co-authored-by: Andrei Vlad Birgaoanu <andreivladbrg@gmail.com>

* feat: more MI campaign data on-chain * remove token decimas from state * test: fix defaultCampaignData() --------- Co-authored-by: Andrei Vlad Birgaoanu <andreivladbrg@gmail.com>

* scripts: just full-check * test: fix code check errors scripts: pr discussion * build: bump deps (#276) chore: run `just full-write` chore: use `forEach` --------- Co-authored-by: Andrei Vlad Birgaoanu <99738872+andreivladbrg@users.noreply.github.com>

andreivladbrg

to be more efficient, i'll leave comments one by one if something catches my attention

would it be possible to place trident-tests under the current tests dir so that we have:

tests/
├── anchor
└── trident

refactor(tests): remove the fuzz_0 dir

IaroslavMazur · 2025-11-04T14:23:38Z

would it be possible to place trident-tests under the current tests dir so that we have:
tests/
├── anchor
└── trident

Thanks for the suggestion!

I've spent some time trying to make the above hierarchy work, tried a bunch of things, but failed to do so, because there seem to be some internal path dependencies rejecting a different folder structure - both for the Anchor tests/ and the trident-tests.

Feel free to give this a try yourself, if you want, though.

andreivladbrg · 2025-11-04T14:25:36Z

i am not familiar with trident, but in case of anchor, they should definitely work by updating the vitest config file with the new path

IaroslavMazur · 2025-11-04T15:06:58Z

i am not familiar with trident, but in case of anchor, they should definitely work by updating the vitest config file with the new path

In the Anchor tests case, there was some issue with the Chainlink test fixture that couldn't be properly configured (I did update the vitest.config.ts).

chore: cargo update

andreivladbrg

since you are still making changes, i am going to leave these comments, and continue adding more

we should add *.fuzz-artifacts in .gitignore file

andreivladbrg · 2025-11-12T12:32:21Z

trident-tests/Cargo.toml

@@ -0,0 +1,19 @@
+[workspace]


do we need this if we have no field configured?

That's, likely, a leftover from the automatic Trident file generation.

We can remove it.

andreivladbrg · 2025-11-12T13:06:21Z

trident-tests/Trident.toml

+  address = "99B2bTijsU6f1GCT73HmdR7HCFFjGMBcPZY6jZ96ynrR"
+  filename = "accounts/chainlink_sol_usd_feed_mock.json"
+
+  # [fuzz.coverage]


since they are commented, can we remove them?

Yes, we can add them again when/if we need the coverage.

andreivladbrg · 2025-11-13T15:51:46Z

trident-tests/fuzz_lockup/test_fuzz.rs

+        self.trident.get_client().warp_to_timestamp(GENESIS.try_into().unwrap());
+    }
+
+    #[flow]


why not create a dir called flows and implement there the logic for each Ix flow ?

this depends on the decision here: #286 (comment)

andreivladbrg · 2025-11-13T15:55:30Z

trident-tests/fuzz_lockup/helpers/lockup_math.rs

it would be a good idea to have a just command to run the trident tests and also autogen this file (and maybe others as well)

Not sure about the auto generation, but the just script has been added in 835a58e

Not sure about the auto generation

it would be similar to the errors & types from the anchor tests

we would need something like this before running trident fuzz run ...:

cp ../programs/lockup/src/utils/lockup_math.rs fuzz_lockup/helpers/lockup_math.rs

I'm open to the idea

andreivladbrg · 2025-11-14T10:46:23Z

trident-tests/fuzz_lockup/test_fuzz.rs

+    #[flow]
+    fn flow_withdraw(&mut self) {
+        // First, create the stream we're going to cancel
+        let (cwt_ix_accs, _) = self.create_with_timestamps();


can't we create streams in the fn start?

That's how it was done in the beginning, until I realized that creating the streams in start() makes it impossible to run flow_create_with_timestamps() - and, possibly, flow_create_with_durations(), as well.

but, how can it initialize the program then?

Program initialization has nothing to do with this, as it only happens once.

The problem here is that the create_with_timestamps()/create_with_durations() fn would be called twice:

both inside start()

and inside its respective flow.

Executing the same Ix twice during a single Fuzz iteration leads to a failure, because fuzzing it a second times yields the same values as the first one (as the fuzzing seed is per iteration, not per ix call).

Executing the same Ix twice during a single Fuzz iteration leads to a failure, because fuzzing it a second times yields the same values as the first one (as the fuzzing seed is per iteration, not per ix call).

let's talk about this in person

andreivladbrg · 2025-11-19T13:38:13Z

trident-tests/fuzz_lockup/instructions/treasury_view.rs

we can remove this

andreivladbrg · 2025-11-19T13:38:31Z

trident-tests/fuzz_lockup/instructions/stream_exists.rs

we can remove this

andreivladbrg · 2025-11-19T15:21:52Z

justfile

lets change the test command to run both anchor & trident tests

and then have individual commands for: test-anchor and test-trident

andreivladbrg · 2025-11-19T15:39:59Z

trident-tests/fuzz_lockup/test_fuzz.rs

+        cancel_ix_accs.stream_data.set_address(cwt_ix_accs.stream_data.pubkey());
+        cancel_ix_accs.stream_data_ata.set_address(cwt_ix_accs.stream_data_ata.pubkey());
+        cancel_ix_accs.stream_nft_mint.set_address(cwt_ix_accs.stream_nft_mint.pubkey());
+        cancel_ix_accs.deposited_token_program.set_address(cwt_ix_accs.deposit_token_program.pubkey());


can't we set all these accounts in the instructions/cancel.rs#InstructionHooks.set_accounts (similar to create tests)?

the objective is simple - make the test_fuzz.rs the entrypoint to the fuzz tests similar to our lib.rs with minimal logic

we would have declared only the:

setup

declaration of flows

exec the tx

The Cancel Ix isn't aware - in its Ix Hooks - of the specific accounts that the Fuzzer has configured the Create Ix with.

At the same time, if we don't configure them manually (using the accs from the Create Ix) and just let the Cancel Ix fuzz them itself, there will, inevitably, be many mismatches resulting in failed Cancel txs (because, e.g. the stream_data accounts in Create and Cancel Ixs are different)

The Cancel Ix isn't aware - in its Ix Hooks - of the specific accounts that the Fuzzer has configured the Create Ix with.

hmm, you sure? can't the accounts can be obtained from FuzzAccounts struct?

can't the accounts can be obtained from FuzzAccounts struct

Tapping into the FuzzAccounts struct inside the set_accounts() Hook is, theoretically, possible, but this'd require:

calling the get_or_create...() fns from the underlining AccountsStorage

and passing the account id, Trident, PDA seeds & the account metadata to it (even though the account has already been created by the Create Ix),

basically, duplicating the account config code from the fuzzed Create Ix.

This doesn't sound reasonable.

Tapping into the FuzzAccounts struct inside the set_accounts() Hook is, theoretically, possible, but this'd require:

wdym?

what is this for then?

solsab/trident-tests/fuzz_lockup/instructions/cancel.rs

Line 56 in c39ffdf

type IxAccounts = FuzzAccounts;

That's just a type wrapper - and it doesn't affect/change what I said above.

andreivladbrg · 2025-11-19T15:47:48Z

justfile

+# Run Lockup fuzz tests
+[group("fuzz")]
+fuzz-lockup:
+    cd trident-tests && trident fuzz run fuzz_lockup


its not a good approach to use cd

it would be better to declare a justfile inside trident-tests for this command: trident fuzz run fuzz_lockup

and then edit this (root justfile) to:

fuzz-lockup: just --justfile trident-tests/justfile fuzz_lockup

for example, take a look how we handle the justfiles in the monorepo

Didn't know that just files can be chained like that.

Sounds good.

andreivladbrg · 2025-11-19T17:38:43Z

trident-tests/fuzz_lockup/test_fuzz.rs

+}
+
+/// Warps to a random timestamp between now and 2x the total stream duration
+fn warp_to_a_random_future_time(trident: &mut Trident, stream_data_pubkey: &Pubkey) -> u64 {


can't we declare this inside the impl FuzzTest? so that we remove the param trident: &mut Trident

andreivladbrg · 2025-11-19T17:54:25Z

trident-tests/fuzz_lockup/test_fuzz.rs

+        );
+
+        // If the withdrawable amount is zero, skip the withdrawal
+        if withdrawable_amount == 0 {


we should never skip the withdrawal since this test logic must ensure on each run a withdrawal happens

with this pattern there are basically discared test runs

we should always warp between: (start + 1, > start + 1)

this point applies to cancel as well

we should always warp between: (start + 1, > start + 1)

This wouldn't be enough to make sure that the withdrawable amount is > 0 at the warped time, because:

there might be a cliff (or not),

the start unlock amount may be 0 (or not),

etc.

Taking this all into consideration and making the time warping dependant on all this just to have 0 discarded test runs is not worth it, imo.

andreivladbrg · 2026-01-09T17:14:44Z

@IaroslavMazur i implemented the 0.12.0 update here: #312

i also added an explanation there for the motivation. would you be ok with merging that PR and then closing this one in its favor, or would you prefer a different approach?

andreivladbrg and others added 7 commits August 28, 2025 15:32

ci: include staging branch in the workflow run

e871c34

refactor(lk): stream funder (#255)

abcd292

* refactor(lk): stream funder * nitpick comment --------- Co-authored-by: Andrei Vlad Birgaoanu <andreivladbrg@gmail.com>

feat: more MI campaign data on-chain (#254)

96a14ae

* feat: more MI campaign data on-chain * remove token decimas from state * test: fix defaultCampaignData() --------- Co-authored-by: Andrei Vlad Birgaoanu <andreivladbrg@gmail.com>

just full-check (#265)

3744fa2

* scripts: just full-check * test: fix code check errors scripts: pr discussion * build: bump deps (#276) chore: run `just full-write` chore: use `forEach` --------- Co-authored-by: Andrei Vlad Birgaoanu <99738872+andreivladbrg@users.noreply.github.com>

refactor: cancel error msg (#282)

5196b85

style: set wrap_comments to true

c8cf9e9

test(lk): Lockup Fuzzing test suite

3588288

IaroslavMazur requested a review from andreivladbrg October 29, 2025 17:40

andreivladbrg reviewed Oct 30, 2025

View reviewed changes

fix(tests): token balances invariant at create stream

4a2fe5c

refactor(tests): remove the fuzz_0 dir

IaroslavMazur added 3 commits November 19, 2025 16:52

fuzz: update program id

e8fe353

chore: cargo update

chore: add fuzzing to just & CI

835a58e

chore: ignore .fuzz-artifacts/

dd7ead7

andreivladbrg requested changes Nov 19, 2025

View reviewed changes

ci: install Trident

c39ffdf

andreivladbrg reviewed Nov 19, 2025

View reviewed changes

andreivladbrg force-pushed the staging branch from c8cf9e9 to 787c1da Compare January 9, 2026 10:42

andreivladbrg mentioned this pull request Jan 9, 2026

test: fuzz trident 0.12.0 tests #312

Open

Conversation

IaroslavMazur commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

andreivladbrg left a comment

Choose a reason for hiding this comment

Uh oh!

IaroslavMazur commented Nov 4, 2025

Uh oh!

andreivladbrg commented Nov 4, 2025

Uh oh!

IaroslavMazur commented Nov 4, 2025

Uh oh!

andreivladbrg left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andreivladbrg Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andreivladbrg Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IaroslavMazur commented Oct 29, 2025 •

edited

Loading

andreivladbrg Nov 19, 2025 •

edited

Loading

andreivladbrg Nov 19, 2025 •

edited

Loading