# $GRAB — Token & On-Chain Game Economy

**Whitepaper v1.0 (Final)** · August 2026 · Solana

A quarterly competitive game economy built around Solana-native ownership, access, competition, and transparent treasury mechanics.

> **Core thesis:** $GRAB is the utility asset connecting access (Battle Pass), competition (Duels / Battle Royale), progression (characters and upgrades), ownership (cosmetics and marketplace), and seasonal competition (leaderboards and distributions).

**What changed from Draft v1.0:** parameters previously marked *illustrative* are now **launch parameters** for Season 1, governed by multisig. Vesting schedules, emission runway, the reward distribution architecture, and the security model are specified. Contract addresses are published in Appendix C at launch.

---

## Contents

1. Executive Summary
2. Design Principles
3. Game & Economic Loop
4. Token Overview
5. Token Utility
6. Battle Pass as the Emission Gate
7. 1v1 Duels
8. 10-Player Battle Royale
9. Quarterly Seasons
10. Seasonal Leaderboard Distributions
11. Token Distribution, Vesting & Emissions
12. Treasury & Platform Revenue
13. DeFi Patterns Applied to Games
14. Sustainability & Economic Metrics
15. Protocol Architecture
16. Authority & Multisig Model
17. Security & Anti-Farming
18. Browser / Backend / Solana Architecture
19. Season 1 Economics
20. Roadmap & Governance
21. Risks & Design Constraints
22. Conclusion
· Appendix A — Launch Parameters
· Appendix B — Glossary
· Appendix C — Contract Addresses
· Disclosure

---

## 1. Executive Summary

GRAB is a browser-based competitive game built around Solana-native transactions. The product exists to make blockchain mechanics useful, understandable and repeatable through competitive gameplay rather than through a speculative token loop.

**$GRAB is a utility token.** It is used for Battle Pass access, character acquisition and progression, cosmetics, competitive modes, marketplace activity and selected ecosystem functions. Players acquire $GRAB through gameplay while holding an active Battle Pass, through external markets, or by holding it as an ecosystem asset. The protocol does not promise a financial return.

The economy runs on **quarterly 12-week seasons**. Each season has a fixed reward budget, a fresh Battle Pass, a ranked leaderboard, seasonal content and a leaderboard-based distribution. Supply is **fixed at 1,000,000,000 $GRAB with mint authority permanently revoked at launch** — seasonal rewards come from pre-funded vaults, never from new issuance.

At launch the game itself is complete. What remains is the on-chain layer: escrow, settlement, access, bounded distribution and treasury custody. That layer is specified in the companion *Smart Contract Technical Requirements v1.0* and is subject to external audit before mainnet deployment.

**Longevity principle:** persistent ownership + recurring competition + recurring access payment + bounded emissions + transparent treasury + quarterly content.

---

## 2. Design Principles

**Utility before speculation.** The token must have reasons to be acquired and spent inside the game before any external market narrative matters.

**Competitive, not extractive.** High-value rewards favour skill, consistency and competition rather than wallet size.

**Fixed supply discipline.** Distribution comes from known allocations. There is no open-ended emission faucet, and after launch there is no mint authority to abuse.

**Recurring demand.** Quarterly passes, seasonal content, upgrades, cosmetics and competitive modes create repeat token demand.

**Treasury over artificial burn.** The protocol does not burn tokens. Duel fees accrue to the treasury and fund servers, development, infrastructure and ecosystem growth. Real revenue is more durable than a deflation narrative.

**On-chain where value matters.** Ownership, escrow, settlement, claims and economic configuration live on Solana. Real-time combat and matchmaking stay off-chain, where they belong.

**Transparent risk controls.** Season budgets, reward caps, treasury policy, authorities and emergency controls are explicit, auditable and published.

**Liveness over control.** No administrative action — including a full emergency pause — can trap a player's escrowed stake. Refund paths remain permissionlessly callable under every protocol state.

---

## 3. Game & Economic Loop

Acquire $GRAB → buy Battle Pass → become eligible to earn → play → compete → earn and rank → spend on progression and cosmetics → re-enter competition → reach the seasonal leaderboard → receive the seasonal distribution → continue into the next season.

