GEXI Whitepaper v1.0
A gaming network with built-in on-chain value.
Gexi combines wallet onboarding, arcade gameplay, social competition, rewards, and token settlement in one repeat-use product.
The current stack already includes zkLogin onboarding, on-chain store settlement, signed reward claims, duel escrow, brawl payouts, burn tracking, checkpoint validation, live prizes, weekly XP ladders, and airdrop controls.
Network
SuiSupply
100,000,000 GEXILive Games
6Model
Hybrid consumer gaming economyConsumer UX as infrastructure
Gexi begins with embedded wallet onboarding, low-friction identity, and repeatable gameplay loops designed for real user retention.
Separate play from value
Tickets absorb high-frequency game usage while GEXI remains focused on settlement, competition, incentives, and ecosystem demand.
Competition as the demand engine
Live matches, duels, brawls, weekly XP ladders, and missions create repeat reasons to hold, spend, and compete.
Verifiable economic flows
Store settlement, reward claims, escrow, payout logic, and burn accounting are tied to explicit on-chain verification paths.
01
Investment Thesis
Gexi is structured so product quality and token throughput reinforce each other.
Crypto gaming will not be won by forcing every interaction on-chain. It will be won by reducing onboarding friction, increasing play frequency, and routing high-trust economic actions through verifiable settlement.
The platform uses a fast product layer for sessions, missions, social engagement, and competition, 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.
Lower onboarding friction and stronger repeat competition can make distribution, retention, and token demand reinforce each other instead of operating as separate layers.
02
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.
| Timing driver | Why it matters |
|---|---|
| 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. |
03
Product Scope
The current implementation is already broader than a simple game launcher or token reward tab.
Gexi already operates as a multi-surface gaming product rather than a single utility screen. The user journey spans onboarding, wallet activity, Ticket acquisition, gameplay, reward claiming, competition, and social engagement in one account system.
Game catalog
Sweet Fruits, Teeter Towers, Hoploop, Twist, Village Defense, and Boing are the current live arcade titles.
Core surfaces
Wallet, games, rewards, store, social, notifications, and competition all sit inside the same product account.
Competition formats
Standard sessions, live matches, duels, brawls, and weekly XP seasons reuse the same identity and progression layer.
Reward system
Tasks can currently pay in Tickets, SUI, or GEXI depending on mission type and settlement path.
Growth system
Airdrop points, social missions, referrals, and leaderboard loops extend engagement beyond gameplay alone.
04
Architecture
Gexi is intentionally hybrid: fast product interactions stay server-orchestrated, while economic finality is routed through explicit Sui transactions.
| Layer | Implementation |
|---|---|
| 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. |
| Flow | Execution path |
|---|---|
| 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. |
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.
05
Implemented Systems
This is not a concept-only stack. Core economic and gameplay systems are already expressed in code, contracts, and scheduled operations.
| System | 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 default 1,000 GEXI prize pool configuration with rank-weighted bracket logic. |
| Weekly XP league | Weekly XP seasons also currently use a default 1,000 GEXI prize pool configuration with bracket-based reward allocation. |
| Session integrity | Gameplay sessions record checkpoint nonce chains, checkpoint hashes, score windows, and anti-cheat audit data before final reward logic is accepted. |
06
GEXI Utility
GEXI sits at the value layer of the platform: access spend, player-funded competition, reward settlement, and campaign distribution.
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.
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.
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 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 | 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. |
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.
07
Economy Model
The core economy is already parameterized in code rather than left to a vague reward narrative.
Ticket entry pricing
The current pack ladder is deterministic: 1 / 5 / 10 / 50 / 100 / 500 Tickets cost 2 / 10 / 20 / 100 / 200 / 1000 GEXI.
Reward pacing
Standard sessions currently 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, which creates a measured gameplay rebate loop without turning Tickets back into redeemable 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.
Gexi already has a visible pricing ladder, explicit competitive budgets, hardcoded XP rules, minimum and maximum duel stakes, and burn-aware payout logic. That means the economy can be analyzed as a parameterized system rather than a black-box promise.
| 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.
08
Ticket Layer
Tickets are the high-frequency access layer that makes the gameplay economy operationally cleaner.
Purpose
Tickets are the internal gameplay access unit used for entries, replays, and repeat sessions across supported formats.
Current pack ladder
1 / 5 / 10 / 50 / 100 / 500 Tickets are currently priced at 2 / 10 / 20 / 100 / 200 / 1000 GEXI.
Acquisition
Tickets are credited after verified store settlement and can also be distributed in selected campaign or airdrop flows.
Economic role
They preserve cleaner accounting by separating high-frequency play consumption from the base token.
Redemption rule
Tickets are not redeemable back into GEXI.
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.
09
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 | 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 |
Game Economy
Player rewards, gameplay incentives, platform activity
Presale
Early backers; unsold allocation intended to be burned
Staking + Liquidity + MM + LP
Liquidity depth and launch support
Treasury / Strategic Reserve
Strategic reserve and expansion flexibility
Team
Long-term alignment
Marketing
Launch and growth campaigns
Ecosystem + Developer + Partnerships
Developer onboarding and partner incentives
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.
| 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. |
| 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 |
| Balance layer | Current logic |
|---|---|
| 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.
| Category | Why Gexi can win |
|---|---|
| Emission-first GameFi | Many GameFi 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 layer | Why it compounds |
|---|---|
| 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.
| Control area | Implementation |
|---|---|
| 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. |
| Layer | Role |
|---|---|
| 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 layer | Current 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 control | Current implementation |
|---|---|
| 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. |
Checkpoint nonces, hash-linked proof chains, elapsed-time windows, score validation, and audit logs make score-based rewards harder to manipulate as usage grows.
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 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.
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.
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.
| Metric group | 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.
| Area | 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
The roadmap is framed around scaling proven product loops rather than adding disconnected features.
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.
| Area | 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.
| Risk | Mitigation |
|---|---|
| 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 | 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.
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.