Mint, Burn, NAV: How GNDX Pricing Actually Works

Here's the question we get most often, in some form: how does the price of $GNDX get set? The honest answer is that it doesn't, in the usual sense. There's no order book where buyers and sellers haggle. There's no team announcing prices. The price of $GNDX is the value of the basket it represents, divided by the number of tokens that exist, every block. That's it. This guide explains exactly what that means and why it works.

The two-token recap

Before we get into pricing, the model: GNDX has two tokens because they do two different things. $GNDX is the index — its supply expands and contracts as people deposit and withdraw, and its price tracks the basket. $GAME is the governance token — fixed supply, used for voting and locked for fee revenue. We've written separately about veGAME if you want to dig into that side. This post is entirely about the $GNDX side.

What NAV actually means

NAV stands for net asset value. It's a borrowed term from traditional indexing. The idea is simple: if a fund holds a basket of stocks, the per-share NAV is the total value of the basket divided by the number of shares outstanding. For GNDX, swap "stocks" for gaming tokens and "shares" for $GNDX:

• Total vault value = sum of (token balance × token price) for every token in the basket, valued in USDC.
• NAV per token = total vault value ÷ $GNDX total supply.

Token prices come from oracles — Chainlink USD feeds where they exist, Uniswap V3 TWAPs with a 20-minute window where they don't. The protocol doesn't trust spot prices for NAV; it uses time-weighted averages so a single bad block can't move the calculation.

One important corner case: when total supply is exactly zero (genesis), NAV is defined as exactly $1.00. This anchors the very first mint to a clean reference price. After that, the formula above takes over.

How minting works

You send USDC. You get $GNDX. The interesting question is how much.

The protocol does it in three steps:

• Step 1. Read the current vault value before your deposit.
• Step 2. Use your USDC to acquire the basket's tokens at their current weights, deposited into the vault. (For small mints this happens instantly; for larger mints it's spread across a TWAP — the routing rules are in our Phase 5 post.)
• Step 3. Read the new vault value. The difference is what your deposit added. Mint you $GNDX equal to (added value) ÷ (NAV per token), where NAV per token is computed from the post-deposit vault value and the pre-deposit supply.

This shape — minting based on value added, not USDC deposited — is what we mean by "value-based minting." It matters because acquiring the basket has friction: DEX fees, slippage, swap impact. If we minted you $GNDX based on the raw USDC you deposited, that friction would show up as dilution to existing holders. Instead, the friction comes out of your $GNDX count, and the per-token NAV stays stable. Existing holders' positions are unchanged in value. You get slightly less $GNDX than the raw-USDC math would give, but each token is worth the same NAV.

How redemption works

You burn $GNDX. You get assets out. You have three modes to choose from:

• Redeem for basket. The simplest mode. You burn N tokens, you receive (N ÷ total supply) of every token in the vault. No swaps, no oracle dependence, no NAV calculation needed for the math itself. This mode works even when oracles are degraded — there's nothing to price.
• Redeem for USDC. The protocol burns your $GNDX, swaps your proportional basket share to USDC inside one transaction, and sends you the USDC. You pay for the swap friction; in exchange you don't have to manage 9–30 token positions in your wallet.
• Redeem overweight. If a specific token has drifted above its target weight by more than 5%, you can redeem your $GNDX specifically for that token at a small bonus. This is a self-service rebalance — the protocol pays you a few basis points to take an overweight token off its hands.

The math for "redeem for basket" is the part worth internalizing because it's where the no-arbitrage property lives. The amount of each token you get is computed against the supply before your burn, not after. We wrote this rule down in big letters in the contract because doing it the other way creates a subtle accounting error that a careful attacker could exploit.

Why the price can't drift

This is the part that surprises people. With most tokens, the market price can detach from any "fundamental" value, sometimes by a lot, for a long time. With $GNDX, that doesn't happen — and not because we're enforcing it, but because arbitrageurs do.

Consider the two cases:

• If $GNDX trades above NAV on a DEX: someone can deposit USDC into the protocol, mint $GNDX at NAV, sell it on the DEX above NAV, and pocket the difference. They'll keep doing this until the DEX price falls back to NAV.
• If $GNDX trades below NAV on a DEX: someone can buy $GNDX cheap on the DEX, redeem it for the basket (or USDC) at NAV, and pocket the difference. They'll keep doing this until the DEX price rises back to NAV.

This is the same arbitrage mechanism that keeps Vanguard ETFs trading near NAV. We didn't invent it. We just inherited it by building the protocol so that minting and redeeming at NAV is something anyone can do, all the time, without permission.

A worked example

Let's walk through a concrete mint. Assume the vault holds $10,000,000 of basket tokens and 9,500,000 $GNDX exist. NAV per token is $10,000,000 ÷ 9,500,000 = $1.0526. You want to deposit $1,000.

• Step 1: Vault value before your deposit: $10,000,000.
• Step 2: Your $1,000 USDC goes through the basket. Suppose DEX friction costs you about $3 across the swaps. The vault value after your deposit is $10,000,997.
• Step 3: You added $997. NAV per token is computed against the new vault value and the pre-deposit supply: $10,000,997 ÷ 9,500,000 = $1.05273. Your $GNDX out: $997 ÷ $1.05273 ≈ 947.1 tokens.

You now hold 947.1 $GNDX. The total supply is 9,500,947.1. The vault holds $10,000,997. Per-token NAV: $10,000,997 ÷ 9,500,947.1 = $1.05263. The NAV is essentially unchanged from before your mint — and that's the point. You absorbed the friction; existing holders saw nothing.

Where fees fit in

Three fees, briefly:

• Mint fee (10 bps default): a small USDC fee taken at deposit time, sent to the FeeCollector.
• Redeem fee (20 bps default): taken in $GNDX at redemption time. Important: the fee is taken before the proportional burn so the math doesn't compound on itself.
• Streaming fee (75 bps annual default): accrues continuously against the vault. This is the only fee that affects NAV directly — every block, the protocol mints a tiny amount of $GNDX to itself proportional to the time elapsed. It's the equivalent of an ETF expense ratio.

All three are bounded by the contract. Mint fee can never exceed 25 bps; redeem fee can range 10–50 bps; streaming fee 25–150 bps. Governance can move them inside those ranges. It can't move them outside.

Common questions

Does the NAV update in real time?

Yes — every read of getNAVPerToken() recomputes from current oracle prices and current vault balances. There's no caching that could go stale.

What if the oracles are wrong?

The protocol uses TWAPs (not spot) and circuit breakers (which clamp prices that diverge more than 30% from the recent TWAP). Stale samples — older than an hour — revert. So a single bad oracle update can't move NAV in a way that would let an attacker mint cheap or redeem rich.

Can I see NAV before I mint?

Always. The mint UI shows you the current NAV and an estimate of $GNDX you'll receive, including expected friction. The transaction modal shows you the actual numbers before you sign.

What happens if I mint when no one else has?

That's genesis. NAV is defined as $1.00 in that case, so your mint behaves like a clean reference deposit. Your USDC × 1e12 (decimal normalization) becomes your $GNDX amount, ignoring the small mint fee.

The takeaway

You don't need to trust us about $GNDX's price. You need to trust two things: the oracles for the underlying basket, and the math we just walked through. Both are public. Both are testable. Both are enforced in the smart contract, not in our promises.

If you want to dig into the actual contracts, the relevant ones are IndexVault.sol, MintEngine.sol, RedeemEngine.sol, and NAVOracle.sol. They're on GitHub. If you'd rather just kick the tires once the protocol is live, that's at gndx.finance.