How INDX works
What the protocol does, how to use it, and the mechanisms underneath — written for someone deciding whether to trust it with their money.
What INDX is
INDX builds rules-based index products on Robinhood Chain. An index is a published set of rules deciding which assets qualify, how much of each is held, and when that is reviewed. One index share gives you proportional ownership of everything the index holds, and you can redeem it for those assets at any time.
The unusual part is what happens to the assets while you hold them. A bounded portion of the Reserve is deployed as liquidity into the constituents’ own markets. The fees that activity earns come back to the index. So the index is not only exposure to a market — it is part of that market’s plumbing.
What makes it different
Five things, each of which is a design decision with a cost, not a marketing line.
1. The index earns from the market it tracks
Most index products are pure exposure: they buy the constituents and wait. Small-cap markets are thin, so buying into them means paying the spread and then sitting behind it. INDX places a bounded slice of the Reserve into those markets as liquidity, which means the index collects part of the spread instead of only paying it, and the markets it depends on get deeper.
The cost: capital deployed into a market can come back worth less than it went in. That is ordinary for liquidity provision and it is not hedged away here. The exposure is bounded by two ceilings so a bad outcome is a dent rather than the index.
2. The rules are fixed before the capital arrives
Eligibility, weighting, concentration limits and the review schedule are written into a versioned methodology that exists onchain before anything is bought. Changing it is a governance action behind a timelock, and every screening result is attributed to the version that produced it.
The cost: the index cannot react to a market event faster than its review schedule allows. That is the trade being made deliberately — rules that can be changed quickly are not rules.
3. The Reserve cannot be withdrawn by anyone
There is no administrative withdrawal path out of the Reserve. Not a disabled one, not a timelocked one, not a multisig-gated one: the function does not exist. A test reads the deployed contract’s ABI and fails the build if a function matching one ever appears.
Governance configures parameters inside fixed caps. It cannot move Reserve assets, and it cannot mint shares against nothing.
4. One asset in, the whole basket out
Buying a ten-asset index normally means ten trades, ten spreads and ten chances to get the proportions wrong. Supplying a single asset does it in one transaction, and buys in the proportions the Reserve already holds so that minting cannot be used to skew the index.
The cost: you pay spread on every leg. Minting in kind is still cheaper if you already hold the constituents, and it stays the primary route rather than being deprecated in favour of the convenient one.
5. The app never shows a number nobody measured
Every figure in the app is read from the chain or from an indexer built out of chain events. Where a value has not been read, the app shows an em dash and says why — it does not show a zero. Those are different claims and the interface keeps them apart everywhere.
| What you see | What it means |
|---|---|
| — | Not read. Nothing is being claimed about this value. |
| 0 | Measured, and the measurement is zero. |
| No indexer connected | History cannot be read. Not a statement that nothing has happened. |
| Not live | The contract for this figure is not deployed yet. |
Getting started
You need a wallet that supports Robinhood Chain and some of the network’s native token for gas. Nothing else — there is no account to create, no allowlist and no sign-up.
- Open the appUse the Launch app button, or go straight to
/app/. Everything is readable before you connect anything. - Connect a walletConnect wallet in the sidebar. The app requests your address and the current chain, nothing else. It never asks for a seed phrase or a private key, and no part of it will ever have a field for one.
- Check the networkIf your wallet is on the wrong chain the app says so and offers to switch. It will not silently read the wrong chain and show you figures from it.
- Read before you actEvery page works read-only. The Reserve, the constituents, the Bands and the methodology parameters are all visible without a transaction.
How to mint index shares
Minting supplies assets to the Reserve and issues you shares against them. Because the Reserve backs the share, what you supply is what the index holds.
- Go to Mint / RedeemThe button sits at the bottom of the app sidebar.
- Choose in-kindSupply the constituents in the proportions the index currently holds. The app shows you the exact list and amounts required for the number of shares you want.
- Approve each assetAn ERC-20 approval per constituent, once. Your wallet shows each one. Approving is not the mint — it authorises the Router to move that asset when the mint runs.
- Set your minimumThe minimum shares out field is your protection. If the transaction would issue fewer shares than that, it reverts rather than filling. Leaving it at zero means accepting any outcome.
- SubmitOne transaction mints. The app shows the resulting share balance read back from the chain, not the number it predicted.
Why in-kind
Supplying the constituents directly means nothing is bought on your behalf, so none of your capital is spent on slippage getting into the index. Where a single-asset convenience route is offered, it converts for you and prices that conversion with an explicit bound you set — the app shows the bound before you sign and the transaction fails rather than filling outside it.
How to mint from a single asset
Minting in kind means holding every constituent before you start. The single-asset route does that part for you: you supply one asset, the protocol buys the basket on your behalf in the proportions the Reserve already holds, and mints against what it acquired.
- Pick the asset and amountThe app shows how the amount will be split across the constituents before you sign. That split is the Reserve’s current composition, priced — it is not a prediction of what the swaps will fill at.
- Set your minimum sharesThis is the bound that matters. If any leg fills badly the basket is worth less, fewer shares mint, and the whole transaction reverts with your funds untouched.
- SubmitOne transaction: split, swap each leg, mint, and return anything that could not be spent.
Why it buys proportionally
The mint itself does not require proportions — the Router values whatever arrives and issues shares against that value, so a lopsided basket would still be fair to you. It would not be fair to everyone else: minting would become a way to push the index’s composition toward whatever you happened to buy, without paying the rebalancing cost. Buying in proportion to what the Reserve already holds means a single-asset mint leaves composition exactly where it found it.
What it is not
- Not a second way into the Reserve. It holds no privileged role and touches no Vault function. It buys the basket and then queues up behind the same in-kind mint everyone else uses. There is one door.
- Not free. You are paying spread on every leg. Minting in kind costs nothing in slippage, and remains the cheaper route if you already hold the constituents.
- Not available for the first mint. With no shares outstanding there is no composition to buy in proportion to, so the opening mint is in kind by design rather than by accident.
How to redeem
Redemption burns shares and returns a proportional slice of everything the Reserve holds. It is the mechanism that makes the share worth what it is backed by, and it is available at all times.
- Enter the shares to burnThe app previews the exact assets and amounts you will receive, read from the current Reserve.
- Check the previewYou receive a slice of every constituent, in kind and pro rata. If Depth has to be unwound to cover your redemption, that happens inside the same transaction.
- Set your minimumAs with minting, the bound is yours to set and the transaction reverts rather than filling outside it.
- SubmitShares burn, assets arrive.
How to claim earnings
Fees the Sleeve earns are split between two routes: one share compounds into the Reserve and lifts the share price for everyone, the other is distributed as claimable tokens. The split is a published parameter.
- Open EarningsThe countdown at the top is the live settlement period. It is real without any contract deployed, because the boundaries are fixed UTC times.
- Watch it accrueYour accrual grows continuously with the time you hold. There is nothing to stake, lock or opt into — holding the share is the whole action.
- Wait for the period to closeAt 00:00, 08:00 or 16:00 UTC the window shuts and its total is fixed permanently.
- ClaimOne transaction. The app seals any closed-but-unsettled period first, then claims — claiming without sealing would walk straight past fees you had already earned.
You are paid in the tokens the fees were earned in. Nothing is sold or swapped on your behalf, so none of it is lost to slippage on the way to you. Settled amounts wait indefinitely: no queue, no deadline, nothing expires.
Reading the app
A short guide to the things most likely to be misread.
- Target weight vs actual weight
- Target is what the methodology says the index should hold. Actual is what it holds right now, which drifts as prices move. Both are shown, and neither is ever presented as the other.
- The Band
- The permitted range around a target weight. Inside it the Engine leaves inventory alone. A marker for actual inventory is drawn only when a real figure was read — a marker resting somewhere plausible is indistinguishable from a measurement, so it is left out rather than guessed.
- NAV per share
- The Reserve’s value divided by shares outstanding, read from the chain. Not estimated in your browser.
- Four Reserve buckets
- Core, Idle Depth, Deployed and Fees are reported separately rather than summed. A single total is the figure that hides problems.
- Activity and Flow
- Built from chain events by an indexer, never inferred from prices. If no indexer is connected the app says so rather than showing an empty list, because an empty list reads as "nothing happened".
The index and its methodology
Every INDX index begins with a methodology published before any capital enters. It is versioned onchain; changing it is a governance action behind a timelock, and the version number increments so that every screening result and weight computation is attributable to the exact rules that produced it.
What the methodology fixes
- Eligibility
- The market category, a market-capitalisation ceiling, minimum liquidity, minimum traded volume over 24h, and a minimum age. An asset failing any of these is not ranked lower — it is excluded.
- Weighting
- Market capitalisation, its square root, equal weight, or liquidity-adjusted. Named in the methodology, not chosen per review.
- Concentration limit
- A ceiling on any one constituent’s weight, so a single asset cannot come to dominate between reviews.
- Review schedule
- How often the rules are re-run. Between reviews target weights do not move, whatever prices do.
- Staleness bound
- The maximum age of the metrics a review may use. Data older than this is refused rather than used, because a screening run on stale inputs produces a confident wrong answer.
How a change lands
- ProposeParameters are validated on submission, not on commit. An impossible methodology cannot be queued, let alone enacted.
- WaitThe timelock runs in full. There is no expedited path, because the delay is the entire protection.
- CommitPermissionless once the delay has elapsed — after the wait there is nothing left to deliberate, so the governor is not a bottleneck.
- VersionThe version increments and is emitted. Every later result points back at it.
The Reserve
The Reserve is the pool of assets backing every share. It is onchain and readable by anyone. Each unit is in exactly one of four accounting states at any moment — the states are exclusive, and the contract asserts that they sum correctly after every single mutation.
| Bucket | Meaning | Immediately available? |
|---|---|---|
| Core | Constituent assets held idle | Yes |
| Idle Depth | Set aside for market-making, not yet placed | Yes |
| Deployed | Currently placed in a constituent market | After unwinding |
| Fees | Earned and banked, not yet distributed or compounded | Yes |
Solvency
After every operation that moves value, the Vault re-checks that the sum of the four buckets matches what it actually holds. An operation that would break that equality reverts. This is why the buckets are reported separately in the app: the split is the thing that makes the total checkable.
What cannot happen
- No administrative withdrawal. The function does not exist and a test fails the build if one is added.
- No minting against nothing. Only the Router may mint, and only after backing has actually arrived — the contract credits what arrived, not what was requested.
- No growing the Depth Sleeve without a valuation. If the price source cannot answer, allocation refuses rather than proceeding blind. Shrinking it never requires one, so a broken feed cannot trap capital.
Depth: the Sleeve
Depth is the bounded portion of the Reserve allocated to providing liquidity in the constituents’ own markets.
Two ceilings and a floor
| Limit | Set at | Can governance change it? |
|---|---|---|
| Hard cap | Deployment, immutable | No. Never, by anyone. |
| Configured cap | Inside the hard cap | It may lower it, and raise it only up to the hard cap. |
| Core floor | A minimum share held idle | Configurable, and cannot overlap the cap. |
The configured cap and the Core floor are checked against each other: a configuration where the Sleeve ceiling and the Core floor would overlap cannot be set at all, rather than being set and then silently misbehaving.
Per-market limits
Beyond the global bounds, each venue has a maximum share of any one asset’s Sleeve. Concentrating the whole allocation of a constituent in a single market would make the index’s exposure to that venue’s failure total rather than partial.
When it loses
Capital placed in a market can come back worth less than it went in. When that happens the shortfall is realised and recorded against that position as a loss, visibly, rather than being absorbed into the Reserve total where nobody would see it. The app shows realised losses per position.
The Engine
The Engine is the onchain logic managing Depth once it is placed. It does not decide what the index holds — that is the methodology’s job — and it cannot move capital outside its bounds.
- Bands
- A permitted range around a target weight. Inside it, inventory is left alone. Approaching an edge, the Engine adjusts fees so that the trade pushing it further out is more expensive and the trade bringing it back is cheaper. It steers with price rather than by trading against the market.
- Dynamic fees
- The fee on each side of a market, moved within a published minimum and maximum, and with a cap on how far it may move in one step. Every change is emitted onchain and appears in the activity feed.
- Inventory state
- Whether a market is inside its Band, approaching an edge, or outside it. Derived from measurements, and shown as unknown when the measurement is unavailable.
- Flow
- Trades against a constituent market. Historical Flow is reconstructed from chain events only.
Programmable by design: the v4 hook
The Engine is not a contract sitting beside a market watching it. It is a Uniswap v4 hook — code the pool itself calls on every swap. v4 lets a pool delegate parts of its behaviour to a hook contract, and the Engine takes two of those: it is invoked before a swap and after it.
| Moment | What the Engine does |
|---|---|
| Before the swap | Computes the fee this particular trade should pay, from where the constituent’s inventory sits inside its Band, and returns it as a per-swap override of the pool’s fee. |
| After the swap | Observes the result. It takes no value and returns no balance delta — the permissions it asks the pool for do not include that. |
This is what makes the fee genuinely dynamic rather than a setting somebody changes occasionally. A trade pushing a constituent toward the edge of its Band is quoted a worse price than the trade bringing it back, and that happens inside the swap, per swap, without anybody submitting a transaction to adjust anything.
It is also why the Engine can be strict. A hook address in v4 encodes its own permissions in the low bits of the address, so the pool can see what a hook is allowed to do before it calls it. The Engine’s address grants it exactly two: before-swap and after-swap. It cannot take a share of the trade, cannot return a balance delta, and cannot touch liquidity — those permissions are not in its address, so the pool would not honour them if the code tried.
Fee bounds are enforced twice
The Engine clamps a fee to its configured range, and the market adapter clamps again to an immutable range fixed at deployment. If the Engine’s range were wider than the adapter’s, every update outside the adapter’s bounds would revert and the market would look configured while silently ignoring its Band. Deployment preflight checks for exactly this and refuses to pass.
Settlement mechanics
Distribution runs in fixed eight-hour periods closing at 00:00, 08:00 and 16:00 UTC. The boundaries are aligned to the Unix epoch rather than to the contract’s deployment, which is why they land on round UTC times and why the app can show a truthful countdown with nothing deployed.
Weighted by time held, not by balance at the bell
A period’s fees are divided by share-seconds: each holder’s balance multiplied by the time they held it.
your share = period fees × (your share-seconds ÷ total share-seconds)
A worked example
Arithmetic, not data. Round numbers chosen so they cannot be mistaken for a reading.
| Holder | Shares | Held for | Share-seconds | Gets |
|---|---|---|---|---|
| Ama | 100 | the full 8h period | 100 × 28,800 = 2,880,000 | 2/3 |
| Ben | 100 | the final 4h only | 100 × 14,400 = 1,440,000 | 1/3 |
| 4,320,000 total |
Ben held the same balance as Ama at the closing instant and receives half what she does, because he held it for half as long. Under a closing-balance scheme they would have received the same amount.
Claiming
Accrual is tracked with cumulative per-period rate sums, so settling a holder who has been idle for hundreds of periods is a constant-time operation rather than a loop over each one. Sealing periods is bounded per call, so a long-dormant contract can always be brought up to date incrementally instead of becoming permanently unsettleable.
Rebalancing
When a review changes target weights, the index moves toward them gradually rather than in one transaction.
- ProposeThe new targets are queued with a window in which they must be executed.
- RampWeights move toward their new targets over the window rather than stepping. A single large step is a trade anybody can see coming and price against.
- Complete or cancelA proposal completes, expires, or is cancelled mid-ramp by the guardian if conditions warrant.
Constituent entries and exits are the same mechanism: an entering asset ramps up from zero, an exiting one ramps down to it.
Governance and its limits
Two roles, deliberately unequal in kind rather than in degree.
| Governor | Guardian | |
|---|---|---|
| Purpose | Configures | Stops things |
| Timelocked? | Yes, on everything that matters | No — an incident needs a response in seconds |
| Can pause | Yes | Yes |
| Can unpause | Yes | No |
| Can change a value | Inside fixed caps | No |
| Can move capital | No | No |
Unpausing is governor-only by design. A guardian who could unpause would simply be a governor with extra steps, and the whole point of the split is that the fast role can only ever reduce what the system is doing.
Two-step handover
Transferring the governor role nominates an address; nothing changes until that address accepts. A mistyped address cannot orphan the protocol, and the app reports a pending nomination as pending rather than as a completed handover.
Security model
What the architecture assumes, and what it does not.
- Contracts hold the rules
- Caps, floors, fee bounds and timelocks are enforced onchain. The interface cannot relax them and neither can an operator.
- The interface is not trusted
- Every figure the app shows is read from the chain or from events. If the app were replaced wholesale, the protocol would behave identically.
- The indexer is not trusted either
- It reconstructs history from events. It cannot mint, move or authorise anything, and if it is wrong the chain is still the record.
- Price feeds are a dependency
- Valuation needs them. Growing Depth refuses without a valuation; shrinking it never requires one, so a failed feed cannot trap capital inside a market.
- Deployment is checked, not assumed
- A preflight reads a deployed system back and reports every misconfiguration it can find — unset roles, mismatched addresses, overlapping bounds, an asset nobody priced, fee ranges wider than their adapter allows. A protocol is not made correct by deploying correct bytecode; it is made correct by the wiring, which nothing onchain can check on its own.
Risks
Plainly, and not as a formality.
- You can lose money. Index shares track a basket of small-cap assets. If those assets fall, the index falls with them. Nothing here prevents that.
- Market-making can lose money. Capital placed as Depth can return worth less than it went in. The Sleeve is bounded so this cannot take the whole index, but a bound limits damage — it does not prevent it.
- Smart contracts can have bugs. This protocol is new. Code that is tested is not code that is proven, and an audit reduces risk without removing it.
- Thin markets behave badly. Small-cap constituents can gap, halt or become illiquid. A redemption during such a period may unwind positions on poor terms.
- Price feeds can be wrong or stale. A wrong price is worse than a missing one: the system refuses to act without a valuation, but it cannot know that a valuation it received is incorrect.
- Governance is a trust assumption. Parameters are capped and timelocked and Reserve assets cannot be withdrawn administratively — but whoever holds the governor role can still change what is changeable.
- New chains carry their own risk. Robinhood Chain, its bridges and its infrastructure are dependencies of everything above.
Common questions
Do I have to stake or lock anything to earn?
What happens if I hold for only part of a settlement period?
Can I always redeem?
Where do the fees actually come from?
Why does the app show a dash instead of a number?
Who can change the rules?
Is this an investment product I can buy through a broker?
Glossary
- Index
- Rules-based exposure to a whole market category through one onchain position.
- Reserve
- The assets economically backing every index share.
- Core
- The portion of the Reserve held idle and immediately available.
- Depth
- The bounded portion of the Reserve deployed across constituent markets as liquidity.
- Sleeve
- The same thing, named where the emphasis is on its limits.
- Engine
- The onchain logic coordinating Depth, dynamic fees and inventory inside methodology limits.
- Bands
- The permitted range around a target weight inside which inventory is left alone.
- Flow
- Trading activity against a constituent market, reconstructed from chain events.
- Constituents
- The assets an index holds, selected by the methodology.
- Methodology
- The published, versioned rules defining eligibility, weighting, limits and review schedule.
- Target weight
- What the methodology says should be held.
- Actual weight
- What is held right now.
- NAV per share
- The Reserve’s value divided by shares outstanding.
- Share-seconds
- Balance multiplied by time held — the denominator a settlement period’s fees are divided by.
- Settlement period
- A fixed eight-hour window closing at 00:00, 08:00 or 16:00 UTC, whose total is final once closed.
- Sealing
- Fixing a closed period’s total so it can be claimed against.
- Zap
- The single-asset mint route: supplies one asset, buys the basket in the Reserve’s current proportions, and mints against it.
- Venue
- An approved contract the zap may swap through. Allowlisted per pair by governance.
- Hook
- A contract a Uniswap v4 pool calls at defined moments in a swap. The Engine is one. Publicly the component is called the Engine; "hook" is the v4 mechanism it uses.
- PoolManager
- The single Uniswap v4 contract that holds every pool and calls hooks. Not yet tested against.
- Guardian
- The role that can stop things immediately and start nothing.
- Governor
- The role that configures, behind timelocks, inside fixed caps.