> 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/revenue-distribution.md). # Revenue Distribution Explains the stated 70/20/10 allocation of protocol fees. ### Allocation AFTERBELL allocates collected protocol fees across three named destinations: | Destination | Share | Economic role | | ---------------------- | ----: | ----------------------- | | Treasury | 70% | Protocol treasury | | Market Maker Subsidies | 20% | Liquidity bootstrapping | | Keeper Bot | 10% | Keeper operations | These percentages total 100% of the protocol fee pool. They are the source-defined allocation. They do not describe additional revenue streams or independent charges. {% hint style="info" %} **Source fact:** protocol fees are allocated 70% to the treasury, 20% to market-maker subsidies, and 10% to the keeper bot. {% endhint %} ### Fee flow Both stated fee types feed the protocol’s fee pool: ``` Trading fees + resolution fees ↓ Protocol fee pool ↓ 70% Treasury | 20% Market Maker Subsidies | 10% Keeper Bot ``` The source identifies a 0.5% trading fee and a 0.1% resolution fee. It does not state when distributions occur, how balances are held, or how allocations are operationally transferred. This page describes the allocation model, not unprovided implementation mechanics. ### Worked allocation If the protocol collects $1,000 in fees, the stated percentages produce: | Destination | Calculation | Illustrative amount | | ---------------------- | -----------: | ------------------: | | Treasury | $1,000 × 70% | $700 | | Market Maker Subsidies | $1,000 × 20% | $200 | | Keeper Bot | $1,000 × 10% | $100 | ``` $1,000 total protocol fees = $700 treasury + $200 market-maker subsidies + $100 keeper bot ``` This is direct arithmetic, not a claim that $1,000 has been collected. The same ratio applies to any fee-pool size. For example, a $500 fee pool would allocate $350, $100, and $50 respectively. ### Treasury allocation The treasury receives 70% of protocol fees under the stated model. This is the largest named allocation and represents retained protocol economics. The source does not define spending categories for the treasury. It would be inappropriate to infer grants, buybacks, governance spending, token programs, or other uses. The economically supported statement is limited: 70% of collected protocol fees is allocated to the treasury. ### Market-maker subsidies Twenty percent of protocol fees is allocated to market-maker subsidies. This connects fee collection to liquidity bootstrapping. New CLOB markets may begin without enough organic bids and asks. AFTERBELL plans to use a market-maker bot that places bids and asks to provide initial liquidity. The source estimates approximately $500 per market per week for this support. The allocation is intended to support that liquidity function. It does not guarantee order-book depth, practical execution, spreads, or organic participation. The source does not define a market-maker contract, payment schedule, quote strategy, or an amount paid to any market in a given period. ### Keeper-bot allocation Ten percent of protocol fees is allocated to the keeper bot. This identifies keeper operations as a named economic destination within the model. The source does not enumerate keeper tasks or a keeper cost schedule. It should not be read as a claim that 10% covers all operating costs. It also does not establish payments on a specific cadence. The supported conclusion is that the model reserves 10% of protocol fees for the keeper bot. ### Intended economic loop The distribution connects market use to the protocol’s stated operational components: ``` Trading activity ↓ Protocol fees ↓ Market-maker subsidies ↓ Initial order availability ↓ More usable markets ↓ Potential trading activity ``` This is an intended mechanism, not a proven growth loop. More usable markets may support more activity, but neither organic liquidity nor trading volume is guaranteed. Fee revenue remains volume-dependent. The treasury and keeper allocations sit alongside this loop. They show that the fee pool is not devoted solely to liquidity. The model divides protocol fees across retained treasury economics, liquidity bootstrapping, and keeper operations. ### Relationship to fee revenue Trading volume is not protocol revenue. At a 0.5% trading fee, $100,000 in daily volume produces $500 of gross daily trading-fee revenue: ``` $100,000 × 0.5% = $500 ``` If $500 were the entire fee pool for an illustration, its allocation would be $350 to the treasury, $100 to market-maker subsidies, and $50 to the keeper bot. This does not include any resolution-fee revenue. The source does not define the resolution-fee base needed to calculate that amount from trading volume. Allocation is also not net revenue. Net economics require the relationship between gross fees and operating costs. The source supplies a projected net figure in its break-even model, but it does not disclose every intermediate assumption required to independently reconcile that figure. ### Limitations and status The percentages are source facts. The calculations are model arithmetic. Neither proves realized performance. AFTERBELL is still under development. Smart contracts are not yet audited, and an audit is planned before mainnet. Liquidity support has costs. Organic liquidity is not guaranteed. Trading volume and resolution activity are uncertain, while regulatory uncertainty remains. AFTERBELL does not currently have a token. This allocation is protocol-fee distribution, not tokenomics, yield, or a promise of income. --- # 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/revenue-distribution.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.