TIP 3: Outcome Markets

Outcome markets are prediction markets expressed as instruments. A market settles to a settlement fraction of 0, 0.5, or 1, and shares of each side redeem to the margin asset at that price (YES) or 1 − fraction (NO). Internally, outcome reuses the perpetual position machinery — it is treated together with perps — with a fixed-price split/merge mechanism layered on top.

Market definitions

An outcome market separates its human-readable definition from its tradable instrument. Three protocol concepts make up that definition:

Display copy is not required on-chain. A registrar may attach a template so clients can render a title and description from consensus data, or register a template-free market and keep that copy in an application metadata service.

For example, a template may define the title {asset} above {price} at {expiry}?. A market supplies values such as BTC, 65000, and 20260812-0600; clients combine the template and those values to display the complete question.

Templates

A template contains:

• a globally unique templateId — 1–64 bytes of lowercase ASCII letters, digits, or -;
• a title template and description template;
• two side names, such as Above and Below;
• a list of named parameters (keywordSpecs) and their value types (dateTime, date, string, instrument, uInt, uDecimal);
• an enabled status.

Templates are maintained by TxFlow governance and can be reused by markets in different channels. At most 1,024 templates may be registered. A disabled template remains queryable so that existing markets can still be rendered, but it cannot be used to create new markets.

Images, logos, banners, and other presentation assets are not part of a template or market definition. Applications may attach them through their own metadata services.

Events and markets

Every market has an instrumentId and belongs to one event in one channel. The event is identified by the pair (exchangeId, eventSlug):

• exchangeId is the channel identifier (0 is the default platform channel).
• eventSlug is a stable value supplied by the market registrar: 1–256 bytes of ASCII letters, digits, -, _, ., or :.

A registrar may change its own mapping from that slug to an external event ID without changing the TxFlow market definition. The same eventSlug may be reused in a different channel without joining those markets into one event.

Multiple markets can share the same event. For example, one event may contain separate markets for BTC finishing above 65,000 and above 70,000 at the same expiry. Each market has its own instrument ID and order book while remaining discoverable as part of the same event.

A market may be registered with a template instance (templateId plus keywordValues) or with no template. Template-free markets still carry eventSlug and the trading parameters; query services render them with eventSlug as the title, empty description, and default side names Yes / No.

The instrumentId is also the identifier used by the shared trading and account APIs.

Shares as a complete set

An outcome market has two sides — call them YES and NO — represented as a long and a short position leg. They are linked by a fixed relationship:

price(YES) + price(NO) = 1

The split price and merge price are both fixed at 0.5: one unit of margin collateral splits into one YES share and one NO share, each worth 0.5, summing to 1.

Split and merge are submitted as a single signed POST /exchange action, outcomeOperate, which carries a batch of split or merge items. A batch may contain at most 50 items.

Split

Each split item takes sz units of margin and mints a complete set:

1. Freeze sz of margin collateral from the outcome account.
2. Open a long (YES) leg of size sz and a short (NO) leg of size sz, both at price 0.5.

The user now holds both sides and can sell either into the order book. Split is skipped (not failed) for an item if available balance is insufficient or sz is invalid — each item in a batch is processed independently.

Merge

merge is the inverse: combine a matched YES + NO set of size sz back into sz units of margin collateral, releasing the frozen collateral. Merge is guarded by a can_merge check (the user must hold both legs in sufficient size); failing items are skipped.

Trading

Beyond split/merge, outcome shares trade through the shared order book and matching path like any other instrument — market/limit orders, the standard time-in-force set, and price–time priority. A user who wants only one side can split a set and sell the unwanted leg, or simply buy the desired side from the book.

Resolution

When the market's real-world outcome is known, it is settled via SettleOutcomeV2:

• resolution_status moves from prepared to resolved (config field).
• settlement_fraction is 0, 0.5, or 1 (trailing zeros are stripped: "1.000" → "1").
• YES redeems at the settlement fraction; NO redeems at 1 − fraction, paid out in the margin asset.

0.5 is an even settlement: both sides redeem at 0.5. An optional settlement_details string (up to 2 KB) may record the rationale; it is stored in consensus history and is not used in payout math.

A resolved market cannot be settled again, and its trading parameters (such as price_tick) cannot be updated.

Configuration

Outcome markets carry an OutcomeExtConfig in the instrument's ext_config:

Fee for a fill is fee_rate × (p × (1 − p))^exponent, where p is the fill price. All other fields come from the common InstrumentConfig with instrument_type = outcome.

Account

Outcome activity settles on the dedicated outcome sub-account, with the same three-bucket balance accounting as the other sub-accounts. Margin for open share legs is sourced from the outcome account.

Application risk notice

The first-party application asks a wallet to acknowledge the Prediction Market risk notice before enabling its trading UI. Checking and recording that acknowledgement uses application-session account endpoints, not POST /info, POST /exchange, or the consensus protocol. Third-party integrations should present disclosures appropriate to their product and jurisdiction; those application-only endpoints are not part of this public API reference.

On-chain data and recovery

Template registration and status changes, market registration, and market settlement are recorded in consensus-ordered block history. This allows an application to reconstruct the protocol-defined outcome data from blocks rather than relying on a single application database.

The recoverable definition includes:

• templates and their enabled status;
• events and their channel membership;
• the markets attached to each event;
• market parameters and settlement history.

Query services may index this block history to provide application-friendly views. Those views are derived from the same consensus data and may briefly lag the latest block. Live order books, positions, balances, and open orders remain trading-state queries rather than market-definition data.

Querying outcome markets

Outcome markets are queried on POST /info:

For the live product flow, use outcomeBbos for discovery-card quotes, l2Book and trades for one market, and outcomeOrderUpdates for matching lifecycle. The API-service outcomeOrderUpdate reports asynchronously accepted Outcome orders that fail before reaching the book, while candle supplies the live probability bar.