Skip to main content

Inclusion Criteria

Every token in the GNDX basket must meet all of the following criteria to be eligible for inclusion in any tier. These are evaluated by the Gaming Council and confirmed by $GAME governance vote.

Universal Requirements (All Tiers)​

CriterionMinimum Requirement
30-day average daily on-chain volume>$75K
Smart contract auditRequired — at least one reputable firm
Exchange listingMust trade on at least 2 DEXes
Active developmentGitHub commits within the last 90 days
Chain compatibilityNatively on Arbitrum, or bridgeable via the official Arbitrum bridge
Age>6 months of on-chain trading history (platform floor)
No Exceptions

The audit requirement is a governance policy enforced through the proposal process and community review; it is not currently proven as an on-chain invariant.

Tier-Specific Requirements​

Tier classification is rank-based rather than tied to absolute market-cap thresholds: tokens are ordered by 90-day average market cap and assigned to a tier based on where they fall in the eligible universe. This avoids forced re-tiering as the gaming sector's overall valuation shifts.

Core​

  • Sector rank: top-tier of the eligible universe by 90-day average market cap
  • 30-day average daily on-chain volume: >$1M
  • Trading history: minimum 12 months

Ascent​

  • Sector rank: mid-tier of the eligible universe by 90-day average market cap
  • 30-day average daily on-chain volume: >$300K

Frontier​

  • Sector rank: early-tier of the eligible universe (newer or recovering projects)
  • 30-day average daily on-chain volume: >$75K (universal floor)
  • Audited smart contracts and active development required

Weight Constraints​

  • Maximum weight per token: 10% (1,000 bps) — hardcoded in IndexVault.MAX_SINGLE_TOKEN_WEIGHT_BPS, cannot be changed
  • Minimum weight per token: 0.5% (50 bps) — governance policy, not on-chain invariant. Positions below this are too small to be meaningful and incur disproportionate rebalancing costs; the methodology committee enforces this in proposals rather than reverting it on-chain.

Exclusion Criteria​

A token will not be eligible for inclusion if it:

  • Has been involved in a confirmed rug pull or exploit in the last 24 months
  • Has a single entity controlling >50% of token supply (concentration risk)
  • Has no publicly verifiable team or development activity
  • Is primarily a speculative memecoin with no underlying game product
  • Is bridged via a third-party bridge (only official Arbitrum bridge is acceptable)

Removal Triggers​

A token already in the basket may be proposed for removal if:

  • Sector rank falls outside the eligible universe for 90 consecutive days
  • Daily volume falls below the tier minimum for 60 consecutive days
  • Smart contract exploit occurs (emergency fast-track removal — 3-day process)
  • Active development ceases (no GitHub commits for 90 days)
  • Bridge risk materially increases

What Happens After Approval​

A successful inclusion vote does not result in the token appearing in the basket fully-allocated overnight. Instead, the new token enters a seeding window so the protocol can fund it in a measured way:

  1. Day 0 — addToken: The new token is registered in IndexVault with state SEEDING. A USD funding target is locked at this moment based on the vault's current TVL × the token's target weight share. This target does not float as TVL changes.
  2. Days 0–14 — funding: Two parallel mechanisms drain capital into the seeding token:
    • Every new mint routes 100% of its USDC into the seeding token (weighted by remaining deficit if multiple tokens are seeding simultaneously).
    • Permissionless keepers can call OnboardingExecutor.executeOnboardingChunk(token) to drain a small slice (≤ 5% per chunk, 4-hour throttle) of the most-overweight existing token into the seeding token via DEX swap.
  3. Graduation: As soon as the seeding token reaches 90% of its normalized target weight, it transitions to a 48-hour cooldown. If funding lags, the token graduates by timeout after 14 days regardless. The cooldown gives the basket a stable 48-hour read on the new composition before redemptions begin treating the token as a normal claim.
  4. Settled: After cooldown, the token participates fully in the basket — included in redemptions, eligible for the rebalance alarm, treated identically to genesis-era tokens.

During seeding and cooldown, redemptions are computed only over fully-settled tokens — a redeemer who exits during this window does not receive any of the seeding token. This naturally accelerates graduation by shrinking settled-side TVL.

The 14-day hard timeout is a protocol-level guarantee: no governance action can extend it. Even a token that fails to reach 90% of target by day 14 still graduates at that point, ensuring the basket converges to a stable state in bounded time.

The Gaming Council's Role​

The Gaming Council — seven elected members — handles the research burden of evaluating inclusion candidates. They publish formal reports on proposed additions/removals, including:

  • Market cap and volume data (30-day averages)
  • Audit status and smart contract risk assessment
  • On-chain player activity metrics
  • Bridge risk analysis

These reports are published on the governance forum before any vote. Community members who disagree with a recommendation can vote against the Council's proposal — all final decisions are made by the $GAME community, not the Council.

See also: Three-Tier Structure · Gaming Council

On this page