> 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/protocol/prediction-market-mechanisms.md).

# Prediction Market Mechanisms

## 4.1 Market Scope and Content Boundaries

In its first phase, MONOPOLY Protocol primarily offers prediction markets that settle at expiry. Its markets concern events with public information sources, definable outcome conditions and verifiable settlement evidence. Priority coverage will include cryptoasset and financial market data, public stock-related prices and events, entertainment-related events, and topics of public interest with clearly defined public data sources.

For cryptoasset and financial markets, the protocol may create markets around cryptoasset price ranges, on-chain indicators, market data, interest rates, yields and public financial indicators. For stock-related topics, it may create markets around public market price ranges, financial report disclosures, index performance, public operating data or other verifiable events. Such markets reflect only users’ judgments about public outcomes. They do not constitute the purchase, sale, custody or issuance of stocks, securities, funds or other financial products, or investment advice.

Entertainment-related markets may cover sporting events, film and television, music, cultural activities and other events with public outcome sources. Markets concerning topics of public interest should be based on publicly verifiable factual outcomes, avoiding personal privacy, harmful events, illegal activities or subjective questions that cannot be determined objectively as trading subjects.

Each market is built around a verifiable question, such as whether a public indicator meets a specified condition by a specified time, whether an asset price falls within a specified range, or whether a public event occurs.

Markets are based on YES/NO outcomes. Users may hold YES shares or NO shares and receive settlement according to the market outcome.

## 4.2 Trading and Price Formation

In its first phase, the protocol uses off-chain order matching and on-chain asset settlement. Users submit orders signed with their wallets. The matching system matches orders, while on-chain contracts execute or record the resulting positions, asset ownership and settlement outcomes.

Each complete set of positions is created with 1 Mono and contains both 1 YES outcome share and 1 NO outcome share. At final settlement, a winning outcome share can be redeemed for 1 Mono, while a losing outcome share becomes worthless. Thus, excluding trading fees, slippage and short-term liquidity deviations, the market satisfies the complete-set constraint:

<figure><img src="https://1276328783-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Finuqfd6d5N0HIYTIBhTS%2Fuploads%2FMMLxrmRA8pIRQ9DkpFjM%2FMono-eq-0.png?alt=media" alt="" width="292"><figcaption></figcaption></figure>

Here, *V*<sub>t</sub>(Yes) and *V*<sub>t</sub>(No) represent the market prices of YES and NO outcome shares at a given time. This constraint provides a basic price anchor. When the prices of the two types of shares diverge excessively from the constraint, market participants can arbitrage by creating, splitting or trading complete sets, helping bring prices back into a reasonable range.

The protocol calculates the market midpoint using the best bid and ask in the frontend order book:

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

Here, *M*<sub>t</sub><sup>i</sup> is the midpoint for outcome i, *A*<sub>t</sub><sup>i</sup> is the current lowest ask, *B*<sub>t</sub><sup>i</sup> is the current highest bid, and i ∈ {Yes, No}.

Using the midpoints for both outcomes, the protocol generates normalized implied outcome probabilities:

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

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

To reduce the effect of individual small trades, brief abnormal quotes or insufficient liquidity on displayed prices, the protocol may additionally display a liquidity-weighted market reference probability on the frontend:

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

Here, *p*<sub>k</sub> is the implied probability of the kth valid trade within the observation window, and *w*<sub>k</sub> is that trade’s weight. Weights may take into account trade size, trade time, order book depth and abnormal-trading detection results. Larger, more recent trades made under normal market conditions receive greater weight.

The prices of YES and NO shares reflect participants’ real-time judgments about market outcomes, not predictions or commitments by the protocol. Market reference probabilities are used only for information display, risk notices and liquidity analysis. They do not determine final outcomes or replace the data sources and settlement rules disclosed in advance.

The implied probability of an outcome is distinct from the market price of Mono itself. Because users use Mono for collateral and settlement, they bear the risk of Mono price fluctuations in addition to the risk of an incorrect judgment about an event.

## 4.3 Market Creation Review and Rule Disclosure

Before each market opens, its rules, content boundaries, data sources and risk parameters should be configured and reviewed. The market page should clearly display the title, trading subject, outcome determination conditions, opening and closing times, expected settlement time, primary and backup outcome sources, and their applicable priority order.

Markets may be created only for events with public information sources, verifiable outcomes and clear settlement conditions. Market creation must comply with the protocol’s content boundaries and must not involve political elections, political party activities, political figures, the direction of government policy, international political conflicts or other politically sensitive topics.

