| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
…s vault A per-owner Anchor vault that holds one volatile token and permissionlessly converts it to a stable token (USDC) once a Switchboard On-Demand price feed reports a price at or below an owner-set threshold. An offchain TukTuk crank calls convert_if_triggered on a schedule; the swap routes through Jupiter v6's shared_accounts_route, with a mock-jupiter program standing in for tests. Instructions: initialize_vault, deposit, update_threshold, convert_if_triggered, withdraw_stables, withdraw_volatile. - token_interface + transfer_checked for every token move, so the vault works against the Classic and Token Extensions programs. - Oracle freshness enforced via MAX_PRICE_STALENESS_SLOTS; owner-only mutations via has_one + PDA seeds. - withdraw_volatile escape hatch so a never-triggered vault never locks funds. - mock-jupiter and mock-switchboard test programs with the real external shapes. - 8 Rust + LiteSVM scenarios; README with a finance primer and a program-flow walkthrough (Alice/Bob/Carol/Dave) naming each handler and the accounts it changes. https://claude.ai/code/session_01UXGGFcK3UWRrcv9UoW1gkJ
| Back | FazBrowse Home | New Git URL |
What this adds
A new tokens/stop-loss-vault/ Anchor example: a per-owner vault that holds a single volatile SPL token (e.g. wSOL) and permissionlessly converts it to a single stable token (e.g. USDC) when a Switchboard On-Demand price feed reports a price at or below an owner-set threshold. The conversion runs from an offchain cranker — typically a TukTuk task — that calls convert_if_triggered on a schedule. The instruction reverts cheaply while the price is above the threshold and only swaps once it has actually dropped.
Architecture
Instructions
Token handling & safety
Why Switchboard On-Demand
On-Demand prices are pulled (not pushed) and verified onchain via Ed25519 signatures, so the price-update bytes travel as an instruction argument and the program trusts them only after verification. That fits a permissionless crank: the cranker pays for the update it wants the program to act on, and the program never trusts the cranker's identity. The teaching example uses a mock-switchboard program exposing the minimum fields the vault reads (price, scale, last-update slot) so tests can drive deterministic price scenarios; production swaps it for the switchboard-on-demand crate and PullFeedAccountData::parse_and_verify.
Why TukTuk
TukTuk is the maintained replacement for the dead Clockwork for scheduling onchain instruction handlers. The vault doesn't enforce the cadence onchain — it records crank_interval_seconds as a hint and stores the TukTuk task pubkey for discoverability. Anyone can crank; in normal operation TukTuk runs the schedule and pays for the price update.
Tests
8 Rust + LiteSVM scenarios under programs/stop-loss-vault/tests/:
Run:
Scope
Limitations (documented in the README and exercised by tests)
https://claude.ai/code/session_01UXGGFcK3UWRrcv9UoW1gkJ