> 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/liquidity-subsidies.md). # Liquidity Subsidies Explains the estimated cost and economic role of liquidity bootstrapping. ### Why liquidity needs support New AFTERBELL markets may start with limited or zero organic orders. This is a central economic constraint for a central limit order book, or CLOB. A CLOB requires actual bids, asks, and counterparties. Without sufficient orders, users may have fewer available counterparties. Trading can become less practical. Liquidity can also vary materially from one market to another. The source does not guarantee organic liquidity. It therefore recognizes an economic cost to making new markets usable. ### Intended approach AFTERBELL plans to bootstrap liquidity with a market-maker bot: ``` Market-maker bot → places bids and asks → provides initial liquidity → helps bootstrap a new market ``` The stated function is initial order availability. The source does not specify the bot’s strategy, quote sizes, spread targets, inventory management, hedging, or minimum depth. It also does not promise that users will always be able to trade at a particular price. {% hint style="info" %} Liquidity bootstrapping is planned support, not guaranteed liquidity. Order availability can differ across markets and over time. {% endhint %} ### Stated cost estimate The source estimates approximately **$500 per market per week** for market-maker support. This is an estimate for the stated liquidity-bootstrapping function. The figure can be scaled as direct arithmetic. For ten markets: ``` 10 markets × $500 per market per week = $5,000 per week $5,000 ÷ 7 days ≈ $714.29 per day ``` This is a mathematical interpretation of the source estimate. It is not an independently verified budget. It is not the protocol’s complete daily cost structure. The source does not establish that every market costs exactly $500 each week or that this cost remains constant as conditions change. ### Relationship to protocol fees The revenue-distribution model assigns 20% of protocol fees to market-maker subsidies: ``` Protocol fee pool → 20% → market-maker subsidies → liquidity bootstrapping ``` This allocation makes liquidity support an explicit part of protocol economics. Trading and resolution fees are collected into a fee pool, then 20% is intended for the market-maker-subsidy destination. The source does not specify the payment mechanics. It does not state how funds are assigned among markets, when they are paid, whether unused funds carry over, or whether the bot receives a fixed amount. The 20% allocation and the $500 weekly estimate should not be treated as a fully specified subsidy schedule. ### Scaling implication Market count affects the stated liquidity estimate. More markets can imply more liquidity-subsidy requirements: | Illustrative market count | Weekly arithmetic at $500 per market | | ------------------------: | -----------------------------------: | | 1 | $500 | | 5 | $2,500 | | 10 | $5,000 | These figures apply the source’s estimate mechanically. They are not forecasts. They do not show total operating costs, actual bot expenditures, or a commitment to launch any specific number of markets. The break-even model uses ten markets as context. At that count, the source estimate implies approximately $5,000 per week, or $714.29 per day on an averaged basis. This illustrates why market count is an important economic dependency. It does not establish that subsidy cost alone determines profitability. ### Liquidity and trading activity Liquidity and activity are related but not identical. Liquidity describes available orders and counterparties. Trading activity describes executed volume. A market-maker bot can help make initial bids and asks available, but the source does not claim it creates organic demand. The intended relationship is: ``` Liquidity support → initial order availability → more usable market → potential trading activity → potential protocol fees ``` This mechanism may help a new market become usable. It does not guarantee volume, market adoption, or positive net economics. Lower trading activity produces lower trading-fee revenue at the fixed 0.5% rate, while liquidity support remains an estimated operating cost. ### Economic boundaries The liquidity estimate should not be confused with fee revenue. At $100,000 daily trading volume, the stated 0.5% trading fee produces $500 in gross trading-fee revenue. At ten markets, the weekly support estimate averages approximately $714.29 per day. These figures do not independently reconcile the source’s projected $2,400 daily net. They show only known arithmetic. The source does not expose every revenue and cost assumption required to reproduce the projected net figure. No missing revenue source or cost should be inferred to force the numbers to balance. ### Limitations and status The $500 figure is an estimate. Organic liquidity is not guaranteed. A CLOB needs actual orders, so market-specific tradability can vary. AFTERBELL remains under development. Smart contracts are not yet audited, with an audit planned before mainnet. The liquidity model is a planned economic approach, not realized performance. It does not provide yield, APY, liquidity mining, or a guaranteed market making program. --- # 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/liquidity-subsidies.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.