The Seeding Window: How GNDX Onboards New Tokens

An index fund's job is to track a target basket. The job is straightforward when the basket is stable. It's much less straightforward the moment a new token is approved for inclusion: the protocol has to get capital into the new token, fairly, on its own books, without distorting any other position. Until now we've been hand-waving that step. The seeding window is how we stop hand-waving.

The problem in one paragraph

When governance approves a new token, the smart contract does the obvious thing: it writes a new entry into the basket with a target weight (say, 5%) and a current balance of zero. The protocol now thinks the token is supposed to be 5% of the vault, but it's actually 0%. That's a 500 basis-point underweight on day one. The rebalance alarm — the keeper-paid mechanism that nudges the basket back toward target — fires immediately. Worse, every redeemer who exits during this window receives a proportional share of zero of the new token, which is silently strange. And the only path to actually funding the token is either organic mints (slow at low TVL) or governance manually executing emergency rebalances one pair at a time. None of this is what you want from a production index protocol.

What we built

Every newly-approved token enters a per-token state machine: SEEDING → COOLDOWN → SETTLED. The transitions are bounded by hardcoded ceilings — no governance vote can extend them — and tied to two parallel funding paths that drain capital into the new token in a measured way.

Path A — passive. While at least one token is in SEEDING, every new mint routes 100% of its USDC into seeding tokens, weighted by remaining USD deficit. Existing holders' tokens get nothing from new mints during this window. If two tokens are seeding simultaneously and one has $400K of unfunded target while the other has $100K, the next mint splits 80/20 by deficit — not by target weight. This is by design: the goal is to close the gap, not maintain proportionality.

Path B — active. A permissionless function, OnboardingExecutor.executeOnboardingChunk(token), drains a small slice (capped at 5% of source vault per chunk) of the most-overweight existing token into the seeding token via a two-leg swap through the protocol's ISwapAdapter. Anyone can call it — typically a Gelato keeper. The function is throttled on-chain to one chunk per token every 4 hours and includes oracle-derived slippage clamps on each swap leg. The chunk size is computed against a linear schedule: at elapsed/window through the seeding period, expected funding is elapsed/window of the locked target, and the chunk fires for exactly the gap.

The two paths cooperate. If organic mints are keeping up, Path B's chunks are no-ops that simply bump the throttle. If mints are slow, Path B closes the gap. If both are slow, the token still graduates by hardcoded 14-day timeout regardless. There is no scenario where a seeding token can stall the basket indefinitely.

The funding target is locked at addition

The crucial design choice — and the reason this works the same at $1M and at $1B TVL — is that the funding target is computed once, at the moment of addToken, in 18-decimal USD. After that it never recomputes. If the vault is at $10M and governance approves a 5% target token, the funding target is locked at exactly $500K. Subsequent TVL changes (other tokens accrue, new mints come in, redemptions exit) don't move it. The mechanism behaves identically regardless of how large the index is.

Graduation

The token transitions from SEEDING to COOLDOWN as soon as it reaches 90% of its normalized target weight (the threshold itself is governance-tunable within a hardcoded 75–90% range), or by hardcoded timeout after 14 days. The cooldown is a 48-hour soak period where the token is funded but still not yet a redemption-eligible claim — it gives the basket a chance to settle into its new composition before redemption math starts treating the token as a normal participant. After cooldown, the token transitions to SETTLED and is treated identically to genesis-era tokens: included in redemptions, eligible for the rebalance alarm, fully active.

Redemption during seeding

This is the part that took the longest design conversation. While a token is in seeding or cooldown, redemptions are computed only over fully-settled tokens. A redeemer who exits during this window receives their pro-rata share of every settled token in the vault, and zero of the seeding token. The seeding token's vault balance stays untouched.

The implication is subtle: a redeemer pays a small implicit "tax" — they don't capture the seeding token's proportional value. We considered the alternative (scaling redemption by total vault value to preserve NAV exactly) and rejected it for three reasons. First, the simple version keeps basket redemption oracle-free, which is load-bearing during oracle outages. Second, redemption shrinking settled-side TVL while leaving the seeding token's balance untouched mechanically raises the seeding token's relative share — redemptions actually accelerate graduation. Third, the cost is bounded: at most ~5% of NAV-implied value, capped at 14 days. Aligns incentives without creating a footgun.

What governance can and cannot do

The hardcoded ceilings — 14-day max duration, 5% per-chunk source cap, 90% upper bound on the graduation threshold — cannot be changed by any governance vote. They live in IndexVault's constants and are duplicated in GNDXGovernor's parameter-bounds enforcement so a passed proposal that violates them reverts at execution rather than at vote count. Governance can tune the defaults — duration (3–14 days), chunk interval (1–12 hours), cooldown (24h–7 days), graduation threshold (75–90%) — within the hardcoded ranges.

The emergency rebalance path remains available to governance regardless of onboarding state. If the natural state machine misbehaves, Timelock retains the ability to manually rebalance. We don't expect to use it, but the option is there.

What this enables

Mostly: repeatability. Adding a new token to GNDX is now a deterministic, on-chain process. The day-zero alarm noise is suppressed. Redeemers don't get short-changed by partially-funded positions. Keepers don't get paid rewards for an underweight that's already being remediated. Mint flow is automatically directed to where the protocol needs it. The 14-day timeout means every approved token converges to a stable state in bounded time, regardless of TVL or mint volume. The whole mechanism behaves identically the first time governance uses it and the hundredth time.

That's the goal. A seeding mechanism you don't have to think about — because it's already thinking about itself.