Once a market opens, its core determination conditions, outcome sources and settlement rules must not be changed arbitrarily. If material ambiguity in the rules, data source failure, a system anomaly or another situation that may affect market fairness is identified, the protocol may pause trading under preset procedures and handle the situation through delayed settlement, review, market cancellation or another established method.

Before trading begins, market rules should explain the principles for handling data delays, disputed outcomes, market cancellation and indeterminate outcomes. Unless the market rules expressly provide otherwise, collateral pending settlement in a canceled market should be returned or otherwise handled according to verifiable on-chain records and preset rules.

## 4.4 Outcome Submission Challenges and Final Settlement

The protocol confirms outcomes through outcome submission, public challenges, independent review and on-chain settlement. A market outcome is not determined directly by a single protocol party, a single data source or a single governance proposal.

| **Role**                 | **Selection or appointment**                                                                       | **Main responsibilities**                                                                                                                                                       |
| ------------------------ | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Outcome submission nodes | The market’s preset primary data source or data and oracle nodes designated by the protocol.       | Submit a preliminary outcome based on the outcome sources and determination conditions disclosed in advance.                                                                    |
| Challengers              | Participants who meet the market rules.                                                            | Challenge outcome sources, data completeness or determination logic during the challenge period, submitting evidence and a challenge bond.                                      |
| Outcome review nodes     | Selected from the protocol’s publicly disclosed set of qualified oracle and data validation nodes. | Independently review and vote on valid challenges, conflicting data and exceptional situations.                                                                                 |
| Governance mechanism     | Operates under the protocol’s governance rules.                                                    | Manage review node admission, incentives, penalties, market templates and exception procedures; it does not directly determine individual market outcomes through ad hoc votes. |

After a market closes, outcome submission nodes submit a preliminary outcome based on its previously disclosed primary and backup outcome sources and determination conditions. The market then enters a public challenge period. Eligible market participants may challenge the outcome during that period by providing verifiable evidence and the preset Mono challenge bond.

If the challenge period ends without a valid challenge, the preliminary outcome becomes final. The on-chain settlement contract completes settlement automatically or under the established procedure. Winning outcome shares can be redeemed for the corresponding Mono collateral, while losing outcome shares no longer have redemption value.

If a valid challenge, conflicting data sources, a data delay or a material anomaly arises, the market enters review. The protocol selects at least three nodes from its publicly disclosed set of qualified outcome review nodes to form a temporary review panel. None may have a direct conflict of interest in that market. Review nodes should deliberate according to the outcome source priority, determination conditions, challenge materials and exception handling rules published before the market opened.

A reviewed outcome can become final only if it receives support from at least two-thirds of valid review votes:

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

Here, *N*<sub>supporting outcome</sub> is the number of valid review votes supporting a particular outcome, and *N*<sub>valid review votes</sub> is the total number of valid review votes, excluding abstentions, recusals for conflicts of interest and invalid votes.

Review nodes’ conclusions, the data sources used, valid vote counts and final disposition should be disclosed through on-chain records, market pages or other verifiable means. Malicious outcome submissions, malicious challenges or violations of review rules may result in loss of bonds, suspension of node eligibility or other appropriate measures under preset rules.

If the review panel cannot reach a valid conclusion within a reasonable period, or neither primary nor backup sources can confirm the outcome, the market should apply its preset exception handling rules, such as postponement, cancellation or return of collateral. Governance may adjust review procedures, node eligibility and rule templates, but must not bypass established rules after a market opens to directly change that market’s outcome.

## 4.5 Perpetual Market Roadmap

The first-phase product centers on markets that settle at expiry. Such markets have clear closing times, outcome conditions and settlement points, making them more suitable for establishing verifiable market rules, data mechanisms and risk controls during the protocol’s early stage.

Once trading, data and risk infrastructure matures, the protocol plans to explore perpetual markets and leverage. Perpetual markets would primarily serve demand to trade continuous prices, ongoing event probabilities or long-term market expectations. Leverage would allow users to increase position exposure within specified collateral limits.

Before perpetual and leveraged products launch, the protocol must deploy and stress-test isolated margin, initial and maintenance margin ratios, mark prices, risk limits, forced liquidation, funding rates or equivalent balancing mechanisms, and protection against abnormal market conditions. All leveraged positions will use Mono as collateral and the settlement asset. In addition to market judgment risk, users must bear Mono price risk and the liquidation risk amplified by leverage.

Perpetual markets and leverage are part of the future product roadmap. This does not constitute a commitment that these features are currently live or will necessarily launch.