> 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/risks-and-limitations/product-market-risk.md). # Product-Market Risk Covers uncertainty about adoption and sustained demand for AFTERBELL markets. ### The core commercial risk The simplest product-market failure scenario is: **“Nobody trades.”** AFTERBELL can technically create a prediction market, match orders through its CLOB, settle through its contracts, and resolve outcome tokens while still failing commercially. Technical functionality is not the same as product-market fit. ``` Technical functionality ≠ Sustained user demand and trading activity ``` The product-market question is whether enough people consistently trade the markets to support liquidity, price discovery, and the product’s economics. ### Demand threshold The source identifies a specific internal product-market test: if volume stays below **$10K per market per day after 30 days**, the product is considered not to be working. This is not a guaranteed KPI or a universal market standard. It is the project’s stated test for evaluating whether AFTERBELL has sufficient demand. ``` After 30 days volume < $10K per market per day ↓ product is not working against the stated test ``` ### Why low volume matters Low trading volume affects fee generation, market usefulness, liquidity, price discovery, market-maker economics, and the ability to support many markets. AFTERBELL’s stated fees are a 0.5% trading fee and a 0.1% resolution fee. Revenue therefore depends on actual volume. If users do not trade, technical availability does not create the economics assumed by the model. ### Break-even model The source model is: ``` 10 markets × $10K daily volume per market = $100K daily volume ``` The projected net is **approximately $2,400 per day after costs**. This is a projection, not a promise. The source states: “These are projections, not promises.” If volume is lower, economics deteriorate. If volume is higher, economics improve. This does not create a new forecast or guarantee either outcome. ### New-market cold start New markets start empty. They need participants and actual orders. Because AFTERBELL uses a CLOB, liquidity does not automatically come from a permanent AMM pool. ``` New market → no organic liquidity yet → limited bids and asks → participation and execution challenge ``` The project plans to bootstrap liquidity with a market maker bot that places bids and asks. This provides initial order flow and can improve market accessibility, but it has an operating cost of about **$500 per market per week**. The source does not define the bot’s strategy, quote size, inventory, spread, or rebalancing mechanism. The bot does not guarantee sustained organic demand. ### Scale and economics More markets create more potential trading opportunities, but they also create more liquidity requirements and market-making costs. ``` More markets → more liquidity support required → more market-making cost ``` The $500 per market per week figure is a source estimate, not a fixed universal cost. It illustrates the tension between expanding market breadth and supporting the liquidity needed for markets to function. ### Possible responses If the product is not working against the stated low-volume test, the source identifies three possible responses: 1. Reduce the number of markets. 2. Increase subsidies. 3. Pivot. These are options, not assurances. The source does not specify how a market reduction, subsidy increase, or pivot would be implemented. ### TVL is not demand TVL is not the same as trading volume. Phase 1 targets $100K TVL, but this does not automatically mean $100K daily volume, active order flow, or sufficient counterparties. Capital may be present while active trading remains insufficient. For a CLOB, the immediate trading experience depends on available bids and asks at the relevant time. ### Product-market risk table | Risk | Signal | Potential impact | Source-identified response | | ------------------- | ----------------------------------------------- | --------------------------------------- | -------------------------------------------- | | Low trading demand | Less than $10K per market per day after 30 days | Product not working against stated test | Reduce markets, increase subsidies, or pivot | | Empty new markets | No organic liquidity at launch | Poor execution or weak participation | Market maker bootstrap | | High liquidity cost | About $500 per market per week estimate | Higher operating cost | Manage market count or subsidies | | Weak fee generation | Lower trading volume | Revenue below model | Adjust product strategy | All figures are source assumptions or estimates. They do not guarantee volume, participation, or revenue. ### What is not guaranteed No minimum trading volume, user count, or revenue level is guaranteed. Organic liquidity is not guaranteed. The break-even model is not proven. The roadmap’s TVL and trader targets are future targets, not current results. AFTERBELL is still being developed, and smart contracts are not yet audited. An audit is planned before mainnet. This is whitepaper **v0.1, September 2026**. AFTERBELL does not currently have a token. It is a product, not a token launch. ### Conclusion The most fundamental product-market risk is not whether AFTERBELL can technically create a prediction market. It is whether enough people will consistently trade those markets to support liquidity, price discovery, and the economics of the product. The source explicitly treats this as measurable risk and defines a $10K-per-market-per-day threshold after 30 days as a signal that the product is not working. --- # 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/risks-and-limitations/product-market-risk.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.