BASALT / PROTOCOL DOCS
Documentation
How Basalt works — the mechanics, the fees, the risk, verifiable on-chain.
Seven short sections, written to be read. Every number on this page is enforced by a program, not asserted by us — where a value is a constant, it is the same constant the client builds transactions with, imported straight from the source.
> 01 — WHAT THIS IS
Basalt is three Solana programs — a whitelist, a basket factory, and a basket program — that hold tokenized equities and issue one share token per basket. The equities are xStocks: Token-2022 tokens issued by Backed Finance, each tracking a listed stock. A basket is a fixed recipe over those tokens: 2–20 constituents and weights in basis points, set once at deployment.
The share token is the whole product. One basket, one Token-2022 mint, 6 decimals. Holding it means holding a pro-rata claim on the basket's vault: at every moment, your share of each constituent equals your share of the total supply, computed on raw on-chain balances. There is no manager with discretion — no rebalancing, no trading, no discretionary anything in V0.
Everything a basket will ever do is decided in the transaction that creates it. Parameters are written to an immutable program-owned account, and no update instruction exists in the program. The rest of this page is what the programs do with that.
> 02 — HOW MINTING WORKS
There are two ways in. The honest one first.
IN-KIND — ONE TRANSACTION
mint_in_kind takes the actual xStocks, in the basket's target proportions, and returns shares in the same transaction. The program prices your deposit from each constituent against the vault and mints the minimum across constituents — an off-weight deposit mints to its least generous reading, and deviating more than 1% from target weights reverts outright (WeightMismatch). Fees are taken in shares, never in tokens. No oracle is consulted: the vault's actual contents are the price.
Pick a basket and amounts
The app previews your net shares after the entry fee before anything is signed.
One transaction
Raw xStocks move from your token accounts into the vault's program-owned accounts via transfer_checked — correct mint and decimals enforced.
Shares mint net of the entry fee
The fee splits 90% creator / 10% treasury between the basket creator and the treasury, and a Minted event lands on-chain — readable by anyone.
ZAP — USDC IN, SEQUENTIAL
Deposit USDC and the app routes through Jupiter: swap legs run first, then the same mint_in_kind call. In V0 these are separate transactions, and that is the honest tradeoff: the swaps are not atomic with the mint. A failed leg leaves you holding intermediate tokens — nothing is lost, but you finish the remaining legs yourself. Typical slippage runs 1–3% and can be worse in fast markets. The atomic on-chain zap is deferred to V1, deliberately.
> 03 — HOW REDEMPTION WORKS
Redemption is the path the whole design bends around. redeem_in_kind burns your shares and pays out the vault pro-rata: for each constituent, amount out = floor(vault balance × shares burned ÷ total supply). Rounding floors to the raw token unit, so the vault can never pay out more than it holds. The only thing that runs before your payout is the management-fee checkpoint, so exit math is never based on a stale accrual.
Three properties, enforced structurally rather than by policy. Oracle-free: the instruction reads no price account of any kind — your pro-rata share of the vault's actual contents is the payout. Permissionless: the only signer is you — no approval, no claim window, no processing delay. Ungateable: the redeem path contains no pause check, because pausing redemption is the one move that would turn self-custody into a promise.
This holds when everything else fails. If the website or the indexer is offline, redemption still works by talking to the basket program directly through any Solana RPC.
> 04 — BASKETS
A basket is defined by three immutable lists written at creation: the constituent mints (every one whitelisted and active at deploy time), their weights in basis points, and the fee schedule. Deployment is atomic — the basket account, the share mint, the vault token accounts, and the creator's seed deposit settle in one transaction. A basket cannot exist empty.
Weights are targets, not managed positions. Prices move and the vault drifts with them; nothing trades to pull it back. The basket page shows actual versus target weight so drift is visible, not discovered. Genesis is deliberately boring: the seed deposit mints exactly 1,000,000 shares — a fixed number chosen so a first depositor cannot engineer a share-price inflation attack.
| Parameter | Constraint | Enforced |
|---|---|---|
| Constituents | 2–20 mints, whitelist active | create_basket |
| Weights | basis points, sum = 10,000 exactly | create_basket |
| Share token | Token-2022 · 6 decimals | fixed |
| Genesis supply | 1,000,000 shares, minted to creator | inflation guard |
| Off-weight mint | reverts above 1% deviation | WeightMismatch |
| Updates | none exist — parameters immutable | program |
> 05 — FEES
Creators choose three fees within hard caps, and the caps are enforced by the factory at deploy — not by policy. Every fee is charged in basket shares, never in the underlying tokens, and splits 90% creator / 10% treasury between the basket's creator and the treasury. Entry is one-time on mint. Exit is one-time on redeem. Management accrues continuously as share dilution through a permissionless crank — (then-current supply × rate × elapsed + stored numerator remainder) ÷ (10,000 × seconds per year) — and is checkpointed inside every mint and redeem so the accrual is never stale. Fee shares join supply, so later intervals compound slightly.
// Caps enforced by FactoryConfig at deploy.
// Imported from app/lib/create-basket.ts — the same
// constants the client validates with.
ENTRY_FEE_CAP_BPS = 300 // 3.00% — one-time, on mint
EXIT_FEE_CAP_BPS = 100 // 1.00% — one-time, on redeem
MANAGEMENT_FEE_CAP_BPS = 300 // 3.00%/yr — share dilution
A basket's fee schedule is immutable once deployed, and it is disclosed on every basket page and in the create wizard before you sign. Read it there — this page shows only the ceiling.
> 06 — RISK
The short version, without the small-print voice: holding a Basalt basket is exposure to tokenized equities and to the programs that wrap them. What can go wrong, plainly:
Market risk
A basket tracks its xStocks; when they fall, the value of your claim falls with them. There is no leverage — and there is no floor.
Issuer and depeg risk
xStocks are structured instruments issued by Backed. Holding one is a claim on the issuer's arrangement, not the underlying share: no shareholder rights, no votes, and the token can trade away from the asset it tracks. Redemption returns xStock tokens, never off-chain shares.
Smart-contract and upgrade risk
The programs hold the vaults, and code can be wrong. The programs are currently upgradable: their upgrade authority can deploy changed logic. A finalized read-only devnet RPC audit on 2026-09-19 confirmed that all three program upgrade authorities and the whitelist configuration authority remain the same single wallet. No multisig or timelock is active. Immutability applies to basket parameters, not program code, and authority reads do not prove deployed bytes match this source tree.
No vetting, no advice
Constituents, weights, and fees are chosen by whoever deploys a basket. Basalt indexes the chain; it does not evaluate anyone's thesis and nothing here is investment advice. Do your own research, and read the full disclosures on Risks & Disclosures.
> 07 — VERIFY IT YOURSELF
Nothing on this page requires trust in this website. Every number here is either a program constant or a fact on the chain, and the chain can be read by anyone.
Open any basket page
The share mint and every constituent mint sit beside the data — each one a copy button. The verify block there is this section, applied.
Paste an address into Solana Explorer
explorer.solana.com, with the cluster matching the app. The Token-2022 mint, its authority, and its extensions are all readable there.
Read the vault
The basket's program-derived authority owns one token account per constituent. Those balances are the actual backing — no off-chain ledger involved.
Read the events
Minted, Redeemed, and FeeAccrued are emitted for every action. The indexer only replays them; it computes nothing you cannot recompute.
PROGRAM IDS
whitelist
FRavMcYQb2FVAHbbG6fGieQHdKk1UrQqgKsAAXTPRQeS
basket_factory
3hzoPep9JKgTmzLT6CNW5x3EN7WNYDevM6KHVM7pLgMF
basket
6Q43vFh4aqGxzvtU2vQwJX9PmX3skfYsGWZdA3fwJB9k
Declared program IDs are not governance proof. Basalt's target is an autonomous hardware-wallet-backed 2-of-3 vault with one 48-hour on-chain timelock, but that migration has not been verified. It remains a mainnet blocker.
If this site disappeared tomorrow, redemption would still work: build a redeem_in_kind transaction against the basket program from any wallet and any RPC. The indexer computes NAV and rankings for convenience; it never signs, and it is never in the path of your exit.