| Layer | Primary function | Examples |
|---|---|---|
| Free gameplay | Skill, discovery, retention | Matches, XP, ranking, basic cosmetics |
| Battle Pass | Economic access gate | Token-earning eligibility, premium quests, seasonal progression |
| $GRAB utility | Economic settlement | Pass, characters, upgrades, skins, tournaments, marketplace |
| Competition | High-value activity | 1v1 duels, 10-player Battle Royale |
| Season | Economic clock | 12 weeks, reward budget, leaderboard, content reset |
| Treasury | Platform sustainability | Servers, development, ecosystem, liquidity reserve |

---

## 4. Token Overview

| Parameter | Launch value |
|---|---|
| Token | $GRAB |
| Network | Solana |
| Token program | SPL Token (not Token-2022) |
| Decimals | 9 |
| Model | Utility token |
| Max supply | **1,000,000,000 $GRAB — fixed** |
| Mint authority | **Revoked at TGE**; revocation transaction published |
| Freeze authority | **None from creation** |
| Transfer tax | 0% |
| Token burn | None |
| Duel platform fee | 5% of the total pot (hard-capped at 10% in program code) |
| Battle Pass | Required for gameplay token earning |
| Season cadence | Quarterly, 12 weeks |
| BR match reward ceiling | 2,000 $GRAB, drawn from the season budget |
| Primary reward source | Pre-funded seasonal reward vaults |
| Governance | Squads multisig, 72-hour timelock on program upgrades |

### Supply discipline

Fixed maximum supply is enforced cryptographically, not by policy. The full supply is minted once at TGE and the mint authority is set to `None` in the same launch sequence. From that moment the protocol is structurally incapable of creating a new $GRAB, regardless of who controls the multisig.

Player rewards and ecosystem incentives are funded from known allocations. Remaining inventory stays in designated reserves until released under the governance process, and the program enforces a **lifetime reward cap of 350,000,000 $GRAB** across all seasons that no configuration change can raise.

---

## 5. Token Utility

**Battle Pass** — recurring quarterly access to the token-earning layer and premium seasonal progression.

**Characters** — acquire new playable characters where the design permits.

**Character upgrades** — progression and customisation sinks. Competitive power stays constrained to avoid pay-to-win.

**Skins and cosmetics** — premium cosmetic purchases and limited seasonal collections.

**Duels** — stake $GRAB in 1v1 matches; the winner receives the post-fee pot.

**Tournaments and premium modes** — entry into higher-stakes or special competition.

**Marketplace** — primary settlement asset for player-to-player and platform-to-player transactions (from Season 3).

**Locking and status** — optional time-locking for privileges, access, discounts, social status or governance. Locking never mints new tokens and carries no APY.

**Seasonal competition** — eligibility and participation in quarterly leaderboard distributions.

---

## 6. Battle Pass as the Emission Gate

The defining economic rule: **players do not earn gameplay $GRAB by creating a free account.** An active Battle Pass is required to enter the token-earning layer.

| Player state | Gameplay rewards | Leaderboard | Premium content | Staked duels |
|---|---|---|---|---|
| Free account | None | Can rank and progress | Limited | No |
| Battle Pass holder | Eligible | Eligible | Full seasonal layer | Yes |

This puts a real cost on every additional identity, which is the cheapest and most effective Sybil control available, and it makes the pass a recurring demand sink. The pass grants **economic access, not combat advantage**.

**Passes are non-transferable.** They are program-held state, not tradable NFTs. A secondary market in used passes would let a farm buy cheap identities and defeat the mechanism the pass exists to provide.

### Pass lifecycle

1. Pass opens with the new season.
2. Player acquires it with $GRAB; payment routes to the treasury.
3. The on-chain program records eligibility for that season only.
4. Gameplay accrues claimable rewards, published weekly.
5. At season end the leaderboard is frozen and the seasonal distribution finalised.
6. The next season requires a new pass. Eligibility never carries over.

---

## 7. 1v1 Duels

Duels are the clearest high-value on-chain mechanic. Both players commit an equal stake into program-controlled escrow, the game server reports the result, the program settles deterministically, and **5% of the combined pot routes to the treasury**. Nothing is burned.

**Example.** A stakes 1,000 $GRAB, B stakes 1,000 $GRAB → 2,000 pot. Treasury receives 100 (5%). Winner receives 1,900.

