Phoenix Prediction Docs

Trading Models

Understand order book, AMM, and LMSR behavior

Players experience all Phoenix markets as predictions, but operators should understand which trading model is behind a market because it changes pricing, liquidity, support questions, and risk.

Operator takeaway

Order-book markets need liquidity and clear support language. AMM/LMSR markets need careful exposure settings because the system can quote directly from the pricing model.

Quick Comparison

TopicOrder bookAMM/LMSR
Who provides the other side?Other players or a market makerThe pricing formula/liquidity pool
Can an order wait?Yes, if it does not match immediatelyUsually no; the system quotes immediately
What moves the visible price?Matched supply and demandThe formula after each accepted trade
Main support question"Why is my order still pending?""Why did the price change after my trade?"
Main operator concernLiquidity and pending ordersLiquidity parameter, exposure, and price movement

Default Model: Order Book

Phoenix listing-backed binary markets use an order book.

In an order book market:

  • Players place orders for side A or side B.
  • A buy order says how many claims the player wants and the maximum price they will pay.
  • A sell order says how many claims the player wants to sell and the minimum price they will accept.
  • Open orders can remain pending until they are filled, cancelled, or rejected.
  • Positions come from fills, not just from submitting an order.

The player-visible price is shaped by real order supply and demand. If there are few matching orders, a player may not fill immediately at the price they want.

Order Status vs Position

This distinction matters in support conversations.

Player seesWhat it means
Order acceptedPhoenix accepted the instruction to trade. It may still be open.
Order filledThe order matched and created or changed a position.
Order partially filledSome quantity matched and some may remain open.
Order cancelledNo further fills will happen for that order.
PositionThe player has actual exposure to the market outcome.

Do not tell players that every accepted order is already a settled position. That creates finance and support confusion when an order sits open.

Operator Implications

Order-book markets need clear operational expectations:

TopicWhy it matters
LiquidityPlayers need enough opposite-side interest or market-making support for orders to fill smoothly.
Order limitsLarger orders can create more exposure and more visible price movement.
Pending ordersSupport may need to explain that an accepted order is not always the same as a filled position.
Price incrementsTick size controls the allowed price steps. Small ticks give precision; larger ticks are easier to understand.
Minimum order sizePrevents tiny orders from cluttering the book and reports.

Binary Claim Sides

Binary markets use sides A and B.

The labels shown to players can be Yes and No, two teams, two price directions, or any pair of mutually exclusive claims. Admin and API surfaces use canonical sides A and B because labels can change by market format.

Before launch, operators should confirm:

  • Side A and side B are mutually exclusive.
  • One side will be correct when the market resolves.
  • The market wording, claim labels, and resolution rule all point to the same outcome.

AMM and LMSR

An AMM prices trades against a formula instead of waiting for another player order. LMSR is one AMM-style pricing model where price moves automatically as players buy an outcome.

In LMSR-style markets:

  • The market can quote a price even when no other player is waiting on the other side.
  • Liquidity is controlled by a parameter. More liquidity means prices move more slowly; less liquidity means prices move faster.
  • The wallet flow is usually simpler because a quoted action can reserve and capture cash immediately.
  • Settlement payouts are still credited after the market resolves or voids.

Some environments can be configured for AMM/LMSR-style markets, but the listing-first player experience is order-book oriented. Operator runbooks should assume order-book behavior unless Phoenix explicitly tells you an environment is using an AMM/LMSR market.

Wallet Impact

The trading model also changes wallet expectations.

Order-book markets use reservation-style wallet operations: reserve cash before buy orders open, capture reserved cash when fills happen, release unused reserves when orders are cancelled, and credit cash for proceeds and settlement.

Before launch, operators should understand which player-visible states map to wallet states. An accepted order, a filled order, a released reserve, and a credited payout are different moments.

How to Explain It to Players

For order-book markets, avoid copy that promises instant purchase or guaranteed fill. Use language like "place order" and "position" rather than "buy now" when the order may wait for a match.

For AMM/LMSR markets, quote and buy language can be appropriate because the system can price the trade directly.

What to Watch Daily

  • Open orders that are not filling.
  • Markets with one-sided demand.
  • Player questions about why an order is pending.
  • Large orders near close time.
  • Markets where the displayed claim labels are clear, but the resolution rule is not.