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
| 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 |
Default Model: Order Book
Phoenix listing-backed binary markets use an order book.
In an order book market:
- Players place orders for side
Aor sideB. - 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 increments | Tick size controls the allowed price steps. Small ticks give precision; larger ticks are easier to understand. |
| Minimum order size | Prevents 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
Aand sideBare 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.