### Protocol rules

- Funds move into escrow before the match becomes active.
- The program records immutable participants, stake, status, timestamps and settlement state.
- **A duel can settle exactly once**, enforced by a one-way state transition.
- The frontend cannot choose or rewrite the winner. Only the authorised result signer can settle, and only to a recorded participant.
- If no valid settlement arrives before the deadline, **anyone** can trigger expiry and both players are refunded in full with zero fee. This path cannot be disabled by any pause or administrative action.
- The 5% fee is deterministic, rounded down, with the remainder to the winner, and visible on-chain.
- Duels above a configured stake threshold (10,000 $GRAB at launch) require a second independent signature to settle, so a single compromised key cannot direct meaningful value.

### Launch stake limits

| Parameter | Value |
|---|---|
| Minimum stake | 100 $GRAB |
| Maximum stake | 50,000 $GRAB |
| Join window | 15 minutes |
| Settlement window | 60 minutes from join |

### Why 5% is revenue, not a burn

The platform intentionally retains value to operate the game, so the fee is protocol revenue. It funds servers, development, infrastructure, marketing, liquidity reserves and ecosystem initiatives. The tokenomics do not depend on deflation.

A useful side effect: at 5% per settlement, wash-trading between two colluding wallets is strictly negative-sum, which makes duel-volume manipulation self-penalising.

---

## 8. 10-Player Battle Royale

Battle Royale is the scalable participation mode. It distributes $GRAB to eligible players under caps at the match, player and season level.

| Placement | Allocation of a 2,000 $GRAB match pool |
|---|---|
| 1st | 800 |
| 2nd | 400 |
| 3rd | 250 |
| 4th | 180 |
| 5th | 120 |
| 6th | 90 |
| 7th | 60 |
| 8th | 40 |
| 9th | 30 |
| 10th | 30 |
| **Total** | **2,000** |

2,000 $GRAB is a **ceiling drawn from the season budget, not a guaranteed mint**. Actual allocation reflects placement, performance, match quality and anti-abuse constraints, and no match can distribute anything once the season's gameplay allocation is exhausted.

### Reward accounting

Match results do not produce individual on-chain transactions. Rewards accrue in the game's ledger and are published **weekly as a Merkle root** covering that epoch's allocations. Players claim from the pre-funded season vault with a proof.

This matters for three reasons: it keeps the number of on-chain transactions proportional to *players*, not *matches*; claims are idempotent by construction, so an allocation can be claimed exactly once; and each published epoch has a 24-hour dispute window before claims open, during which a bad root can be caught and the protocol paused.

Every published tree is made public so any player can independently verify their own allocation and the epoch total.

---

## 9. Quarterly Seasons

A season is the protocol's economic clock: one 12-week season per quarter, four competitive cycles per year.

| Phase | Timing | Purpose |
|---|---|---|
| Announcement | Pre-season | Reveal theme, content, pass, reward budget |
| Launch | Week 1 | Open season and pass |
| Competition | Weeks 1–10 | Matches, progression, duels, BR |
| Final push | Weeks 11–12 | Leaderboard competition and events |
| Snapshot | End of Week 12 | Freeze eligible rankings and rewards |
| Distribution | Transition window | Publish leaderboard root, open claims |
| Claim window | 90 days from season end | Players claim; unclaimed returns to the reward reserve |
| Next season | Following quarter | New pass, content and reward budget |

**Unclaimed rewards return to the player reward reserve and are recycled into future seasons — they are never swept into operating treasury.** Converting unclaimed player value into company revenue would create exactly the wrong incentive around claim friction. The reward reserve is multisig-held, consistent with the custody model in the token distribution table above — not a separate on-chain program account — with the smart contract itself enforcing on-chain that a sweep can never target either treasury account (see the technical requirements document, §6.2, for the exact enforcement mechanics).

### Persistent vs seasonal state

| Persists | Resets each season |
|---|---|
| $GRAB balances | Leaderboard rank |
| Owned characters | Season score |
| Owned skins and cosmetics | Battle Pass |
| Historical achievements | Seasonal reward eligibility |
| Wallet identity | Seasonal progression |
| Treasury history | Season content and events |

---

## 10. Seasonal Leaderboard Distributions

