Why 10%? The Math Behind GNDX's Hardcoded Weight Ceiling

Every index has a single number that decides whether it survives a bad week. For GNDX, that number is 10% — the maximum weight any one token can hold in the basket. It looks arbitrary. It isn't. We're going to walk through the math we used to get there, the alternatives we rejected, and why the cap is hardcoded in the smart contract instead of left to a governance vote.

What "weight cap" actually means

If a basket holds ten tokens at 10% each, every token contributes equally to NAV. If the basket holds three tokens at 30/30/40, those three drive almost everything. The weight cap is the per-token ceiling enforced at add and update time inside the IndexVault contract. You can have fewer tokens, you can have lower weights, but no single token can ever exceed the cap. The check is the first line of addToken and updateWeight:

• If newWeightBps > MAX_SINGLE_TOKEN_WEIGHT_BPS, the call reverts.

That constant — MAX_SINGLE_TOKEN_WEIGHT_BPS = 1000 — is the cap. Bps are basis points, so 1000 bps = 10%. The constant has no setter. There is no upgrade path that exposes it. There is no governance proposal that can move it. Even a proposal that passes will revert at execution.

The thought experiment

Imagine a single token in the basket goes to zero overnight. This is not hypothetical — we counted 11 such events across our research universe of 47 GameFi tokens. The question is: how much does the index lose, and how long does it take to recover?

The first part is easy. If the token had weight w, the index loses approximately w of its NAV. The second part is harder, because recovery requires (a) the rebalancer to redistribute the now-zero slot's value across the other tokens, (b) the remaining tokens to perform well enough to fill the hole, and (c) governance to react if the cause is structural rather than idiosyncratic.

The recovery is bounded by the rebalance cadence (quarterly), so the practical question is: after one quarter, can the index plausibly recover?

Walking the cap

We ran the same blow-up against five different cap values, holding the basket composition constant otherwise. Numbers below assume the affected token was at the maximum weight, the rest of the basket performed in line with median historical quarterly returns for the corresponding tier, and a single rebalance distributed the missing value:

• 5% cap: NAV drawdown of ~5%. Recoverable inside one quarter in 94% of historical paths.
• 10% cap: NAV drawdown of ~10%. Recoverable inside one quarter in 71% of paths.
• 15% cap: NAV drawdown of ~15%. Recoverable inside one quarter in 38% of paths.
• 20% cap: NAV drawdown of ~20%. Recoverable inside one quarter in 14% of paths.
• 25% cap: NAV drawdown of ~25%. Recoverable inside one quarter in 4% of paths.

The cliff is between 10% and 15%. At 10%, a blow-up is a bad quarter you can plausibly recover from. At 15%, you're carrying the loss for a year or longer in most paths. At 20% you're carrying it permanently in the median case.

Why not 5% then?

Two reasons.

First, 5% is hard to populate. The Web3 gaming token universe with reliable Chainlink feeds, sustained >$50M market cap, and orderly liquidity is on the order of 25–35 names. A 5% cap forces the basket to hold at least 20 of them just to reach 100% weight, and many of those would have to come from the lower-quality end of the universe, dragging average liquidity down.

Second, 5% pays a real cost in concentration efficiency. The strongest projects in any sector tend to compound at higher rates than the median, and capping them at 5% caps the index's upside exposure to those compounders. There's no free lunch.

10% is the spot where the basket can hold the strongest 8–10 names at full conviction in the Core tier without exposing the index to a single-token catastrophe. The math says so. We'd love a more elegant answer; the data doesn't have one.

Why hardcoded

An interesting fact about most "decentralized" indexes: their per-token caps are governance-adjustable. A large enough holder, or a coordinated coalition, can vote the cap up. This is fine until it isn't. The pattern in TradFi is that boards and IC committees relax risk limits in exactly the moments when those limits matter most — after a strong run, when a single position has produced outsized returns and "feels different." Crypto governance is even worse, because the holders most likely to push for a higher cap are also the ones who'd benefit most personally from concentration.

Hardcoding solves this with a one-way door. To change the cap, you'd have to deploy a new IndexVault contract, migrate the entire vault, and convince every $GNDX holder to redeem and re-mint into the new contract. That's not impossible — protocols do migrations — but it's a public, slow, expensive process that allows the community to organize against it rather than vote it through quietly.

How other indexes compare

The honest answer: most don't have a hard cap at all. Market-cap-weighted index funds inherit whatever concentration the market hands them. Crypto sector indexes that promise diversification often allow single-token weights of 30–50% in practice, which is most of why they end up behaving like concentrated single-token positions in stress.

The handful of protocols that do enforce caps tend to set them in the 15–20% range and make them governance-adjustable. We think the math we ran above explains why those products struggle through drawdowns: the caps are above the recovery cliff, not below it.

Stress testing the actual basket

The launch basket on Arbitrum has nine tokens initially, with weight targets ranging from 5% to 9.5%. None are at the 10% ceiling, but the ceiling is what bounds the worst plausible quarterly outcome. We simulated 10,000 paths combining historical sector returns with the historical mortality rate for each tier:

• Median annual return: roughly in line with the sector benchmark, mid-double-digits.
• Worst quarterly drawdown across paths: bounded by ~14% even in catastrophic scenarios — because no single token can take the index down more than its weight allows.
• Probability of total loss: effectively zero. The basket would have to hold tokens that all went to zero simultaneously, which is structurally implausible across three tiers.

None of this guarantees performance. It does guarantee that the worst-case shape of the loss is bounded by something we chose deliberately, rather than by whatever shape the market hands us.

The takeaway

Risk management in indexes is mostly about deciding what bad outcomes you're willing to accept ahead of time. Setting a 10% cap is a statement that we'd rather give up some upside concentration than take on tail risk we can't recover from. Hardcoding the cap is a statement that we don't trust ourselves — or any future governance — to keep that promise when the temptation to relax it is highest.

You don't have to take our word for any of this. The constant is in IndexVault.sol, the check is on the first line of every weight-mutating function, and the test suite has a fuzz test that runs 1,000 inputs to verify the cap can never be violated by any sequence of legitimate operations. If you want to verify, the code is on GitHub. If you want the underlying data on the 47 tokens, that's in our mortality post.