> For the complete documentation index, see [llms.txt](https://docs.tapzi.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tapzi.io/roadmap.md). # Roadmap — Milestone-Based Expansion
Tapzi's roadmap is evolving from a **calendar-first model** into a **milestone-driven execution framework**. The original Tapzi roadmap was designed around the project's initial phase as a first-party skill-based gaming platform. Whitepaper 3.0 expands that strategy. Tapzi is now being developed as a broader infrastructure network connecting: * players; * competitive games; * developers; * creators; * tournament operators; * future commercial participants. This requires a different roadmap philosophy. > **A new phase should begin because the previous phase produced sufficient evidence, not simply because a calendar date arrived.** The Plan 3 roadmap therefore follows: > **Prove → Platformize → Scale → Expand** *** ### 1. Roadmap Philosophy Each phase is designed to reduce a different category of risk. **Phase I** Prove that the first-party competitive network works. **Phase II** Prove that external developers can use the infrastructure. **Phase III** Prove that content supply can scale beyond professional studios. **Phase IV** Prove that additional distribution channels improve network growth. **Phase V** Evaluate adjacent transaction infrastructure. **Phase VI** Build deeper settlement infrastructure only if actual scale requires it. **Phase VII** Explore emerging economies without making them dependencies of the core business. Later phases are therefore increasingly conditional. They are strategic directions rather than unconditional promises. *** ### 2. Status Framework Every roadmap capability should use Tapzi's public status framework. | Status | Meaning | | --------------------- | ---------------------------------------------- | | 🟢 **LIVE** | In production and publicly usable | | 🔵 **BETA** | Publicly testable but still evolving | | 🟡 **IN DEVELOPMENT** | Active implementation underway | | ⚪ **DESIGNED** | Technical or product specification exists | | 🟣 **RESEARCH** | Strategic option without a delivery commitment | The **Current Product Status** page should remain the authoritative source for the latest status of individual features. The roadmap describes strategic sequencing. The Product Status page describes what exists today. *** ### 3. Phase I: PROVE #### Competitive Network & Trust Foundation **Objective** Prove that Tapzi's core competitive infrastructure can operate reliably with real users. The focus of this phase is not ecosystem breadth. It is evidence. *** #### Core Product **Tapzi Skill Arena** Continue developing and validating the first-party competitive environment. Supported and compatible formats can include: * Chess; * Checkers; * Tic-Tac-Toe; * additional suitable strategy titles. The objective is to establish a stable environment in which Tapzi's infrastructure can be tested under real operating conditions. *** #### Competitive Infrastructure Key systems include: * player authentication; * matchmaking; * competitive ratings; * authoritative game state; * match recovery; * replay infrastructure; * result authentication; * settlement; * tournament functionality; * anti-cheat; * dispute handling. *** #### Trust Infrastructure Phase I also strengthens the evidence around the project. This includes: * current product-status disclosure; * development history; * contract transparency; * audit references; * canonical tokenomics; * canonical vesting information; * security documentation; * Proof Center development. *** #### Phase I Success Metrics Progress should increasingly be evaluated using metrics such as: **Product** * registered users; * active players; * completed matches; * match completion rate. **Engagement** * D7 retention; * D30 retention; * repeat participation. **Infrastructure** * matchmaking latency; * settlement success; * service uptime; * reconnect success. **Integrity** * cheat flags; * confirmed violations; * dispute frequency; * dispute resolution. **Economics** Where applicable: * competition volume; * service revenue; * revenue per active participant. Not every metric must be publicly disclosed immediately. Metrics that are published should reflect measured activity. *** #### Phase I Exit Principle Phase I should be considered sufficiently proven when the network demonstrates consistent operating reliability and enough real-user activity to justify exposing selected infrastructure to external developers. The transition should be evidence-driven. *** ### 4. Phase II: PLATFORMIZE #### Tapzi Studio & Developer Infrastructure **Objective** Convert infrastructure developed for Tapzi's own games into reusable services for third-party developers. This is the stage where Tapzi begins evolving from: > **operator of competitive games** into: > **provider of competitive gaming infrastructure.** *** #### Tapzi Studio Planned capabilities may include: * player identity; * matchmaking; * ratings; * tournament systems; * match sessions; * settlement integrations; * replay APIs; * competitive-integrity services; * reputation; * analytics; * webhooks. *** #### Developer Experience Phase II should progressively introduce: **Documentation** Clear technical integration documentation. **Sandbox** A safe environment for developers to test integrations. **APIs** Production-ready interfaces for supported services. **SDKs** Engine-specific integrations where demand and technical readiness justify them. Potential engine support may include: * Unity; * Unreal Engine; * Godot; * Web/HTML5. Engine support should only be marked LIVE when the corresponding production implementation exists. *** #### Tournament Cloud Tournament infrastructure can begin evolving into a reusable product for developers, communities, and organizers. Potential functionality includes: * brackets; * leagues; * ladders; * seasons; * qualification systems; * community tournaments; * sponsored competitions. *** #### Developer Analytics Tapzi Studio may progressively expose analytics such as: * match activity; * retention; * competition participation; * player skill distribution; * tournament engagement; * infrastructure performance. *** #### Phase II Success Metrics Relevant evidence may include: * external developer registrations; * sandbox activity; * completed integrations; * production integrations; * matches generated through third-party titles; * active developers; * developer retention; * infrastructure usage. A publicly released SDK by itself should not be considered proof of developer adoption. *** #### Phase II Exit Principle The network should demonstrate that external developers can successfully integrate and operate Tapzi-powered competitive experiences before creator tooling becomes a major scaling priority. *** ### 5. Phase III: SCALE SUPPLY #### Tapzi GameBuilder & Creator Ecosystem **Objective** Expand the supply of competitive experiences beyond Tapzi's internal team and professional game studios. Tapzi GameBuilder is intended to reduce the technical barrier to creating lightweight competitive games. *** #### Creator Studio Potential capabilities include: **Assisted Creation** * natural-language assistance; * rules configuration; * game templates; * logic scaffolding. **Visual Creation** * UI templates; * reusable components; * asset libraries. **Competition Infrastructure** Compatible experiences may inherit: * identity; * matchmaking; * ratings; * tournaments; * analytics; * eligible settlement services. **Distribution** Creators may eventually distribute compatible experiences through supported Tapzi surfaces. *** #### Creator Analytics Potential analytics include: * plays; * active players; * retention; * competition participation; * tournament performance; * creator engagement. *** #### Creator Economy Any creator monetization model should be disclosed before production activation. Whitepaper 3.0 does not establish a fixed creator revenue percentage. Potential creator economics should be evaluated based on: * sustainability; * product usage; * developer economics; * network economics; * applicable legal requirements. *** #### Phase III Success Metrics Potential indicators include: * active creators; * games created; * games published; * player activity in creator games; * creator-game retention; * percentage of network activity generated outside first-party titles. *** #### Phase III Exit Principle Creator supply should demonstrate meaningful player usage before Tapzi treats GameBuilder as a proven network-growth engine. *** ### 6. Phase IV: EXPAND DISTRIBUTION #### More Entry Points Into the Same Network **Objective** Increase user acquisition without fragmenting Tapzi into separate ecosystems. The principle is: > **More surfaces, shared infrastructure.** *** #### Potential Distribution Channels **Web** Tapzi's primary browser-based environment. **Mobile** Mobile-optimized and future supported mobile experiences. **Third-Party Games** Games integrated through Tapzi Studio. **Creator Experiences** Games developed through future GameBuilder infrastructure. **Partner Portals** Strategic distribution through compatible partners. **Social / Mini-App Environments** Eligible platforms capable of supporting Tapzi experiences. *** ### 7. Telegram Mini-App Telegram represents a potential social-distribution channel rather than a separate Tapzi business. Potential functionality may include: * lightweight strategy games; * social challenges; * player acquisition; * community competitions; * account onboarding. Any value-based competition functionality remains dependent on: * Telegram policy; * jurisdiction; * eligibility; * technical implementation; * applicable payment rules. Telegram should therefore follow its actual public status rather than being treated as a guaranteed launch channel. *** #### Phase IV Success Metrics Distribution channels should be evaluated through metrics such as: * acquisition; * activation; * retention; * completed matches; * cost per acquired participant; * conversion into broader network usage. Tapzi should not measure distribution success simply by the number of platforms on which a product appears. *** ### 8. Phase V: EXPAND ECONOMICS #### Tapzi Pay Pilot **Objective** Evaluate whether selected transaction and settlement capabilities developed within the Tapzi ecosystem can support broader digital commerce. Tapzi Pay remains an **adjacent commercial expansion**. It is not required for the Competition Protocol or Skill Arena to succeed. *** #### Initial Areas of Exploration Potential capabilities include: * non-custodial settlement; * stablecoin checkout; * merchant APIs; * webhooks; * compatible e-commerce integrations; * QR-based payment experiences; * account abstraction; * sponsored transactions; * third-party fiat on-ramp integrations. Exact production functionality should follow actual implementation status. *** #### Pilot-First Strategy Tapzi Pay should begin through controlled pilots rather than broad claims of global merchant infrastructure. Pilot objectives include validating: * merchant demand; * transaction reliability; * checkout conversion; * settlement performance; * support requirements; * security; * compliance processes; * unit economics. *** #### Merchant Token Utility Future merchant use of $TAPZI may be evaluated where it creates practical benefits such as access to defined service tiers. Whitepaper 3.0 does not establish fixed: * merchant staking requirements; * fee tiers; * lock periods; * processing discounts. These should be disclosed only when the commercial model is approved and ready for implementation. *** #### Phase V Success Metrics Potential metrics include: * pilot merchants; * active merchants; * transaction count; * payment volume; * settlement success; * merchant retention; * transaction cost; * support incidents. Tapzi Pay should advance based on demonstrated commercial demand. *** ### 9. Phase VI: OWN INFRASTRUCTURE #### Dedicated Settlement Infrastructure **Status: 🟣 RESEARCH / CONDITIONAL** **Objective** Evaluate whether Tapzi's usage has grown sufficiently to justify deeper ownership of the settlement layer. Tapzi does **not** require a dedicated blockchain, Layer-3, or application-specific rollup to validate the core business. Existing blockchain infrastructure should be used while it remains economically and technically appropriate. *** #### Potential Trigger Conditions Dedicated settlement infrastructure should only be considered if measurable usage creates recurring limitations involving: **Throughput** Existing networks cannot economically support required transaction volume. **Cost** Settlement costs materially harm network economics. **Latency** Confirmation characteristics create a meaningful user or operational problem. **Cross-Game Settlement** A larger ecosystem introduces settlement complexity that dedicated infrastructure can materially reduce. **Interoperability** The network requires infrastructure that cannot reasonably be achieved through the existing architecture. *** #### Decision Principle > **Tapzi does not build a blockchain because having a blockchain sounds valuable.** A dedicated settlement network should solve a demonstrated infrastructure problem. Until then, it remains optional. *** ### 10. Phase VII: EMERGING ECONOMIES #### AI Agent Infrastructure **Status: 🟣 RESEARCH** **Objective** Explore potential future economic and competitive interactions involving autonomous software agents. Possible research areas include: * Agent-vs-Agent competitions; * Human-vs-Agent formats; * model benchmarking; * autonomous tournament participants; * programmatic service purchasing; * machine-to-machine payments. These concepts represent long-term optionality. They are not required for Tapzi's current network strategy. *** ### 11. Phase Dependencies The roadmap can be understood as a dependency chain: ``` PHASE I: PROVE Competitive Network │ ▼ PHASE II: PLATFORMIZE Developer Infrastructure │ ▼ PHASE III: SCALE SUPPLY Creators & GameBuilder │ ▼ PHASE IV: EXPAND DISTRIBUTION More Network Entry Points │ ▼ PHASE V: EXPAND ECONOMICS Tapzi Pay Pilot │ ▼ PHASE VI: OWN INFRASTRUCTURE Only If Scale Requires It │ ▼ PHASE VII: EMERGING ECONOMIES Long-Term Research ``` The arrows indicate strategic progression. They do not mean that all work must happen in perfectly isolated sequential blocks. Some research and development can overlap. However, later-stage investment should increasingly be justified by evidence from earlier stages. *** ### 12. What the Roadmap Does Not Mean The Plan 3 roadmap should not be interpreted as: * a guaranteed delivery schedule; * a guarantee that every research concept will launch; * a promise of token appreciation; * a guarantee of exchange listings; * a commitment to build a dedicated blockchain; * a commitment to launch Tapzi Pay in every jurisdiction; * a commitment to introduce AI-agent infrastructure. Strategic priorities can change based on: * user evidence; * technical findings; * security requirements; * market demand; * regulation; * capital efficiency. Material changes should be disclosed rather than silently rewritten. *** ### 13. Historical Roadmap Tapzi's original roadmap should remain publicly accessible as a [Historical Roadmap — 2025–2026](/development-history/historical-roadmap-2025-2026.md). It represents the strategy and expectations published during Tapzi's earlier development phase. Whitepaper 3.0 does not erase that history. Instead, it documents the project's evolution from: **Tapzi v1** First-party skill-based gaming platform. to: **Tapzi Whitepaper 3.0** Competitive digital skill economy infrastructure. Historical commitments should remain inspectable so that users and stakeholders can compare previous objectives with actual execution. *** ### 14. Proof-of-Execution Roadmap progress should increasingly be demonstrated through evidence. Examples include: **Product Evidence** Live product functionality. **Usage Evidence** Real network activity. **Technical Evidence** Production systems and releases. **Developer Evidence** Verified integrations. **Creator Evidence** Published and used creator experiences. **Commercial Evidence** Actual pilots and customers. **Security Evidence** Audits, testing, and incident reporting. **Token Evidence** Canonical supply, allocation, and vesting information. *** ### 15. Quarterly Execution Reporting Tapzi intends to progressively publish **Proof-of-Execution** updates covering: **What was planned** What the team intended to accomplish. **What was delivered** What actually became available. **What changed** Changes to scope or sequence. **Why it changed** Technical, commercial, security, regulatory, or resource reasons. **Evidence** Links to relevant: * products; * releases; * metrics; * contracts; * reports. **Next Milestone** The next major execution objective. This creates a historical record that can be reviewed over time. *** ### 16. Roadmap Success Is Not Feature Count Tapzi does not define successful execution as: > **the largest number of shipped features.** The objective is to progressively produce: * reliable products; * active users; * recurring usage; * stronger infrastructure; * developer adoption; * content supply; * sustainable revenue; * demonstrable network effects. A smaller number of widely used capabilities creates more value than a larger number of unused products. *** ### 17. Capital Discipline The milestone roadmap also supports capital discipline. Before committing substantial resources to a new vertical, Tapzi should be able to answer: **What problem does this solve?** **What evidence suggests users need it?** **Can existing infrastructure solve the problem first?** **What new operating complexity does it introduce?** **What security requirements does it add?** **What regulatory obligations may apply?** **How will success be measured?** This framework is particularly important for: * GameBuilder; * Tapzi Pay; * dedicated settlement infrastructure; * autonomous-agent infrastructure. *** ### 18. Tokenomics Remain Independent The Plan 3 roadmap does **not** alter Tapzi's existing tokenomics. Moving from one roadmap phase to another does not: * increase total supply; * create new allocation categories; * alter existing allocation percentages; * change TGE unlocks; * change cliffs; * change vesting periods. The canonical: [Token Allocation Breakdown](/tokenomics/token-allocation-breakdown.md) and [Vesting Schedule Overview](/tokenomics/vesting-schedule-overview.md) remain unchanged. A new product phase does not mean new token issuance. *** ### 19. The Plan 3 Execution Model The roadmap can ultimately be summarized in four words: ### PROVE Show that the network works. ↓ ### PLATFORMIZE Make proven infrastructure reusable. ↓ ### SCALE Allow more participants to build on the network. ↓ ### EXPAND Enter new markets only where evidence justifies it. This sequencing gives Tapzi substantial long-term optionality without making every future opportunity a current commitment. *** > **Build what the network needs. Prove that it works. Scale what users adopt. Expand when evidence justifies it.**