How a market gets bound
Markind 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.
05·1Compose → mint → rotate → redeem
the full flowStage & create
The recipe is staged in an account (solana transactions cap instruction data), then the factory burns $MK 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.
05·2Live feed wall
every wired market05·3The on-chain record
verified against the chain| Account | Address | Explorer |
|---|---|---|
| cluster | Solana Devnet | |
| program | 2tAz…Be9o | open |
| protocol | Cfr5…BQW8 | open |
| usd mint | zpfq…84Rr | open |
| license mint | EniY…6VvV | open |
| splitter ledger | DKtY…XtSw | open |
| lending pool | Co8h…12CV | open |
| faucet | Cmo6…9ZUa | open |
| MAG7 basket | Bkay…vrQs | open |
| TOP6 basket | EfCU…SNbg | open |
| AI6 basket | 9ES8…pYeC | open |
| TBILL basket | 84mk…Uay7 | open |
| SOCIAL basket | C7fx…N7QB | open |
| BIGTECH basket | EX2V…pE24 | open |
solana program id 2tAzcsATTjFpGHnCUkuVvsNmYMkv3GCsJknJke1GBe9o · evm history (robinhood chain testnet) in the repository archives.
05·4Everything else
the deeper questionsWhy 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. Markind is a testnet experiment — not audited, not a security, nothing here is financial advice.