Every season ends with a distribution to high-performing players — a competitive yield mechanism, not passive inflationary staking.

| Tier | Share of the leaderboard pool |
|---|---|
| Top 1% | 25% |
| Top 5% | 25% |
| Top 10% | 20% |
| Top 25% | 15% |
| Top 50% | 10% |
| Participation / long tail | 5% |

Weights are reviewed each season against observed player distributions. A winner-take-most curve over-concentrates rewards and damages retention; a flat curve removes the reason to compete. Season 1 uses the table above and publishes any change at least two weeks before the following season opens.

### Leaderboard integrity

- The score formula is deterministic and **published before the season opens**. It is not changed mid-season.
- Daily and per-match contributions are capped where needed.
- Collusion, boosting, intentional losses, botting and multi-account abuse are actively detected.
- The leaderboard is frozen at season end and the final root published with the distribution methodology.
- Flagged accounts enter a quarantine and dispute process before finalisation, not after.

---

## 11. Token Distribution, Vesting & Emissions

**Total supply: 1,000,000,000 $GRAB. Minted once at TGE. Mint authority revoked.**

| Allocation | % | Tokens | TGE unlock | Cliff | Vesting |
|---|---|---|---|---|---|
| Player rewards | 25% | 250,000,000 | — | — | Released per season into reward vaults; max 32,000,000 / year |
| Community & seasonal airdrops | 10% | 100,000,000 | — | — | Released per season into leaderboard pools; max 8,000,000 / year |
| Ecosystem | 15% | 150,000,000 | 5% | — | 36-month linear, monthly |
| Treasury | 15% | 150,000,000 | 10% | — | 36-month linear, monthly |
| Team | 15% | 150,000,000 | 0% | **12 months** | 36-month linear, monthly after cliff |
| Investors | 10% | 100,000,000 | 0% | **6 months** | 24-month linear, monthly after cliff |
| Liquidity | 10% | 100,000,000 | 100% | — | Deployed to DEX/CEX liquidity and market infrastructure |
| **Total** | **100%** | **1,000,000,000** | | | |

Team, investor, ecosystem and treasury allocations are held in an audited third-party on-chain vesting program with publicly verifiable lock contracts, not in a wallet governed by a manual promise.

### Circulating supply

| Milestone | Approx. circulating | % of supply |
|---|---|---|
| TGE | 132,500,000 | 13.3% |
| Month 12 | ~280,000,000 | 28% |
| Month 24 | ~530,000,000 | 53% |
| Month 36 | ~800,000,000 | 80% |

TGE circulating consists of liquidity (100M), ecosystem TGE unlock (7.5M), treasury TGE unlock (15M) and the Season 1 reward vault (10M). No team or investor tokens circulate at launch.

### Emission rule and runway

Player rewards plus community airdrops form a **bounded emissions bucket of 350,000,000 $GRAB**, enforced as a hard ceiling in program code. The protocol tracks lifetime committed rewards; a season can only allocate what remains.

At the Season 1 rate of 10,000,000 $GRAB per season (40,000,000 per year), the reward bucket has an **8.75-year runway** before requiring governance action. That is a deliberate design choice: the economy should not face a cliff inside its first product cycle.

No unlimited minting. No automatic inflationary APY. No burn dependency. Rewards are funded exclusively from pre-allocated inventory.

---

## 12. Treasury & Platform Revenue

The treasury is the operational foundation of the game, not a passive wallet and not a price-support mechanism.

| Revenue source | Destination |
|---|---|
| 5% duel fee | Platform treasury (operations) |
| Battle Pass payments | Treasury / platform operations |
| Marketplace fees | Treasury / ecosystem / liquidity reserve |
| Cosmetics and upgrades | Treasury / content production |
| Tournament fees | Prize pool + platform allocation |
| Other platform revenue | Defined treasury policy |

### Treasury waterfall

| Share | Use |
|---|---|
| 40% | Operations: servers, infrastructure, recurring costs |
| 25% | Ecosystem: events, content, partnerships |
| 20% | Liquidity reserve |
| 15% | Strategic reserve and future development |

These are policy targets set by the multisig, not hardcoded protocol rules. The treasury may retain $GRAB and/or convert a portion into operating assets under the project's legal, accounting and treasury policies.

