veGAME

veGAME (vote-escrowed GAME) is the non-transferable governance and revenue-share token issued when $GAME holders lock their tokens in the VeGAME.sol contract.

Why veGAME?

The vote-escrow model aligns voting power with long-term commitment:

• Short-term holders have minimal voting influence
• Long-term committed holders earn more governance power and more fee revenue
• Flash loan attacks are impossible — votes require tokens locked before the proposal snapshot

Locking Mechanics

To receive veGAME, call VeGAME.lock(gameAmount, durationSeconds) with a valid lock duration:

Lock Duration	Seconds	veGAME Multiplier	Example: 10,000 GAME
3 months	7,776,000	0.25×	2,500 veGAME
6 months	15,552,000	0.50×	5,000 veGAME
1 year	31,536,000	1.00×	10,000 veGAME
2 years	63,072,000	2.00×	20,000 veGAME
4 years	126,144,000	4.00×	40,000 veGAME

Exact Durations Only

The smart contract accepts only these five durations. Any other value reverts with InvalidLockDuration. There are no intermediate options.

Linear Decay

veGAME balance is not static — it decays linearly back to zero as the lock approaches expiry:

veBalance(t) = gameAmountLocked × multiplierBps × (lockEnd − t) / (lockDuration × 10,000)

Where:

• t = current timestamp
• lockEnd = timestamp when lock expires
• lockDuration = lockEnd − lockStart
• multiplierBps = 2500, 5000, 10000, 20000, or 40000

Key behaviour:

• At lock start: full veGAME balance (maximum voting power)
• At halfway point: exactly half the original balance remains
• At lock expiry: exactly zero — $GAME becomes withdrawable

Managing Your Lock

Extending a Lock

Call extendLock(newDurationSeconds) to reset the lock to a new (longer) duration from the current time. The new duration must result in a later lockEnd than the current one. Your veGAME balance immediately recalculates at the new multiplier.

Adding to a Lock

Call addToLock(additionalGameAmount) to add more $GAME to an active (non-expired) lock at the same multiplier.

Withdrawing

After lock expiry, call withdraw() to reclaim your full $GAME amount. veGAME balance is exactly zero at expiry, so no voting power is lost by waiting.

Fee Revenue Distribution

veGAME holders receive a share of weekly protocol fee revenue as $GAME (Shape A pipeline):

1. FeeCollector accumulates mint fees (USDC) and streaming/exit fees ($GNDX on the contract).
2. Contract $GNDX is swapped to USDC; then a treasury USDC cut is sent out (treasurySplitBps).
3. The post-treasury USDC remainder is swapped once to $GAME (with a minGameOut slippage floor).
4. That $GAME is split between VeGAME (staker leg) and burn (buyback leg); VeGAME credits lockers pro-rata using the same accumulator model as before (weight = initial ve at lock, not live decaying balance).

Your share of each staker-leg deposit:

yourReward ∝ yourInitialVeWeight / totalInitialVeWeights × gameToStakers

Longer locks earn more — both because of the higher initial multiplier and because decay is slower for longer locks.

Delegation

$GAME holders who prefer not to actively vote can delegate their veGAME voting power to a trusted community member:

• Call delegate(delegateeAddress) to delegate
• Delegation is revocable at any time — just call delegate(anotherAddress) or delegate(yourOwnAddress)
• Delegation does not transfer tokens — you retain ownership and fee revenue
• The governance portal highlights recognized delegates with their voting histories

Non-Transferability

veGAME is non-transferable. It cannot be sold, gifted, or used as collateral. It represents a commitment to the protocol, not a tradeable asset.

---

See also: Locking $GAME · Governance · veGAME Mechanics