> For the complete documentation index, see [llms.txt](https://whitepaper.after-bell.uk/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://whitepaper.after-bell.uk/roadmap/phase-1-mvp.md). # Phase 1: MVP Defines the initial roadmap target for AFTERBELL’s minimum viable product. ### First product-validation phase Phase 1 is the MVP phase. It covers **Week 1–6** and has one primary objective: **prove the product works**. This is a roadmap target, not a statement of current performance. The phase is intended to validate the core AFTERBELL product loop before the roadmap seeks a larger market universe, more participation, or new product capabilities. ``` Market → Yes / No trading → CLOB matching → on-chain settlement → oracle verification → resolution → redemption ``` For AFTERBELL, proving the product works means demonstrating this complete flow as a product experience. It is not enough to create a market or show a trading interface in isolation. Participants must be able to interact with Yes and No markets, matched activity must reach the on-chain settlement path, and the market must be able to reach resolution and redemption. {% hint style="info" %} Phase 1 describes future roadmap targets. It does not report current markets, TVL, traders, or completed validation. {% endhint %} ### Phase targets | Metric | Phase 1 target | | -------- | -------------: | | Timeline | Week 1–6 | | Markets | 10 | | TVL | $100K | | Traders | 1,000 | The target of **10 markets** defines the initial market universe. It is a bounded starting point for operating the core market flow. The roadmap does not specify the composition of those markets beyond AFTERBELL’s prediction-market product for stock tokens. The **$100K TVL** target is the stated liquidity and capital target for the phase. It should not be interpreted as revenue, trading volume, or a guarantee of market depth. The source does not define average position sizes, retention, daily activity, or a volume target. The **1,000 traders** target defines the intended participation level for the MVP phase. It is not a claim about existing users, conversion, or user behavior. It establishes the scale at which the roadmap aims to test the initial product loop. Together, these targets frame Phase 1 as an initial operating environment: a limited market set, stated liquidity target, and stated participant target. They are not independent proof that the product has already succeeded. ### Product validation The MVP phase is designed to validate whether the existing architecture can operate as a coherent market product. A successful Phase 1 would demonstrate the intended capabilities, not declare them already proven: * The core market product can operate across its full lifecycle. * Users can interact with Yes and No market positions. * The trading architecture can support the initial market set. * Resolution and redemption can complete the product loop. The phrase “prove the product works” should be read in that context. It is a validation objective for the end-to-end system rather than a claim about a single component. An outcome token without a working resolution path would not validate the full product. Likewise, an off-chain match without on-chain settlement would not complete the stated flow. Phase 1 brings these components together around the initial 10-market target. ### Technical foundation Phase 1 uses the architecture already described for AFTERBELL. Robinhood Chain provides the EVM execution environment. Smart contracts provide the protocol layer. The CLOB handles off-chain matching, while `CTFExchange` handles CLOB settlement on-chain. ``` Robinhood Chain → smart contracts → CTFExchange → CLOB matching → Chainlink primary price → Robinhood API cross-check → ERC-1155 outcome tokens → redemption ``` The order of the diagram is architectural, not a detailed transaction sequence. The key Phase 1 requirement is that these existing pieces can support a real product flow. A user selects an outcome, signs trading intent, reaches the off-chain CLOB matching path, and settles through the on-chain protocol path using USDG and ERC-1155 outcome positions. At resolution, `OracleResolver` reads Chainlink and cross-checks Robinhood. A disagreement above 5% pauses the market for manual resolution using off-chain evidence. This is part of the architecture Phase 1 seeks to validate, not a future mechanism added by the roadmap. ### What success would demonstrate The stated definition of Phase 1 success is: ``` 10 markets + $100K TVL + 1,000 traders + working core product loop ``` Reaching these targets would demonstrate the intended first-stage product validation. It would show that the roadmap has pursued its initial market, capital, and participation targets while exercising the product’s trading-to-redemption loop. It would not, by itself, prove permanent liquidity, future revenue, audited security, or readiness for every later roadmap capability. Organic liquidity is not guaranteed, and revenue projections are not proven. The roadmap uses this phase to validate the core before attempting the larger targets in Phase 2. ### Current status and boundaries AFTERBELL is still under development. Phase 1 is a future roadmap phase, not a report of current adoption. Smart contracts are not yet audited, and an audit is planned before mainnet. This roadmap is documented in whitepaper **v0.1, September 2026**. AFTERBELL does not currently have a token. It is a product, not a token launch. ### Transition to Phase 2 Phase 1 focuses on proving the core product. If the roadmap’s MVP validation is achieved, the next phase shifts from initial validation to scaling the market, TVL, and trader targets. ``` Phase 1 — MVP → prove the core product Phase 2 — Scale → expand market, user, and liquidity targets; add programmatic trading Phase 3 — Compose → add options hedging, cross-chain markets, and structured products ``` Phase 2 is a roadmap objective, not a guaranteed outcome of Phase 1. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://whitepaper.after-bell.uk/roadmap/phase-1-mvp.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.