**Reporting commitment.** A quarterly treasury report is published within 30 days of each season's end covering: opening and closing balances by vault, revenue by source, expenditure by category, tokens released into reward vaults, and total claimed versus swept. All addresses are public (Appendix C) and independently verifiable.

---

## 13. DeFi Patterns Applied to Games

The model borrows what fits a competitive game and rejects what does not.

**Locking over inflationary staking.** Users can lock $GRAB for utility, access, discounts, status or governance. Locking never mints tokens.

**Bounded emissions.** Reward vaults behave as controlled, pre-funded emission budgets with hard ceilings.

**Revenue-backed ecosystem.** Duel and platform revenue fund real operating activity rather than relying on issuance.

**Treasury runway.** Liquid reserves are measured against monthly operating costs and reported quarterly.

**Liquidity as infrastructure.** Sufficient market depth for entry and exit, without automatic buybacks as a price mechanism.

**Economic feedback.** Next-season budgets respond to measured participation and revenue, within governance limits and never above the lifetime cap.

**Explicitly avoided:** rebasing, reflection taxes, automatic redistribution, and any price-stabilisation promise.

---

## 14. Sustainability & Economic Metrics

Token price is not the primary health metric. The economy is judged on whether players consume, earn, hold and return.

| Metric | Definition | Season 1 target |
|---|---|---|
| Sink / emission ratio | $GRAB spent in game ÷ $GRAB distributed | ≥ 1.0 |
| Earning coverage | Average seasonal earnings ÷ pass cost | 0.6–0.8× average |
| Pass conversion | Pass holders ÷ active eligible accounts | ≥ 15% |
| Treasury runway | Liquid treasury ÷ monthly operating cost | ≥ 18 months |
| Token velocity | Transactional volume ÷ average circulating supply | Monitored |
| Spend rate | Players spending ÷ players earning | ≥ 0.7 |
| Duel volume | Total pot volume per day / week / season | Growth trend |
| Reward concentration | Share earned by top percentiles | Top 1% ≤ 30% |
| Reward leakage | Rewards tied to flagged activity | ≤ 2% |
| Retention | D1 / D7 / D30 / seasonal return | Published each season |
| Net supply change | Distributions − treasury inflow; no burn assumed | Monitored |

### Target economy shape

Casual players earn less than they spend. Strong competitors cover much of their recurring game costs. Elite players earn meaningful seasonal rewards. This keeps competitive performance valuable without turning the whole population into net token exporters — which is the failure mode that has ended most play-to-earn economies.

---

## 15. Protocol Architecture

The smart contract layer is intentionally small. The browser and game server handle real-time execution; Solana handles ownership, escrow, settlement, claims and economic configuration.

| Account | Purpose |
|---|---|
| `GlobalConfig` | Authorities, treasuries, parameters, pause state, current season, lifetime reward cap |
| `Season` | Season id, window, allocations, caps, leaderboard root, claim deadline |
| `RewardVault` | Pre-funded $GRAB inventory for one season |
| `RewardEpoch` | Weekly Merkle root, epoch total, claimed total, dispute window |
| `ClaimBitmap` | Replay protection for claims |
| `BattlePass` | Non-transferable seasonal access record |
| `PlayerSeason` | Eligibility, per-player claimed totals, duel activity |
| `Duel` | Participants, stake, status, timestamps, winner, fee |
| `DuelEscrow` | Program-controlled custody of both stakes |
| Treasury vaults | Separated operational and ecosystem balances |

### Core instructions

`initialize_config` · `propose_authority` / `accept_authority` · `set_result_authority` · `set_duel_params` · `set_pause_flags` · `create_season` · `fund_reward_vault` · `activate_season` · `snapshot_season` · `finalize_leaderboard` · `sweep_unclaimed` · `activate_battle_pass` · `create_duel` · `join_duel` · `settle_duel` · `cancel_duel` · `expire_duel` · `publish_reward_epoch` · `claim_gameplay_reward` · `claim_season_reward` · `withdraw_treasury`

### Invariants

