Trading Models | Phoenix Prediction Docs

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

The model is your operator's trading engine, set by Phoenix. You can read it under Manage > Your operator. A change applies only to books opened after it; a book keeps the engine it opened with.

Operator takeaway

Order-book markets need liquidity and clear support language. AMM/LMSR markets quote directly from the pricing model; Phoenix sets their liquidity, and your levers are your order limits and suspending your book.

Quick Comparison

Topic	Order book	AMM/LMSR
Who provides the other side?	Other players or a market maker	The pricing formula/liquidity pool
Can an order wait?	Yes, if it does not match immediately	Usually no; the system quotes immediately
What moves the visible price?	Matched supply and demand	The formula after each accepted trade
Main support question	"Why is my order still pending?"	"Why did the price change after my trade?"
Main operator concern	Liquidity and pending orders	Liquidity parameter, exposure, and price movement

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 sees	What it means
Order accepted	Phoenix accepted the instruction to trade. It may still be open.
Order filled	The order matched and created or changed a position.
Order partially filled	Some quantity matched and some may remain open.
Order cancelled	No further fills will happen for that order.
Position	The 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:

Topic	Why it matters
Liquidity	Players need enough opposite-side interest or market-making support for orders to fill smoothly.
Order limits	Larger orders can create more exposure and more visible price movement.
Pending orders	Support may need to explain that an accepted order is not always the same as a filled position.
Price steps	Fixed at 0.01: limit prices sit between 0.01 and 0.99.
Minimum order size	Your minimum per currency in each environment, set by your Admin. It keeps tiny orders out of the book and reports.

Two Outcomes

Every market has two outcomes: Yes and No, or two names such as two teams. The back office shows the outcome names ("Bought Yes"); the wallet and the developer APIs call them side a and side b.

Before launch, confirm:

The two outcomes 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 that Phoenix sets. 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.

Whether your markets use an order book or AMM/LMSR depends on your operator's trading engine; check it under Manage > Your operator before writing support scripts.

One Winner Events

An event of several markets of which at most one can resolve Yes (a One winner event, see Your Events and Results) is priced as one set, so a player cannot win by buying No on every outcome.

AMM/LMSR: one shared market maker prices all the outcomes. Their Yes prices add up to 100%, and a buy on one outcome moves the others. Phoenix funds the set with the market maker's maximum loss for each outcome market, so an event of several outcomes is backed by that amount several times, not once for the whole event. When the event says none of its outcomes may win, it also shows a "None of these" line, so the prices still add up to 100%.
Order book: when one of the outcomes always wins, a player who holds No on one outcome can turn it into Yes on every other outcome that can still win ("Turn into Yes on the others" on the position in the embed). It pays the same whichever outcome wins and moves no money, so your wallet is not called. It is not offered when none of the outcomes may win, after an outcome was voided, once the event is decided, or on an outcome that no longer trades.
The outcomes are fixed at the first bet. After it no market can be added to the event.

Order Size Precision

Phoenix accepts only order sizes it can price exactly in the player's currency, so every amount your wallet moves is exact (see Exact amounts and rounding). The rule depends on the trading model and the currency's decimals.

Market	Smallest share quantity a player can trade
AMM/LMSR, any currency	1 share (whole shares only)
Order book, 2-decimal currency (KES, USD, ETB)	1 share
Order book, 3-decimal currency	0.1 share
Order book, 4 or more decimals (USDT, BTC)	0.01 share
Order book, 0-decimal currency (JPY)	100 shares

On an order book the price grid is the fixed 0.01 tick, and the share step is the smallest one that keeps price times quantity a whole number of the currency's smallest unit, and never smaller than 0.01 share. On an AMM the per-share price is rounded to the currency's smallest unit instead (up on a buy, down on a sell), and shares are whole.

Cash amounts follow the currency: a budget or a limit order's total has at most the currency's decimals (2 for KES). A budget buy on an AMM buys the whole shares the budget pays for and releases the rest; a budget too small for one share buys nothing and is released in full.

An order off these grids is rejected with "amount has more decimals than the currency allows" (stored as stake_precision). Phoenix does not round a player's order for them. The minimum and maximum order sizes for each currency in the order's environment (under Manage > Your operator) apply on top, to orders that state an amount (a budget buy or a limit order); a sell sized in shares is not held to them.

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.