Skip to main content

Rebalancing

GNDX uses four rebalancing mechanisms to keep the basket aligned with its target weights. Two are continuous and automatic; one is quarterly and governance-driven; one is an emergency governance tool for active selling during crises.

1. Passive Rebalancing on Mint​

Every time a user deposits USDC, the MintEngine runs mint routing: among routable basket tokens (not inactive, not excluded via IndexVault mint-routing flags), it either splits USDC by target weights when the basket is near neutral, or directs the full mint step to the most underweight routable token.

How it works: Drift is evaluated on-chain (IndexVault.getWeightDriftBps). Excluded tokens get zero new USDC in that step until governance clears exclusion—while still counting toward NAV and redemptions.

This passive mechanism corrects drift continuously — every single mint is a rebalancing action — without requiring the protocol to sell existing positions or incur exit fees.

2. Overweight Arbitrage Incentive​

When any token drifts more than 5% above its target weight, the protocol activates a bonus redemption path.

Overweight Bonus

Redeeming the specific overweight token applies a 0.22% bonus to the effective NAV used to calculate the redemption amount. The standard exit fee (0.20%) still applies separately, so the net benefit versus a standard basket redemption is approximately +0.02%. This creates a direct economic incentive for external arbitrageurs to correct the imbalance.

Example: If Token A has a target weight of 10% and its current weight is 15.1% (5.1% drift), any user can redeem $GNDX and choose Token A as their redemption asset. The effective NAV is calculated as navPerToken × 10022 / 10000, giving the redeemer slightly more of the overweight token.

Bots monitoring IndexVault.getWeightDriftBps(token) can identify and act on these opportunities. The result: overweight positions are corrected without governance action and without the protocol paying for active management.

Weight drift is defined on-chain as a value-share drift:

drift = currentUSDShareBps - targetShareBps

IndexVault.getWeightDriftBps(token) is the canonical source of truth. Positive = overweight. Threshold for incentive activation: 500 bps (5%).

3. Emergency Rebalance (Governance-Triggered)​

When a basket token is in severe distress (confirmed exploit, team collapse, exchange delisting), governance can actively sell the overweight position rather than waiting for passive rebalancing:

  1. Step 1: Governance calls updateWeight(token, 0) — sets the crashing token's target to 0%, making it maximally overweight.
  2. Step 2: Governance calls RebalanceController.executeEmergencyRebalance(overweightToken, underweightToken, sellAmount):
    • Pulls the overweight token from the vault
    • Swaps it to USDC (via the DEX adapter) as a routing intermediary
    • Swaps USDC to the most underweight remaining token
    • Deposits the underweight token back into the vault
  3. Step 3: Repeat until the overweight token balance is near zero, then removeToken().

Safety constraints:

  • GOVERNANCE_ROLE only (requires governance vote + 48-hour timelock)
  • Sell amount capped at 25% of vault balance per transaction (prevents single-tx drain)
  • 3% slippage tolerance using NAVOracle TWAP pricing
  • Drift direction validated on-chain: overweight token must have positive drift, underweight must have negative drift
When does the protocol NOT sell?

If the entire market drops equally (all tokens -30%), every token's weight drift stays near zero. There is nothing to rebalance. The protocol correctly does nothing — selling Token A to buy Token B when both are -30% just incurs swap fees for zero portfolio improvement. This matches how traditional index funds (SPY, VOO) handle market-wide drawdowns.

4. Quarterly Governance Rebalancing​

Every quarter, $GAME governance conducts a full rebalancing review. This is the only mechanism that can:

  • Add new tokens to the basket
  • Remove existing tokens
  • Change target weights
  • Re-tier tokens between Core / Ascent / Frontier

Process​

  1. Gaming Council publishes a rebalancing recommendation report (published on governance forum)
  2. Temperature Check on Snapshot — 5-day community discussion
  3. Governance Proposal on Snapshot — 7-day vote, 66% supermajority required
  4. Timelock — 48-hour delay after vote passes
  5. Execution — RebalanceController executes weight changes

Weight Change Constraints​

Any weight change proposed via governance is subject to:

  • Hard cap: no token can be set above 10% (1000 bps — enforced in smart contract; proposal reverts if exceeded regardless of vote outcome)
  • Tier allocation bands: tier weights are enforced within hard on-chain floors and ceilings (Core 55–65%, Ascent 20–30%, Frontier 10–15%) and must be updated atomically
  • Three tiers must always sum to 10,000 bps (100%)

Token Addition​

Adding a new token requires:

  • Full inclusion criteria met
  • Chainlink price feed registered in NAVOracle before the proposal executes
  • 66% supermajority vote
  • 48-hour timelock

Seeding Window — what happens after a successful vote​

Once governance executes the addition, the new token enters a seeding window rather than appearing in the basket fully-allocated overnight. This avoids the "alarm noise" that would otherwise trigger every keeper sweep until the token is funded, and it keeps redemption fair while the basket transitions.

Funding paths during the window:

  • Path A (passive): every new mint automatically routes 100% of its USDC into the seeding token(s), weighted by remaining USD deficit. Existing basket tokens get nothing from new mints during this window.
  • Path B (active): anyone (typically a Gelato keeper) can call OnboardingExecutor.executeOnboardingChunk(token) to drain a small slice (≤ 5% of vault balance) of the most-overweight existing token into the seeding token via a two-leg swap. Throttled to one chunk per token every 4 hours by default.

Graduation: the token transitions to a 48-hour cooldown phase as soon as it reaches 90% of its normalized target weight, OR after a hardcoded 14-day timeout if funding lags. After cooldown, the token is fully active in the basket.

Redeem and alarm exclusions during seeding: redemptions are computed only over fully-settled basket tokens — a redeemer who exits during seeding does not receive any of the seeding token, and the token's vault balance stays untouched. The same exclusion applies to the rebalance alarm so keepers are not paid rewards for an underweight that's already being remediated by Path A and Path B.

Token Removal​

Removing a token requires:

  • Token balance in IndexVault must be exactly zero before governance can remove it
  • The rebalancing proposal must include a plan to distribute or sell the existing balance
  • 66% supermajority vote
Emergency Removal

For confirmed exploits, the Gaming Council can submit an emergency governance proposal. The standard 7-day voting period applies; the community should prioritise participation. A future contract upgrade will introduce a compressed emergency voting period.

See also: Inclusion Criteria · Protocol Architecture

On this page