- A duel can never settle twice.
- Escrowed funds leave only through authorised settlement, cancellation or timeout.
- A reward allocation can never be claimed twice.
- Season rewards can never exceed the season allocation.
- Lifetime rewards can never exceed 350,000,000 $GRAB.
- Treasury fee calculation is deterministic and capped at 10% in code.
- Only the multisig can change sensitive configuration.
- No instruction can mint $GRAB, and no mint authority exists after launch.
- Refund paths remain callable under every pause configuration.

Full account layouts, instruction preconditions, error codes and the complete invariant set are specified in *GRAB Smart Contract Technical Requirements v1.0*.

---

## 16. Authority & Multisig Model

Early governance uses a multisig rather than a single administrator key. Operational keys are narrowly scoped and hold no arbitrary transfer authority.

| Authority | Responsibilities | Custody |
|---|---|---|
| Upgrade multisig | Program upgrades, behind a 72-hour timelock | Squads v4, 4-of-7 |
| Operations multisig | Treasury, season budgets, vault funding, emergency pause, high-risk configuration | Squads v4, 3-of-5 |
| Game program | Escrow, settlement, reward claims, deterministic fee routing | Program-derived |
| Result signer | Authorised match-result submission only, within program constraints | KMS-backed hot key, rotated quarterly |
| Cosigner | Second approval for high-stake duel settlement | Separate KMS, separate operators |
| Player wallet | Signs player-initiated economic actions | Player |
| Indexer | Read-only aggregation | — |

**Critical security boundary: the backend cannot transfer a player's $GRAB.** It can only declare a winner for a duel that is already locked, and the program routes funds along fixed rails to that recorded participant. It cannot mint, cannot reach the treasury, and cannot alter configuration.

---

## 17. Security & Anti-Farming

Because $GRAB is economically valuable, the game assumes adversarial behaviour from day one.

### Threats

Sybil farming and wallet clusters · bots and scripted play · match fixing · intentional losses and boosting · multi-account leaderboard manipulation · reward claim replay · backend signer compromise · result authority abuse · treasury key compromise · parameter abuse or sudden reward inflation · frontend spoofing and client-side winner manipulation · malicious program upgrade.

### Controls

- Battle Pass gate places a real cost on every additional identity.
- Per-match, per-epoch and per-season reward caps enforced on-chain.
- Minimum match-quality and eligibility rules.
- Rate limiting, anomaly detection, server-side anti-cheat and behavioural analysis.
- Leaderboard dispute and quarantine process before finalisation.
- 24-hour dispute window between reward publication and claim opening.
- Multisig-controlled emergency pause that can never strand escrowed funds.
- Permissionless timeout and recovery paths for incomplete duels.
- Second-signature requirement for high-stake duel settlement.
- Signer rotation, key isolation, hardware-backed custody.
- 72-hour timelock and verifiable builds on program upgrades.
- Independent indexing, hourly reconciliation and public monitoring for abnormal transfers.

### Audit commitment

The program undergoes external security audit before mainnet deployment. Reports are published in full, including unremediated findings and the reasoning for accepting them. A bug bounty runs from launch.

---

## 18. Browser / Backend / Solana Architecture

| Layer | Responsibility |
|---|---|
| Browser client | Rendering, input, wallet connection, signing, game UI |
| Game server | Real-time state, matchmaking, combat authority, anti-cheat |
| API / orchestrator | Queues, match lifecycle, season data, analytics |
| Merkle builder | Converts reward ledgers into canonical, publicly verifiable trees |
| Solana program | Escrow, token movement, claims, settlement, rules |
| Indexer | Transaction history, leaderboards, analytics, reconciliation |
| Treasury / multisig | Administrative controls and capital management |

**Design rule:** value-bearing state on-chain, real-time combat off-chain. Movement, individual hits and high-frequency gameplay events never touch Solana.

### Meaningful transaction strategy

Organic Solana activity comes from economically meaningful actions: Battle Pass purchases, duel deposits and settlements, tournament entry, reward claims, character and cosmetic purchases, marketplace settlement, locking and seasonal claims. The design deliberately does **not** add artificial transactions to inflate transaction-count metrics — which is also why match results are batched into weekly claims rather than written per match.

---

## 19. Season 1 Economics

A working model, not a forecast. Actual values are recalibrated each quarter from observed data.

