Protocol guide
How SolBasket works
A plain-language view of vault ownership, basket shares, deposits, redemptions, management delays, and the boundaries between on-chain rules and interface estimates.
Basket vaults
Each basket has a unique program-derived vault authority. Assets are held in canonical token accounts associated with that authority; managers and governance do not receive an arbitrary withdrawal instruction.
Shares and deposits
An exact-share deposit transfers the proportional underlying quantities before Token-2022 shares are minted. Normal issuance uses vault balances and circulating share supply—not a USD price.
In-kind redemption
Redemption burns an exact share quantity and transfers floor-rounded proportional assets to the holder’s canonical token accounts. This path cannot be disabled by deposit, rebalance, manager, API, pricing, or keeper pause state.
Estimates and routing
Jupiter prices inform UI estimates only. Convenience swaps are optional and separately reviewed. Missing prices remain unavailable, while underlying token quantities continue to be displayed.
Managed changes
Material managed-fund changes commit to a canonical on-chain hash and wait through a configured delay. Holders can inspect pending changes and redeem during the delay.
Deployed addresses and audit scope
This interface publishes a program address only from the active runtime configuration and verifies basket ownership against that exact address by direct RPC. No mainnet deployment address, upgrade-authority state, or independent audit scope is claimed when those records are unavailable. Before mainnet activation, the exact program address, deployment slot, binary hash, source commit, upgrade authority, and any independent audit scope must be published together here.