Polymarket terms deep dive
Clear, trader-focused explanations of the Polymarket terms that confuse newcomers: CLOB, CTF, UMA, FAK and how they interact on Polygon.
Polymarket terms deep dive
This guide is a concise, trader-focused "Polymarket terms deep dive" that explains the platform vocabulary most often misunderstood by new users. Read this to quickly connect the technical pieces — CLOB, CTF, UMA, FAK — to everyday actions like placing orders, splitting sets, and waiting for resolution.
Key takeaways
- CLOB is the matching engine that runs limit and market orders on Polymarket; maker fees are zero and taker fees vary by category.
- CTF is the on-chain ERC-1155 system that mints, merges, and redeems outcome tokens; pUSD is used to split into complete sets.
- UMA is the optimistic oracle Polymarket uses for resolution; disputes can pause settlement and affect timing.
- FAK (Fill‑And‑Kill) is Polymarket's market‑order behaviour: immediate execution or cancellation, with built‑in slippage protection.
1. CLOB — the book behind every quote
CLOB stands for Central Limit Order Book. On Polymarket, the CLOB is the exchange component that records limit orders, matches buyers and sellers, and exposes order‑book and midpoint data. When you place a limit order you join the book as a maker; when you take liquidity you pay the taker fee.
Important operational facts:
- Reads from the CLOB are exposed via the public CLOB REST surface at https://clob.polymarket.com (writes require API key + HMAC).
- The CLOB determines best bid, best ask, spread, and midpoint. The WebSocket stream at wss://ws-subscriptions-clob.polymarket.com/ws/market provides real‑time book events like best_bid_ask and last_trade_price.
Why it matters to traders: understanding how the book aggregates orders explains why spreads tighten on liquid markets and why arbitrage edges often evaporate in seconds.
2. CTF — how outcome tokens are created and settled
CTF means Conditional Token Framework (Gnosis's ERC-1155 pattern). Polymarket uses CTF to represent each outcome as an on‑chain token. Operations you will use:
- split: take pUSD and mint a complete set of outcome tokens (one token per outcome) for the market condition.
- merge: convert outcome tokens back into a single token class when appropriate.
- redeem: after resolution, burn winning tokens to receive $1.00 each in pUSD.
Practical implications:
- Buying a complete set by splitting costs roughly $1.00 in pUSD (plus any market spreads you pay on the CLOB). A complete set guarantees you hold each outcome token, so redeeming the winning leg yields the $1.00 per winning token after UMA resolution.
- CTF operations are handled through Polymarket's Relayer so users do not pay gas; the Relayer abstracts wallet deployment and ERC-20 approvals.
3. UMA — the oracle that makes markets resolvable
UMA is the optimistic oracle Polymarket uses to determine market outcomes. UMA's process is not instant: it accepts a proposed value and allows a dispute window. If a dispute is raised, the oracle process can lengthen settlement.
Key trader consequences:
- Resolution timing is probabilistic: disputes can pause or delay redemption of winning tokens, which affects when funds become withdrawable.
- Disputed resolutions introduce settlement risk; arbitrage and endgame strategies should account for the possibility of delayed payout.
4. FAK — what Polymarket means by market order
FAK stands for Fill‑And‑Kill. Polymarket exposes market order semantics via a createMarketOrder helper that behaves as FAK: it attempts immediate execution against current resting orders and cancels any unfilled remainder.
Operational details:
- FAK provides instantaneous execution or cancellation; it protects traders from unintentionally leaving an order on the book.
- Polymarket's implementation includes automatic slippage protection; the SDK helper calculates acceptable execution bounds.
Why this matters for execution strategy:
- FAK is useful when you need immediate execution without leaving a child order on the book. For large fills or thin markets, you may still face partial fills and slippage.
- The presence of taker fees (variable by category) means immediately executed liquidity carries a cost that must be included in any execution calculus.
5. How these pieces work together during a trade
Step through a common flow:
- You view market prices from the CLOB (best bid, best ask, midpoint). The WebSocket stream can show real‑time changes.
- You place a limit or market (FAK) order through the CLOB API or Polymarket UI; the Relayer handles wallet/approval steps gaslessly.
- If you buy a complete set you will call CTF split (mint outcome tokens) with roughly $1.00 in pUSD; after resolution you call redeem to convert winning tokens to $1.00 pUSD.
- Resolution is sourced from UMA; disputes can delay redeemability and therefore settlement.
Understanding the lifecycle clarifies where execution risk, settlement timing risk, and oracle risk live in the stack.
6. Common misunderstandings corrected
- "The book is off‑chain": false. The CLOB exposes a public API and a WebSocket; order placement and cancellation pass through authenticated endpoints.
- "Outcome tokens are ERC‑20": outcome tokens are ERC‑1155 under the CTF model.
- "FAK is a guaranteed full fill": no. FAK attempts immediate execution and cancels the unfilled remainder; partial fills are possible.
- "Resolution always pays immediately": not always. UMA disputes can pause settlement.
How this affects your trading
Knowing these terms helps you pick an execution approach. Use the CLOB data for timing; prefer FAK for quick fills when you accept possible partial execution; use split/merge/redeem flows when you want tokenised exposure or to lock a complete set for arbitrage. Always factor in taker fees, slippage, and potential delays from UMA disputes when you compute realised outcomes.
Closing note: this guide focused on the technical roles of CLOB, CTF, UMA, and FAK and how they interact. Keep these mechanics in mind when designing order logic or risk controls; the words map directly to on‑chain actions and observable API behaviour.
Frequently asked questions
Is a market order on Polymarket the same as an exchange market order?
Polymarket's market order behavior is implemented as FAK (Fill‑And‑Kill): the order attempts immediate execution against resting liquidity and cancels any unfilled remainder. It is similar to exchange market orders but allows partial fills and includes built‑in slippage protection.
When should I use split/merge operations?
Use split when you want a complete set of outcome tokens (for example, to capture a combinatorial arbitrage edge). Merge is used to recombine outcome tokens when you no longer need separated legs. Remember that splitting requires roughly $1.00 in pUSD per complete set and that redemption waits on UMA resolution.
How do UMA disputes affect my ability to redeem winnings?
UMA runs an optimistic resolution process with a dispute window. If a dispute is raised, settlement can be delayed until UMA finalises the result, which postpones redeeming winning tokens into pUSD.
Are outcome tokens transferable?
Outcome tokens are ERC‑1155 tokens under the CTF model, and they can be transferred between wallets using the normal token transfer mechanics. Polymarket's Relayer can also handle these operations gaslessly for supported wallets.
Do makers pay fees on Polymarket?
Maker fees on Polymarket are zero; taker fees vary by category and currently range between 0% and 1.8%, with some categories (e.g., Geopolitics) fee‑free.
참조된 용어
관련 가이드
교육용 자료입니다. 재무, 법률 또는 세금 조언이 아닙니다. Polymarket은 귀하의 관할 구역에서 사용 불가할 수 있습니다.