> 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/economics/break-even-model.md). # Break-Even Model Interprets the source’s projected volume, cost, and net-economics model. ### Headline model The source provides the following **modelled projection**: ``` Approximately $100,000 daily trading volume across 10 markets Projected net: approximately $2,400 per day after costs ``` This is not historical performance. It is not current revenue. It is not a guarantee. It is a future-oriented model statement. {% hint style="warning" %} The source provides a projected net figure but does not expose every intermediate revenue and cost assumption needed to independently reproduce it. {% endhint %} ### What break-even means here Break-even describes the point where modeled revenue and modeled operating costs cover each other or produce a positive modeled net. It does **not** mean the protocol makes $100,000 per day. That number is modeled daily trading volume. Trading volume is the amount traded. Fee revenue is the percentage collected from applicable activity. Net revenue is what remains after operating costs and the model’s other components. These concepts must remain separate. ### Known model components #### Trading volume The model uses approximately $100,000 of daily trading volume across ten markets. A simple average implies: ``` $100,000 ÷ 10 markets = approximately $10,000 daily volume per market ``` This is mathematical interpretation, not a per-market target or forecast. Actual market activity may be uneven. The source does not say each market will trade the same amount. #### Trading fee The stated trading fee is 0.5%. Applied to the model’s daily volume: ``` $100,000 × 0.5% = $500 daily gross trading-fee revenue ``` This is gross trading-fee revenue only. It is not total protocol revenue and it is not net revenue after costs. #### Resolution fee The source also specifies a 0.1% resolution fee. It does not provide enough information to identify the daily applicable resolution-fee base. The entire $100,000 of daily trading volume must not be assumed to be subject to this fee. Resolution-fee revenue can only be calculated when the applicable resolution amount is known. The source does not supply that amount for the break-even model. #### Liquidity subsidy estimate The source estimates approximately $500 per market per week for liquidity bootstrapping. At ten markets: ``` 10 × $500 = $5,000 per week $5,000 ÷ 7 = approximately $714.29 per day ``` This is direct arithmetic from the estimate. It is not a complete daily operating budget. It also does not establish that all ten markets incur that cost continuously. #### Fee distribution The protocol fee pool is allocated as follows: | Destination | Share | | ---------------------- | ----: | | Treasury | 70% | | Market Maker Subsidies | 20% | | Keeper Bot | 10% | This allocation explains how collected protocol fees are intended to support treasury economics, liquidity bootstrapping, and keeper operations. It does not itself calculate total costs or net revenue. ### Model transparency The provided source states approximately $100,000 daily trading volume, a 0.5% trading fee, a 0.1% resolution fee, an estimated $500 per market per week liquidity cost, and a projected net of approximately $2,400 per day. Those inputs do not expose every intermediate assumption required to reconstruct the exact projected net independently. In particular, the source does not provide the resolution-fee base, every operating cost, or the full model treatment of those values. The known arithmetic should not be forced to balance. The $500 gross daily trading-fee calculation and the $714.29 average daily ten-market subsidy calculation are useful interpretations of source numbers. They are not sufficient to validate, correct, or replace the stated projected net. This is a transparency boundary, not an invitation to invent assumptions. No additional revenue stream, cost category, or fee application should be inferred from the gap. ### Trading-fee sensitivity The following scenarios use only the stated 0.5% rate. They show gross trading-fee revenue. They are mathematical scenarios, not forecasts or profit estimates. | Daily trading volume | Calculation | Gross daily trading-fee revenue | | -------------------: | --------------: | ------------------------------: | | $10,000 | $10,000 × 0.5% | $50 | | $50,000 | $50,000 × 0.5% | $250 | | $100,000 | $100,000 × 0.5% | $500 | | $250,000 | $250,000 × 0.5% | $1,250 | Higher volume produces higher gross trading-fee revenue at a fixed rate. Lower volume produces lower gross trading-fee revenue. These results do not show net revenue because the complete cost and resolution-fee assumptions are not disclosed. ### Market count and liquidity costs Market count is a separate economic dependency. More markets can mean more liquidity subsidy requirements under the stated per-market estimate. Fewer markets can imply lower requirements. The relationship is illustrative: | Markets | Weekly arithmetic | Average daily equivalent | | ------: | -----------------: | -----------------------: | | 1 | 1 × $500 = $500 | approximately $71.43 | | 5 | 5 × $500 = $2,500 | approximately $357.14 | | 10 | 10 × $500 = $5,000 | approximately $714.29 | These are direct interpretations of the $500-per-market weekly estimate. They are not a universal cost model. The source does not state how costs change with activity, market design, or time. ### Economic dependencies The model links several named dependencies: ``` Trading volume → trading-fee revenue Resolution activity → resolution-fee component Market count → potential liquidity subsidy requirements Liquidity → market tradability Protocol fee pool → treasury, market-maker subsidies, keeper operations ``` The dependency chain does not guarantee an outcome. Liquidity can make markets more usable, but organic liquidity is not guaranteed. Usable markets may support activity, but volume remains uncertain. Fee revenue depends on that activity. ### Projection versus realized performance The model has four distinct categories: * **Source facts:** 0.5% trading fee, 0.1% resolution fee, 70/20/10 allocation, and approximately $500 per market per week. * **Model arithmetic:** calculations directly derived from those numbers. * **Projection:** approximately $100,000 daily volume across ten markets and approximately $2,400 daily net after costs. * **Realized performance:** observed activity, revenue, and costs. The provided material supplies no evidence that the projected revenue or net figure has been realized. It should not be represented as achieved protocol performance. ### Limitations The projection is unproven. Trading volume is uncertain. Organic liquidity is not guaranteed. Market-maker subsidies create operating costs, and the source does not expose every projected-net assumption. AFTERBELL is still under development. Smart contracts are not yet audited, and an audit is planned before mainnet. Regulatory uncertainty remains. Roadmap targets are future targets. AFTERBELL does not currently have a token and is a product, not a token launch. The break-even model is therefore best read as a transparent planning framework. It shows the stated direction of protocol economics while preserving the boundary between calculation, projection, and realized results. --- # 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/economics/break-even-model.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.