# GEXI Whitepaper v1.0 Date: April 23, 2026 ## Executive Summary Gexi is a consumer gaming network built on Sui. It combines embedded wallet onboarding, arcade gameplay, social competition, rewards, and token settlement in one repeat-use product. The current stack already includes: - Sui zkLogin onboarding with embedded wallet creation - On-chain store settlement for Ticket purchases - Signed GEXI reward claims with voucher, nonce, and expiry controls - Duel stake escrow and payout logic - Brawl payout logic with burn-aware settlement - Live match prize systems - Weekly XP leagues - Checkpoint-based anti-cheat validation - Airdrop integrity controls and risk scoring The central thesis is straightforward: crypto gaming will not be won by putting every interaction on-chain. It will be won by reducing onboarding friction, increasing play frequency, and routing value-bearing actions through verifiable settlement when trust matters. --- ## 1. Investment Thesis Gexi is structured so product quality and token throughput reinforce each other. The platform uses a fast product layer for sessions, missions, rankings, and social activity, while tying store purchases, reward claims, escrow logic, payout events, and burn accounting back to Sui. The economic thesis is simple: product usage should create token throughput through access, competition, and settlement, not rely mainly on treasury-funded distribution. Tickets support frequent gameplay, while GEXI handles access purchases, stake-based competition, reward settlement, and campaign distribution. ### Core Bet Lower onboarding friction and stronger repeat competition can make distribution, retention, and token demand reinforce each other instead of operating as separate layers. --- ## 2. Why Now The timing case is stronger in 2026 because wallet abstraction is ready, emission-first GameFi has weakened, and product retention matters more than narrative alone. ### 2026 favors product-first GameFi The market is rewarding products that retain attention, not emissions without usage. ### Wallet abstraction is production-ready zkLogin, embedded onboarding, and server-assisted wallet flows remove much of the wallet-first setup tax. ### Mobile replay loops fit the category Short sessions, social rivalry, and ranked replays create repeat behavior more naturally than one-off claims. ### Studios still need distribution A shared wallet, rewards, social, and competition layer gives studios more leverage than isolated tooling. --- ## 3. Product Scope Gexi already operates as a multi-surface gaming product rather than a single utility page. The user journey spans onboarding, wallet activity, Ticket acquisition, gameplay, reward claiming, competition, and social engagement in one account system. ### Current product footprint - Game catalog: Sweet Fruits, Teeter Towers, Hoploop, Twist, Village Defense, and Boing - Core surfaces: wallet, games, rewards, store, social, notifications, and competition - Competition formats: standard sessions, live matches, duels, brawls, and weekly XP seasons - Reward system: tasks can currently pay in Tickets, SUI, or GEXI - Growth system: airdrop points, social missions, referrals, and leaderboard loops --- ## 4. Architecture Gexi is intentionally hybrid: fast product interactions stay server-orchestrated, while economic finality is routed through explicit Sui transactions. ### Core layers - Client layer: Next.js product surfaces handle onboarding, game launch, store, rewards, wallet, social, live competition, and developer-facing distribution views - Identity and wallet layer: Sui zkLogin provides Google-based wallet access and session continuity without forcing a traditional wallet-first onboarding path - Signing layer: the client generates an ephemeral zkLogin signing context, while backend-authenticated Shinami services provide wallet address, salt, and zkProof generation without exposing wallet access keys in the browser - Server orchestration: Supabase-backed application services coordinate profile state, session lifecycle, checkpoints, leaderboards, airdrop controls, burn records, and payout preparation - Game integrity layer: checkpoint nonce chains, score windows, elapsed-time validation, anti-cheat audits, and replay/session rules filter high-frequency gameplay events before payout logic is accepted - On-chain execution: Move contracts on Sui execute pack purchases, reward claims, duel stake locking, payout authorization, and vault burn-capable treasury operations - Scheduled operations: background jobs finalize brawls, process automatic payouts, roll live competition windows, expire stale claims, and reconcile burn or reward records ### Transaction and settlement flows - Wallet flow: Google OIDC starts the zkLogin flow, backend routes call Shinami zkWallet for address and salt plus Shinami zkProver for zkProofs, and the client assembles the final zkLogin signature before submission to Sui - Store flow: client requests a server-built transaction, user signs on Sui, `buy_pack` emits `PackPurchased`, then the backend reconciles the on-chain event before Tickets are credited - Reward flow: backend prepares a signed ED25519 voucher with amount, nonce, and expiry, user executes `claim_reward`, and nonce usage prevents duplicate redemption - Duel flow: both players lock stake through `lock_stake`, the result service determines the payout instruction, and the winner path applies a 10% burn commission before settlement - Brawl flow: participant entry builds the pool as `entry_fee_gexi × participant_count`, then finalization distributes winner or split payouts and records burn events when applicable - Session flow: games submit started-at timestamps, checkpoints, ticket context, and final scores; invalid duration, missing context, or malformed values are rejected before ranking or rewards ### Why this matters High-frequency interactions such as sessions, checkpoints, rankings, missions, and social activity stay fast. Store settlement, reward claims, stake locking, and payout verification move through explicit on-chain flows that users, operators, and infrastructure partners can verify. --- ## 5. Implemented Systems This is not a concept-only stack. Core economic and gameplay systems are already expressed in code, contracts, and scheduled operations. ### Current status - On-chain store settlement: Move store module supports pack purchase events, paused state, configurable pack pricing, vault accounting, and burn-capable admin sweep - Reward vault claims: Move rewards module supports signed voucher claims, nonce replay protection, expiry checks, vault funding, and autopayout paths - Duel escrow: Move duel module supports stake locking, payout claims, limits, verifier control, and 10% burn commission on winner payouts - Live competition payouts: live matches currently use a default 1,000 GEXI prize pool configuration with rank-weighted bracket logic across the top 125 ranks - Weekly XP league: weekly XP seasons currently use a default 1,000 GEXI prize pool configuration with bracket-based reward allocation across the top 60 ranks - Session integrity: gameplay sessions record checkpoint nonce chains, checkpoint hashes, score windows, and anti-cheat audit data before final reward logic is accepted --- ## 6. GEXI Utility GEXI sits at the value layer of the platform: access spend, player-funded competition, reward settlement, and campaign distribution. ### Utility surfaces #### Store utility GEXI is spent to acquire Ticket packs. Tickets are only credited after a verified on-chain `PackPurchased` event is observed and reconciled. #### Reward utility GEXI is distributed through reward claims, live competition prizes, weekly XP systems, and platform incentive programs, but those flows are not the full economic story. #### Competitive utility Duels and brawls use GEXI-denominated entry amounts, turning player-versus-player and group competition into direct token throughput rather than treasury-funded farming alone. #### Campaign utility Partner and ecosystem missions can distribute GEXI-denominated incentives inside an already active gaming surface. #### Strategic utility Treasury, reserve, liquidity, and partnership allocations support market formation and controlled platform expansion. ### Demand model | Demand layer | How the token moves | Why it matters | |---|---|---| | Ticket and store layer | Users purchase GEXI-powered Ticket packs to access high-frequency gameplay loops | Demand originates from access and replay, not only from speculative holding | | Duel layer | Two players each lock GEXI on-chain before the winner path distributes net payout and burns 10% of the gross winner amount | Value transfers between players and burn mechanics can scale without matching treasury inflation | | Brawl layer | Each participant contributes entry GEXI, the pool scales with headcount, and settlement routes value to winners or split outcomes while recording burn events where applicable | The prize pool can grow with competition density rather than requiring a fixed treasury subsidy for every match | | Treasury-funded reward layer | Live matches, weekly XP leagues, and campaigns distribute visible reward budgets to seed competition, discovery, and re-engagement | Treasury rewards are positioned as activation and retention budgets, not the only reason the token moves | ### Demand engine | Demand engine | How behavior converts to throughput | Why it matters | |---|---|---| | Replay engine | Short-session games, visible score improvement, and low-friction re-entry convert retention into recurring Ticket demand | The core loop is built to generate repeat access spend, not only one-time activation | | Social rivalry | Players can compare runs, challenge friends, and re-enter ranked formats inside the same account graph | Competition density rises when users bring opponents back into the same surface | | Stake-based formats | Duels and brawls move GEXI between players through performance-based settlement | Higher engagement can increase token throughput without matching treasury emissions | | Event cadence | Live matches, weekly XP, missions, and progression pacing create recurring return points across the week | Demand is supported by repeat product rhythms rather than a single reward moment | ### Strategic interpretation GEXI is not designed as a pure reward token. Treasury-funded rewards are only one layer. Duels and brawls move value directly between players while preserving burn-linked settlement on winner paths, making GEXI structurally different from an emission-only play-to-earn loop. --- ## 7. Economy Model The core economy is already parameterized in code rather than left to a vague reward narrative. ### Live parameters - Ticket entry pricing: 1 / 5 / 10 / 50 / 100 / 500 Tickets cost 2 / 10 / 20 / 100 / 200 / 1000 GEXI - Reward pacing: standard sessions grant 2 XP, live-match replays 4 XP, duel participation 8 XP, brawl participation 10 XP, and task claims 40 XP - Progression rebate: every level currently grants 1 Ticket, creating a measured gameplay rebate loop without making Tickets redeemable back into GEXI - Competition budgets: live matches run on a fixed 1,000 GEXI pool every 48 hours and weekly XP seasons run on a fixed 1,000 GEXI weekly pool unless governance updates those parameters - Burn-aware settlement: store vault balances are burnable and competitive payouts currently apply a 10% burn commission on winner-style settlement paths ### Throughput examples | Example | Current parameters | Why it matters | |---|---|---| | 100 purchases of the 10-Ticket pack | 100 × 20 GEXI = 2,000 GEXI sent to the store vault and reconciled against 1,000 Ticket credits | Gameplay capacity scales with direct token spend rather than uncapped free issuance | | 1,000 minimum-stake duels | Minimum duel stake is 20 GEXI per side, so gross notional throughput is 40,000 GEXI; a 10% winner burn implies 4,000 GEXI burned across resolved payouts | Competitive usage can generate measurable sink pressure even at minimum entry sizes | | 50 brawls with 10 players at 20 GEXI entry | Each brawl builds a 200 GEXI pool, creating 10,000 GEXI aggregate prize throughput; burn-aware settlement can remove roughly 1,000 GEXI before payout on winner-style outcomes | Group competition scales demand with participation count rather than requiring fixed treasury spend per match | | 30-day prize schedule at current defaults | Live matches distribute about 15,000 GEXI over fifteen 48-hour rotations; weekly XP adds about 4,000 to 5,000 GEXI depending on calendar alignment | Recurring reward budgets are visible, parameterized, and separable from store sinks and competitive burns | These examples are illustrative, not forward guidance. The point is that spend, rewards, and burn behavior can already be modeled from live parameters. --- ## 8. Ticket Layer Tickets are the high-frequency access layer that makes the gameplay economy operationally cleaner. ### Current design - Purpose: gameplay entry, replays, and repeat session access - Current pack ladder: 1 / 5 / 10 / 50 / 100 / 500 Tickets - Current prices: 2 / 10 / 20 / 100 / 200 / 1000 GEXI - Acquisition: verified store settlement and selected campaign or airdrop grants - Redemption: Tickets are not redeemable back into GEXI ### Why it matters Tickets give Gexi a dedicated operational unit for session entry and replays. That separation allows GEXI to remain the value-bearing asset while Ticket pricing and Ticket grants can be balanced for gameplay quality, retention, and campaign efficiency. --- ## 9. Tokenomics GEXI has a fixed total supply of 100,000,000 tokens, with allocation and release schedules designed to separate launch liquidity from long-duration network buildout. The current allocation model combines long-tail game economy capacity, treasury and reserve flexibility, launch liquidity support, team alignment, and ecosystem growth budgets. Vesting matters because Gexi is designed as a long-duration consumer network, not a short-cycle emission event. ### Allocation overview | Allocation | Share | TGE | Cliff | Vesting | Purpose | |---|---:|---:|---|---|---| | Game Economy | 23% | 0% | 3 months | Linear over 60 months | Player rewards, gameplay incentives, platform activity | | Presale | 20% | 10% | 1 month | Linear over 6 months | Early backers; unsold allocation intended to be burned | | Staking + Liquidity + MM + LP | 20% | 10% | None | Remaining 90% linear over 24 months | Liquidity depth and launch support | | Treasury / Strategic Reserve | 15% | 0% | 6 months | Linear over 24 months | Strategic reserve and expansion flexibility | | Team | 10% | 0% | 6 months | Linear over 24 months | Long-term alignment | | Marketing | 5% | 10% | None | Remaining 90% linear over 24 months | Launch and growth campaigns | | Ecosystem + Developer + Partnerships | 7% | 10% | None | Remaining 90% linear over 24 months | Developer onboarding and partner incentives | ### Indicative TGE state | Launch metric | Current view | Interpretation | |---|---|---| | Indicative TGE unlocked supply | 5.2% of total supply, or 5,200,000 GEXI | Calculated from the declared TGE portions of Presale, Liquidity/MM/LP, Marketing, and Ecosystem allocations before any unsold-presale burn adjustment | | Indicative first full post-TGE monthly unlock | 1,200,000 GEXI | Made up of the linear month-one releases from Liquidity/MM/LP, Marketing, and Ecosystem allocations under the current schedule | | Largest scheduled unlock pressure | Presale linear vesting after its cliff | The Presale bucket has the fastest release cadence in the declared model, which is why market formation discipline matters around launch and early post-launch trading | ### Unlock visibility | Allocation | TGE unlocked | Unlock begins | Indicative monthly unlock | |---|---:|---|---:| | Game Economy | 0 | Month 4 | 383,333 GEXI / month | | Presale | 2,000,000 | Month 2 | 3,000,000 GEXI / month | | Staking + Liquidity + MM + LP | 2,000,000 | Month 1 | 750,000 GEXI / month | | Treasury / Strategic Reserve | 0 | Month 7 | 625,000 GEXI / month | | Team | 0 | Month 7 | 416,667 GEXI / month | | Marketing | 500,000 | Month 1 | 187,500 GEXI / month | | Ecosystem + Developer + Partnerships | 700,000 | Month 1 | 262,500 GEXI / month | ### Emission Interpretation The allocation model only works if emissions remain tied to product growth, competition quality, and real transaction demand. In practice, that means pairing fixed supply with staged unlocks, visible reward budgets, and disciplined market formation. ### Emission vs burn balance - Scheduled emissions: unlocks and reward budgets are knowable from the declared vesting schedule and live competition parameters - Usage-linked burn: store vault burns, duel commissions, and brawl burn events depend on actual platform activity rather than a guaranteed deflation schedule - Net circulating behavior: net supply expands when scheduled unlocks and distributed rewards exceed usage-linked burns, and tightens when transaction demand and burn throughput rise faster than active emissions - Measurement layer: burn activity is already structured for daily, weekly, monthly, and cumulative reporting through dedicated burn-event tables and views The goal is to make store spend, participant-funded competition, and usage-linked burn a larger share of token movement over time, while treasury rewards remain targeted budgets for activation, discovery, and re-engagement. --- ## 10. Competitive Positioning Gexi is positioned around a repeat-use gaming surface rather than a single-token narrative or a single-title product. ### Why Gexi can win - Emission-first GameFi: many systems lead with token farming and then search for retention. Gexi starts with replayable arcade loops, then attaches value-bearing actions to the moments that users already repeat - Telegram and mini-app arcades: these products often solve distribution but not durable on-chain value capture. Gexi combines low-friction onboarding with explicit store settlement, prize systems, burn paths, and wallet-native rewards - Standalone Web2 arcade portals: they can deliver lightweight gameplay but generally stop at ad or IAP monetization. Gexi extends the same loop with verifiable token settlement, partner campaigns, and on-chain competition - Isolated game studios: single-title teams usually rebuild wallet, rewards, and competition infrastructure game by game. Gexi’s shared stack turns identity, rewards, store, and competition into reusable network infrastructure ### Moat structure - Integrated system moat: the defensibility is not one mechanic in isolation. It is the combination of embedded onboarding, Tickets, replay loops, live competition, reward validation, burn accounting, and partner distribution inside one stack - Data and balancing moat: checkpoint proofs, session-quality thresholds, anti-cheat audit logs, reward issuance, burn records, and leaderboard behavior compound into a proprietary balancing and integrity dataset over time - Distribution moat: every additional game, mission, or partner campaign lands on top of an existing identity, wallet, competition, and reward surface rather than starting user acquisition from zero The edge is not one mechanic. Low-friction onboarding, replayable arcade loops, participant-funded competition, and verifiable settlement compound because each layer increases the usefulness of the others. --- ## 11. Security and Audit Posture Security credibility comes from a clear custody model, explicit controls, abuse resistance, and disciplined external-review planning rather than vague audit language. ### Core controls #### Spend controls Sensitive purchase and spend flows use a 4-digit transaction PIN with retry controls, blocking behavior, and short-lived proof cookies. #### Claim controls Reward claims use signed vouchers, expiry timestamps, and on-chain used-nonce protection to prevent duplicate redemption. #### Gameplay validation Checkpoint nonce chains, hash-linked session proofs, elapsed-time checks, score-window validation, and audit logs protect score-based systems. #### Airdrop integrity Airdrop flows include request-risk scoring, IP-hash clustering, account-count heuristics, and post-claim reconciliation. #### Response controls Store, rewards, and duel systems include pause controls so the platform can react quickly to anomalous behavior or settlement issues. ### Responsibility split - Client and game runtime: generates gameplay events, checkpoint summaries, elapsed time, and final score payloads - Backend orchestration: applies session validation, checks checkpoint integrity, prepares vouchers, verifies emitted chain events, updates leaderboards, and reconciles payouts - On-chain layer: finalizes payment, reward, escrow, burn, and payout-sensitive actions through Move modules and event-based verification ### Custody and signing model - Authorization model: user transactions are authorized with a client-side zkLogin signing context rather than a reusable private key distributed to the app or stored in backend business logic - Salt and address handling: authenticated backend routes call Shinami zkWallet services for wallet address and salt so wallet access keys are not exposed to the browser - Proof generation: authenticated backend routes request zkLogin proofs from Shinami zkProver, while final signature assembly and transaction submission remain tied to the client session - Session continuity: zkLogin session state is persisted locally for continuity and can be refreshed or cleared when stale rather than relying on a permanently open signing context - Treasury separation: reward voucher verifier keys are separate from treasury wallet control, and reward vault assets remain in on-chain objects until claim or payout ### Abuse resistance - Verified play sessions: direct score posting is disabled. Reward-sensitive progress must flow through a created play session with server-issued metadata - Checkpoint proof chain: each run submits sequence, elapsed time, score, best score, previous hash, and checkpoint hash. Regressions, broken chains, and invalid hashes are rejected - Finalize windows: server rules reject stale checkpoints, oversize finalize deltas, expired sessions, malformed replay contexts, and mode-inconsistent ticket usage before rewards can settle - Airdrop sybil controls: airdrop flows hash IPs, hash user agents, count accounts per IP cluster, and move accounts into clear, flagged, or banned states at defined thresholds - Claim abuse controls: reward claims require nonce-bound vouchers, expiry windows, pending-claim state checks, and emitted-event verification before off-chain state updates - Spend approval controls: 4-digit spend PIN verification uses hashed storage, response delays, failed-attempt blocking, and short-lived signed proof cookies for sensitive spend flows ### Additional deterministic filters Server rules reject negative scores, missing timestamps, expired sessions, invalid live-match replay contexts, and malformed Ticket usage before those events reach payout-sensitive paths. Game-specific duration ceilings add deterministic filtering instead of relying on moderation alone. Competitive sessions are also governed by game- and mode-specific checkpoint policies. High-trust modes use tighter checkpoint cadence, stale-proof rejection, bounded finalize deltas, minimum duration thresholds for base XP, and minimum checkpoint counts before a run can translate into leaderboard or reward-sensitive progress. ### External review posture External audit has not yet been commissioned at the current testnet stage. The present security posture emphasizes bounded contract scope, pause controls, verifier rotation, nonce protection, payout limits, and explicit treasury-linked settlement paths. Independent review remains a priority before broader capital exposure, larger-scale liquidity activation, or larger treasury deployment. Gexi uses zkLogin with server-side Shinami wallet and prover services for salt handling and proof generation, while client sessions retain the signing context used to assemble final transaction signatures. Wallet access keys stay off public browser routes without turning the product into a generic custodial app wallet. --- ## 12. Growth Strategy Gexi can scale through players, developers, and ecosystem campaigns at the same time. ### Growth vectors #### Player acquisition Embedded wallets reduce the barrier for first-time crypto users entering the platform. #### Retention Tickets, replay loops, competitions, missions, and progression create multiple return triggers. #### Developer expansion External studios can plug into an existing distribution, rewards, competition, and wallet layer instead of rebuilding these systems from scratch. #### Ecosystem distribution Partners can activate campaigns inside a gaming-native surface with measurable participation and reward completion. ### Strategic interpretation Once replay and competition retention are established, each additional game, mission, or partner campaign can enter a system that already has identity, wallets, rewards, and visible progression. --- ## 13. Metrics The public KPI layer will begin with testnet. Until then, the focus is on measuring the right behaviors rather than filling the document with placeholder vanity numbers. ### Tracked metrics - Onboarding metrics: wallet-backed signups, wallet activation rate, successful zkLogin onboarding completion, and first-session conversion - Gameplay metrics: total sessions, sessions per active user, replay rate, live match participation, duel count, and brawl participation - Economy metrics: Ticket sales, Ticket grants, GEXI spent in store, reward claims, prize payouts, and total GEXI burned - Retention metrics: day-1, day-7, and day-30 retention, weekly active cohorts, repeat payer rate, and competition re-entry behavior - Developer and ecosystem metrics: live games, incoming game submissions, partner campaign activations, mission completion rates, and external distribution throughput Testnet is the first public measurement window for onboarding quality, replay behavior, competition depth, store conversion, and reward integrity. As public testnet progresses, this section is intended to be updated with live operating metrics rather than speculative projections. The aim is to show measurable product behavior, not inflated claims. --- ## 14. Team The team is intentionally keeping a low public profile at this stage, while shipping a product stack that is already beyond MVP scope. ### Current positioning - Product and growth: the founding group spans consumer product design, gameplay loops, live operations, campaign systems, and growth-oriented product strategy - Technical systems: core contributors cover full-stack engineering, wallet integration, backend orchestration, data pipelines, anti-cheat controls, and smart-contract execution paths - Operating model: the team is entering market with a working product stack, shifting execution focus toward scale, polish, integrity, and distribution - Identity posture: contributors remain non-public for security and operational reasons; the product, code surface, and system design are the early trust anchors The strategy is product-first: a built platform, live economic flows, and a broader-than-MVP system surface should carry more weight than founder visibility at this stage. --- ## 15. Roadmap ### Phase I Strengthen the core gaming loop: wallet UX, Ticket balancing, store settlement, claims, live matches, duels, and brawls at scale. ### Phase II Expand the external developer layer with more titles, better activation tooling, and clearer performance-linked reward programs. ### Phase III Scale partner campaigns and ecosystem missions so Gexi becomes a repeatable user-acquisition and retention surface inside Sui. ### Phase IV Introduce deeper economy controls, retention-informed balancing, and more adaptive campaign intelligence across the network. --- ## 16. Legal & Compliance Gexi is being built with a compliance-aware operating model rather than assuming legal structure can be added after distribution begins. ### Current posture - Entity direction: the operating company is expected to be established in Turkey, with the legal structure intended to support product operations, partnerships, and treasury discipline as the network expands - Utility framing: GEXI is presented as a platform utility token used across store access, competition, rewards, campaigns, and broader network participation rather than as a passive yield instrument - Jurisdiction discipline: access conditions, campaign design, and token-enabled flows may be adjusted by region as the platform formalizes its operating footprint and distribution strategy - Verification readiness: enhanced verification, campaign gating, and distribution controls can be introduced where required for larger reward programs, partnerships, exchange processes, or jurisdiction-sensitive operations As the Turkish entity is formalized and token-enabled activity expands, region-specific controls and verification requirements may be strengthened where appropriate. --- ## 17. Key Risks The model must keep proving four things: supply absorption, retention, regulatory discipline, and settlement security. ### Supply absorption risk Early unlocks must be matched by real store demand, competition throughput, and burn activity. The mitigation is staged vesting, visible budgets, burn tracking, and disciplined market formation. ### Treasury-to-market leakage risk If treasury rewards dominate player-funded throughput, claims can become sell pressure. The mitigation is fixed prize budgets, store demand, participant-funded competition, and burn tracking. ### Retention risk Reward systems only remain durable if replay quality and competition depth stay high. The mitigation is catalog curation, session-quality thresholds, Ticket pacing, and live-ops balancing. ### Regulatory operating risk Jurisdiction requirements can evolve as token-enabled distribution expands. The mitigation is a compliance-aware operating model, Turkish entity formation, campaign gating, and verification readiness. ### Security and settlement risk As value throughput grows, the cost of failure rises. The mitigation is a narrow contract surface, pause controls, nonce protections, verifier management, bounded payout logic, and a staged external-review roadmap. ### Player behavior model | Player behavior | Likely incentive | Current mitigation | |---|---|---| | Casual player | Uses Tickets for access and replays, enters light competition, and may spend for convenience or progression continuity | Store spend and replay loops create recurring low-friction demand | | Skilled competitor | Locks GEXI into duels and brawls to win from other players rather than relying only on platform emissions | Competition throughput converts skill expression into peer-funded token movement | | Extractor behavior | Attempts to farm treasury-funded rewards with minimal engagement or low-quality sessions | Checkpoint proofs, duration thresholds, session-quality gating, and burn-aware competition reduce the system’s reliance on pure emission farming | --- ## Conclusion Gexi is building a consumer gaming network with measurable token throughput. The thesis is simple: reduce onboarding friction, make competition economically meaningful, and connect value-bearing moments to verifiable settlement. If execution stays disciplined, access spend, player-versus-player competition, and controlled treasury budgets can support a more durable token model than emission-heavy gaming systems. ## Disclaimer This document is informational and reflects the current product direction, implemented architecture, and declared token structure as of April 23, 2026. Features, allocation mechanics, partnership structures, rollout timing, and strategic priorities may evolve as the platform scales.