Risk and Liquidity
Practical checks for exposure, fees, and market demand
Each operator owns its player relationship, wallet model, liquidity plan, and counterparty risk. Phoenix provides the market system, but the operator is responsible for how much exposure it is willing to take.
Risk is operational, not only financial
Ambiguous wording, thin liquidity, and slow settlement can create support pressure even when the market engine is working correctly.
What Market Risk Means Here
Players trade Yes/No markets inside events. Read Trading Models for the difference between order-book and AMM/LMSR behavior.
In practical terms:
- Higher order limits can increase exposure quickly.
- Thin or one-sided demand can make a market hard for players to understand.
- Order-book markets can have accepted orders that are still waiting to fill.
- Ambiguous rules create support pressure even when the trading system behaves correctly.
Phoenix can help tune this, but your team should understand the tradeoff before promoting high-volume events.
Liquidity in Order-Book Markets
In an order-book market, a smooth player experience depends on there being enough matching interest.
Operators should decide before launch:
- Whether the market needs active market-making support.
- What spreads are acceptable for the player audience.
- How long a typical order can remain open before support questions start.
- Whether low-liquidity markets should be featured, hidden (in Curation), or delayed.
- Who is watching high-volume markets near close time.
Low liquidity is not only a trading issue. It becomes a player trust issue when users think they placed a prediction but do not understand why the order has not filled.
Exposure Checks
Before promoting a market, ask:
Confirm the maximum single-order size for the currency (Manage > Your operator).
Estimate expected maximum total volume.
Check whether one outcome could attract one-sided demand.
Confirm the resolution source is reliable enough for the expected volume.
Make sure support and trading teams understand the market rule.
Fees
Fees come from the fee schedule Phoenix sets for your operator: a taker fee, and a maker rebate where one applies. You can read it under Manage > Your operator or through the Operator API. A fee is charged to the taker on each fill, at trade time: a flat rate on the amount traded, or a curve that is largest at a 50% price and near zero on long shots, depending on your schedule. It is not charged on profit at settlement, so a player pays it whether or not the position later wins. The fee is rounded up to the currency's smallest unit.
You cannot change the fee schedule yourself. Before asking Phoenix to change fees:
- Confirm the fee is allowed in the operator's jurisdiction.
- Confirm player-facing copy is clear.
- Test quotes so the buy flow shows expected gross and net outcomes.
- Do not change fees casually on markets that players already understand differently.
When to Use Smaller Markets
Start smaller when:
- The market format is new to your players.
- The resolution source has not been used in production before.
- The market wording could create disputes.
- You are launching a new category or event type.
- Settlement monitoring is not yet routine for the team.
Warning Signals
Investigate quickly when:
- Order failure rates spike.
- One market is taking far more volume than expected.
- Players are asking what a market means.
- A data provider or event source changes its result timing.
Where to Look
- Event page > Liabilities: what your players would be paid on each outcome of a market (If Yes, If No).
- Dashboard: which events carry the volume, and the books you have suspended.
- Trades: large orders and rejected attempts as they happen.
The best risk control is usually a clear market rule before launch. The second best is acting early when the real-world situation no longer matches the original rule: suspend your book on a platform event, or hold or close your own market.