Methodology
How a basket becomes a token, and what keeps it honest.
Universe
Eligible holdings are tokenized real-world assets on Solana with a curated entry on tokens.xyz: tokenized equities (xStocks, Backpack Securities, PreStocks), tokenized gold, tokenized ETFs and, where a basket calls for it, Solana-native protocol tokens. Ondo Global Markets tokens and the tokenized-treasury shelf are excluded because they cannot be routed on Jupiter. Each holding is the asset's primary variant as ranked by tokens.xyz (redeemability first, then liquidity, then execution quality). Holdings must have a live on-chain market. Assets flagged with an active advisory (for example a compromised contract) are excluded from new baskets and trimmed from existing ones at the next rebalance.
Weighting
Every basket declares a weighting method in its definition. The method, its data source and its parameters are fixed in pools.json and shown on the factsheet.
| Method | Target weight | Source |
|---|---|---|
| equal | 1 / n, capped | none |
| capWeighted | ∝ public market cap, capped and floored | tokens.xyz canonical market |
| liquidityWeighted | ∝ √(on-chain liquidity), capped and floored | tokens.xyz primary variant market |
| custom | rule-based, documented per basket | as stated on the factsheet |
Caps stop one name from becoming the basket. Floors stop a holding from becoming a rounding error that costs more to rebalance than it contributes. Both are shown as parameters on the factsheet.
Indicative NAV
Until a vault is live, and alongside it afterwards, the site shows an indicative NAV: a constant-mix index that rebalances to the target weights every day, indexed to 100 at the start of the 30-day window, computed from daily closes of each holding's primary on-chain variant (tokens.xyz OHLCV, with CoinGecko for Solana-native tokens that tokens.xyz does not index). Daily rebalancing is what a drift-threshold keeper approximates; a buy-and-hold index would let one runaway holding dominate the print. Constituents without price history are excluded and weights renormalised; the factsheet shows the coverage. The 24h figure is the weight-average of each holding's 24h change from the latest market snapshot, with Jupiter's price API as fallback.
Indicative NAV does not include vault fees, rebalance slippage, or the cash buffer. The vault's realised NAV is what you get when you redeem, and it is always on-chain.
Rebalancing
A keeper monitors each vault. It trades back to target through Jupiter when either condition is met:
- Any holding has drifted more than the basket's
driftThresholdBpsfrom its target weight, or - The scheduled cadence has elapsed (weekly by default).
Each rebalance is a sequence of swaps of at most maxTradeUsd each, sells before buys, largest deviation first, with a slippage limit. Every swap signature is written to the rebalance log on the factsheet. The keeper holds a manager key that can only move assets between the vault's strategies; it cannot withdraw.
Buying and redeeming
A basket's token is the vault's LP token. There are two ways in and two ways out:
- Jupiter. Swap any token for the basket token on the open market. Works as long as there is liquidity in the LP token; the vault keeps a USDC buffer so that redemptions do not require selling holdings.
- Vault. Deposit USDC directly to the vault and receive LP at NAV; redeem LP for USDC at NAV, instantly up to the idle buffer, otherwise after the vault's waiting period.
Fees
Where enabled, the protocol earns a Jupiter platform fee on swaps routed through the embedded terminal, and the vault's issuance/redemption fees as configured on Voltr. Fees are shown on the factsheet when the vault is live. There is no management fee unless the factsheet says so.
Changes
Basket definitions live in a versioned JSON file. Adding, removing or reweighting a holding is a new version with a new generatedAt. The keeper only ever trades to the version the site shows.