How a market gets bound
Orbind is an on-chain index rotation protocol on Solana. One program holds the whole market model: baskets, the factory and license burn, the fee splitter, the credit desk and the faucet — all state lives in program accounts, all rules enforced on-chain.
Compose → mint → rotate → redeem
Stage & create
The recipe is staged in an account (solana transactions cap instruction data), then the factory burns $ORB and creates the basket plus its SPL mint in the next transaction.
Mint
Deposit the exact component amounts — rounding up — plus a 0.5% USD fee split 60/40. The basket mints you index shares from its own PDA.
Rotate (managed)
The curator proposes a new recipe and executes after cooldown. Settling happens at oracle prices with a hard 0.5% NAV bound; exited assets leave the basket.
Redeem
Burn shares, receive components — rounding down. No oracle read, no permission, no pause. Vault balances always cover the recipe.
Live feed wall
The on-chain record
| account | address | |
|---|---|---|
| cluster | Solana Devnet | |
| program | 2tAz…Be9o | explorer |
| protocol | Cfr5…BQW8 | explorer |
| usd mint | zpfq…84Rr | explorer |
| license mint | EniY…6VvV | explorer |
| splitter ledger | DKtY…XtSw | explorer |
| lending pool | Co8h…12CV | explorer |
| faucet | Cmo6…9ZUa | explorer |
| MAG7 basket | Bkay…vrQs | explorer |
| TOP6 basket | EfCU…SNbg | explorer |
| AI6 basket | 9ES8…pYeC | explorer |
| TBILL basket | 84mk…Uay7 | explorer |
| SOCIAL basket | C7fx…N7QB | explorer |
| BIGTECH basket | EX2V…pE24 | explorer |
solana program id 2tAzcsATTjFpGHnCUkuVvsNmYMkv3GCsJknJke1GBe9o · evm history (robinhood chain testnet) in the repository archives.
Everything else
Why one Solana program instead of separate contracts?+/-
On Solana the contract is code and the state is accounts — one program can hold every entity (baskets, splitter, pool, faucet) with cheaper deployments and atomic cross-entity instructions like the fee routing inside mint.
Why is there a staging account for basket creation?+/-
Solana caps a transaction at 1232 bytes. A seven-component recipe plus creation accounts busts that in one instruction, so the recipe is staged into a PDA and consumed by the next transaction.
Why does the basket keep a price cache?+/-
The same size bound: minting with seven components plus live feeds does not fit. A permissionless refresh_price instruction re-quotes the basket from its feeds; mints enforce the cache is fresh before trading.
Are the holder counts exact?+/-
Approximate: SPL transfers between wallets bypass the program, so holder_count tracks mint/redeem-derived changes only — enough to gate the staged deposit caps on a testnet.
What happens if the oracle goes stale?+/-
Every price read enforces max_price_age. On devnet the mock feeds are static so baskets tolerate a year; production wiring would use real feeds with market-hours staleness.
Is this audited?+/-
No. Orbind is a testnet experiment — not audited, not a security, nothing here is financial advice.