| Parameter | Value |
|---|---|
| Season length | 12 weeks |
| Target active players | 100,000 |
| Target pass conversion | 20% |
| Pass price | 500 $GRAB |
| Pass demand at 20,000 buyers | 10,000,000 $GRAB |
| Season reward budget | 10,000,000 $GRAB |
| — Gameplay rewards | 6,000,000 |
| — Leaderboard pool | 2,000,000 |
| — Events and tournaments | 1,000,000 |
| — Season reserve | 1,000,000 |
| Per-player season reward cap | 25,000 $GRAB |
| Per-player weekly reward cap | 3,000 $GRAB |
| Average duel pot | 2,000 $GRAB |
| Duel fee | 5% to treasury |

At these values, **pass demand alone offsets the full season reward budget** for a sink/emission ratio of roughly 1.0 before counting duel fees, cosmetics, upgrades and tournaments. The core question is never whether 10 million tokens are distributed — it is how much is absorbed relative to how much is released. That ratio is measured and republished every season.

### Earning coverage

| Archetype | Seasonal earnings | Pass coverage |
|---|---|---|
| Casual | ~150 $GRAB | 0.30× |
| Average | ~350 $GRAB | 0.70× |
| Strong | ~550 $GRAB | 1.10× |
| Elite | 1,500+ $GRAB | 3.00×+ |

The target shape: the average player cannot trivially self-fund indefinitely, while strong and elite players earn meaningfully for skill and persistence. Values are calibrated from retention, spend and reward-leakage data each season.

---

## 20. Roadmap & Governance

| Phase | Focus |
|---|---|
| Pre-launch | Token mint and authority revocation, program build, audit, treasury multisig, Battle Pass, reward vaults, testnet and soak |
| Season 1 | Player acquisition, on-chain onboarding, economic telemetry, generous but bounded incentives |
| Season 2 | Tune reward budgets, sinks, pass economics and anti-farming controls |
| Season 3 | Marketplace program, expanded tournaments, social layer, higher-value competition |
| Season 4 | Annual championship, larger ecosystem events, mature treasury policy, first governance transfer of non-critical parameters |

### Governance philosophy

The first stage prioritises safety and predictability. Parameter changes are slow, transparent and subject to multisig approval with public announcement before taking effect. Over time, non-critical parameters — reward curve weights, cosmetic pricing, event budgets — move toward community governance, while security-critical controls (upgrade authority, treasury withdrawal, pause) remain constrained and timelocked.

---

## 21. Risks & Design Constraints

**Speculative sell pressure.** Rewards can be sold immediately, especially after seasonal distributions. *Mitigation:* strong utility sinks, recurring passes, controlled emissions, meaningful progression, and a claim window that spreads distribution rather than concentrating it on one day.

**Pay-to-win pressure.** Direct token-to-power conversion distorts competition. *Mitigation:* competitive power stays constrained; $GRAB is for access, ownership, customisation and progression.

**Sybil farming.** Multiple wallets multiply rewards. *Mitigation:* the pass cost per identity, on-chain per-player caps, anti-bot and behavioural analysis, leaderboard review.

**Result authority compromise.** A compromised hot signer could direct duel outcomes. *Mitigation:* exposure bounded to locked duels, stake ceilings, cosigning above threshold, hourly reconciliation, rotation, emergency pause. This risk is disclosed rather than minimised.

**Treasury concentration.** A large treasury creates governance risk. *Mitigation:* multisig, vault separation, published spending policy, quarterly public reporting.

**Reward exhaustion.** A season can burn through its allocation early. *Mitigation:* pre-funded budgets, match and player ceilings, remaining-allocation checks on every claim.

**Low utility.** With no reason to spend, velocity becomes dominated by selling. *Mitigation:* pass, progression, cosmetics, competition, marketplace and social sinks; the sink/emission ratio is a tracked, published target.

**Liquidity risk.** Thin markets increase slippage. *Mitigation:* dedicated liquidity reserve and gradual market infrastructure.

**Game weakness.** Tokenomics cannot fix a weak core game. Retention and fun remain the primary demand engine.

**Regulatory and legal risk.** Token distribution, markets, prizes and monetisation create jurisdiction-specific obligations, and staked 1v1 competition for value may be treated differently across jurisdictions. Final launch design and geographic availability require legal review in each relevant jurisdiction.

---

## 22. Conclusion

