feat(scenarios): add native Jupiter v6 support & refactor registry

[tanmay4l]

Problem Surfpool lacked native scenario support for Jupiter v6, preventing users from easily overriding swap states (e.g., TokenLedger). Additionally, the template registry contained duplicated logic for loading protocol overrides.

[tanmay4l]

im not sure if we really need this in surfpool tho

[lgalabru]

so freaking cool thanks so much @TanmayDhobale !
were you able to successfully test it?

[tanmay4l]

so freaking cool thanks so much @TanmayDhobale ! were you able to successfully test it?

so freaking cool thanks so much @TanmayDhobale ! were you able to successfully test it?

Yes Ive verified it in two ways

Unit Tests: Added a suite of tests in
registry.rs
that verifies the Jupiter IDL loads tokenLedger discriminator is correct and the override templates are valid
Integration: verified surfpool starts up successfully with the Jupiter templates registered and ready for use

[MicaiahReid]

This is so awesome, @TanmayDhobale!

Do you have an example token account I can set for the executing the scenario, and what data I can fetch on-chain afterwords to confirm it worked?

[tanmay4l]

@lgalabru, but do we really need this in the surfpool? I’d like to know your vision. we could add more protocols, like Raydium AMM

[tanmay4l]

This is so awesome, @TanmayDhobale!

Do you have an example token account I can set for the executing the scenario, and what data I can fetch on-chain afterwords to confirm it worked?

yea verify it works without needing a live swap transaction and you can simply check that the state override is applied to a dummy address

1. Register this Scenario: (I'm using an arbitrary key 7777... as the 'fake' TokenLedger for testing)

{ "id": "test-jup-override", "name": "Test Override", "overrides": [ { "template_id": "jupiter-token-ledger-override", "values": { "tokenAccount": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", // USDC Mint "amount": 123456789 }, "account": { "Pubkey": "77777777777777777777777777777777777777777777" } } ] }

2. Verify On-Chain: Call getAccountInfo on 77777777777777777777777777777777777777777777. You will see the account data correctly populated with:

Discriminator: [107, 110, 10, 17, 104, 195, 124, 11] (TokenLedger)
TokenAccount: EPjFWdd5... (32 bytes)
Amount: 123456789 (8 bytes, little-endian)

[lgalabru]

Super exciting stuffs, thanks @TanmayDhobale!
Scenarios are going to be essential for generative testing, back testing, etc!