> For the complete documentation index, see [llms.txt](https://monopolyprotocolone.gitbook.io/monopolyprotocol-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://monopolyprotocolone.gitbook.io/monopolyprotocol-docs/tokenomics/fees-risk-reserves-and-revenue.md).

# Protocol Fees Risk Reserves and Revenue Allocation

## 7.1 Sources of Fees

Protocol fees primarily come from prediction market trading, market settlement and other protocol services approved through governance. All protocol fees are denominated or settled in Mono.

In each period, actual fee revenue is calculated from completed trade volumes, applicable fee rates and valid fee reduction rules:

<figure><img src="https://1276328783-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Finuqfd6d5N0HIYTIBhTS%2Fuploads%2FztWsATx8DIR1tRJDSGCd%2Fen-image9.png?alt=media" alt="" width="256"><figcaption></figcaption></figure>

Here, *F*<sub>t</sub> is actual protocol fee revenue in period t; T\_t is the set of trades settled during that period; *V*<sub>i</sub> is the volume of trade i; *r*<sub>i</sub> is the fee rate for the relevant market; and *δ*<sub>i</sub> is the applicable fee discount or rebate rate.

Before the risk reserve reaches its preset target, periodic fee revenue is generally allocated as follows:

| **Use**                                       | **Reference allocation** | **Description**                                                                       |
| --------------------------------------------- | ------------------------ | ------------------------------------------------------------------------------------- |
| Risk reserve replenishment                    | 45%                      | Establish and replenish protocol-level risk reserves.                                 |
| User and ecosystem incentives                 | 35%                      | Incentivize genuine user participation, data contributions and ecosystem development. |
| Protocol operations and long-term development | 20%                      | Support technology, security, infrastructure, operations and long-term development.   |

As protocol trading volume grows, fee revenue *F*<sub>t</sub> increases accordingly, as do the amounts allocated to the risk reserve, ecosystem incentives and long-term development.

Once the risk reserve reaches its preset target, part of the revenue previously allocated to replenishing it may be redirected to direct burns or open-market buybacks and burns under publicly disclosed rules. The thresholds, proportions, execution cycles and adjustment procedures will be disclosed through governance announcements, on-chain records or other verifiable means.

## 7.2 Risk Reserve

The risk reserve is managed through a dedicated vault. Its initial funding includes the risk reserve token allocation, supplemented by ongoing fee revenue after the protocol begins operating. Its target size should be evaluated dynamically based on open interest, market volatility, data quality, historical anomalies and protocol risk parameters, rather than fixed at an unchanging amount.

The reserve is used only for expressly defined protocol risk events, including confirmed smart contract technical anomalies, confirmed data or settlement errors, market dispute handling under preset rules, and protocol-level risk events confirmed through governance.

Activation, transfer or disposal of reserve funds follows preset permission and public record mechanisms. Except for emergency security measures, material fund operations are carried out through multisignature controls, timelocks, governance procedures or other appropriate access controls, with verifiable on-chain records retained.

The risk reserve does not guarantee users’ principal, market prices, trading profits, asset returns or ordinary trading losses. It does not cover losses caused by incorrect market judgments, Mono price fluctuations, leveraged liquidation, insufficient market liquidity or other risks that are not protocol-level risks.

## 7.3 Protocol Revenue Allocation Buybacks and Burns

The protocol will establish a revenue allocation mechanism linked to the scale of its business. Growth in prediction market trading volume generates more protocol fee revenue. Once the established needs of the risk reserve, user incentives and protocol operations are met, more revenue may be used for direct Mono burns or open-market buybacks and burns.

The core logic is:

Growth in market trading volume → Growth in protocol fee revenue → Growth in the amount available for value recirculation → Growth in Mono burned directly or bought back and burned.

For each settlement period, protocol fee revenue may be calculated as follows:

<figure><img src="https://1276328783-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Finuqfd6d5N0HIYTIBhTS%2Fuploads%2FztWsATx8DIR1tRJDSGCd%2Fen-image9.png?alt=media" alt="" width="256"><figcaption></figcaption></figure>

Here, *F*<sub>t</sub> is actual protocol fee revenue in period t; T\_t is the set of trades settled during that period; *V*<sub>i</sub> is the volume of trade i; *r*<sub>i</sub> is the fee rate for the relevant market; and *δ*<sub>i</sub> is the applicable fee discount or rebate rate.

For fees collected directly in Mono, the protocol may transfer a burn proportion *α*<sub>t</sub> to a burn address:

<figure><img src="https://1276328783-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Finuqfd6d5N0HIYTIBhTS%2Fuploads%2FjXrXCcqTTjYGyWhezzL0%2Fen-image10.png?alt=media" alt="" width="130"><figcaption></figcaption></figure>

Here, *D*<sub>t</sub> is the amount of Mono burned directly in period t. As trading volume and effective fee revenue increase, the amount burned directly also increases, assuming other parameters remain unchanged.

For external revenue received in forms other than Mono, or funds allocated to a buyback vault through governance, the protocol may use a proportion *β*<sub>t</sub> to buy back Mono on the open market:

<figure><img src="https://1276328783-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Finuqfd6d5N0HIYTIBhTS%2Fuploads%2FiIuMHOSWG1FX5or6ViGd%2Fen-image11.png?alt=media" alt="" width="129"><figcaption></figcaption></figure>

<figure><img src="https://1276328783-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Finuqfd6d5N0HIYTIBhTS%2Fuploads%2FWt9H4Lhqz7nQkIbf42z1%2Fen-image12.png?alt=media" alt="" width="130"><figcaption></figcaption></figure>

Here, *E*<sub>t</sub> is external revenue or the buyback vault balance available for buybacks; *B*<sub>t</sub> is the current period’s buyback budget; *TWAP*<sub>t,W</sub> is the time-weighted average price of Mono over the specified window W; and *Q*<sub>t</sub> is the expected amount of Mono that can be bought back and burned.

Using TWAP rather than a single-point price for buybacks can reduce the impact of short-term price volatility, insufficient liquidity or abnormal trading on execution. Actual buyback quantities must be determined from on-chain trade records.

The protocol will periodically disclose fee revenue, amounts burned directly, buyback budgets, actual buyback quantities, burn addresses and related on-chain records through its website, governance announcements or blockchain explorers. Before the risk reserve reaches its preset threshold, relevant revenue will prioritize reserve replenishment. Once the threshold is reached, burn and buyback proportions will be adjusted dynamically under publicly disclosed rules or governance procedures.