$GRAB is the economic utility layer of a competitive Solana game, not a yield product. Its sustainability depends on connecting token demand to actual game activity: pass access, competitive entry, progression, cosmetics, marketplace usage and recurring quarterly participation.

The protocol uses fixed supply with revoked mint authority, bounded seasonal reward vaults with a hard lifetime ceiling, treasury-funded operation, a 5% duel fee, and performance-based seasonal distributions. It avoids token burns, unlimited emissions, automatic staking APY and artificial price support.

**Long-term success = game quality × player retention × token utility × economic discipline.** Tokenomics amplifies a good game; it does not substitute for one.

---

## Appendix A — Launch Parameters

| Parameter | Value |
|---|---|
| Max supply | 1,000,000,000 $GRAB |
| Decimals | 9 |
| Mint authority | Revoked at TGE |
| Freeze authority | None |
| Lifetime reward cap | 350,000,000 $GRAB |
| Duel fee | 5% (code cap 10%) |
| Min / max duel stake | 100 / 50,000 $GRAB |
| High-stake cosign threshold | 10,000 $GRAB |
| Duel join / settle window | 15 min / 60 min |
| Season length | 12 weeks |
| Season 1 pass price | 500 $GRAB |
| Season 1 reward budget | 10,000,000 $GRAB |
| Per-player season cap | 25,000 $GRAB |
| Per-player weekly cap | 3,000 $GRAB |
| BR match ceiling | 2,000 $GRAB |
| Reward epoch cadence | Weekly |
| Dispute window | 24 hours |
| Claim window | 90 days after season end |
| Upgrade timelock | 72 hours |
| Multisig thresholds | 3-of-5 operations, 4-of-7 upgrade |

### Pre-launch checklist

- [ ] Mint created with 9 decimals, no freeze authority
- [ ] Full supply minted, mint authority revoked, transaction published
- [ ] Team, investor, ecosystem, treasury allocations locked in verifiable vesting contracts
- [ ] Program audited by an independent firm; report published
- [ ] Bug bounty live
- [ ] Multisig configured, signers verified, upgrade timelock active
- [ ] Season 1 vault funded and verified on-chain
- [ ] Leaderboard score formula published
- [ ] Anti-farm rules and dispute process published
- [ ] Quarterly reporting dashboard live
- [ ] Legal review complete for launch jurisdictions
- [ ] All addresses published in Appendix C

---

## Appendix B — Glossary

**Battle Pass** — non-transferable seasonal access record required to earn $GRAB from gameplay.
**Duel** — 1v1 match with equal stakes held in program escrow; winner takes the pot less a 5% fee.
**Epoch** — a weekly reward publication within a season, represented by a Merkle root.
**Merkle root** — a cryptographic commitment to a full list of reward allocations, allowing any player to prove their entry without publishing 100,000 transactions.
**Reward vault** — a pre-funded, season-specific token account from which all seasonal rewards are paid.
**Sink** — any mechanism that removes $GRAB from player circulation into the treasury.
**Snapshot** — the freezing of leaderboard state at season end.

---

## Appendix C — Contract Addresses

Published at launch and permanently maintained on the project website.

| Item | Address |
|---|---|
| $GRAB mint | *(published at TGE)* |
| `grab_core` program | *(published at deployment)* |
| GlobalConfig PDA | *(published)* |
| Operations treasury | *(published)* |
| Ecosystem treasury | *(published)* |
| Operations multisig | *(published)* |
| Upgrade multisig | *(published)* |
| Vesting contracts | *(published)* |
| Mint authority revocation tx | *(published)* |

---

**Disclosure.** This document is a product and economic design specification. It is not legal, investment, tax, accounting or financial advice, and it is not an offer or solicitation to sell securities or any financial instrument. $GRAB is designed as a utility token for use within the GRAB game; the protocol makes no promise, representation or guarantee of financial return, price appreciation, or liquidity. Parameters stated here are launch targets subject to governance and to validation against real player behaviour, market conditions and legal requirements. Token distribution, competitive staking, prize mechanics and monetisation may be regulated differently across jurisdictions; availability may be restricted accordingly. Participants are responsible for their own compliance and tax obligations. Smart contracts carry inherent technical risk, including risk of loss, notwithstanding audit.