A prediction market website is the entrance to a system with several jobs. The interface presents a market, the exchange matches orders, contracts settle asset movements, and data services make the result readable. An oracle supplies the market’s eventual answer through its configured resolution process.
Those jobs happen in different places. A button click, an accepted order and a settled trade are different milestones. Understanding the boundaries explains why a market can be visible while trading is unavailable, or why a completed transaction can take time to appear in a portfolio.
This is the second article in How Polymarket and Kuest work. Start with what a prediction market price actually means if prices and payouts are new to you.
Four layers, four responsibilities
| Layer | Role |
|---|---|
| Interface | Present questions, rules and account controls |
| Exchange | Validate orders and find compatible trading interest |
| Contracts | Enforce the asset and permission rules of the selected route |
| Data services | Organize metadata, balances and activity for applications |
Polymarket’s API overview reflects this separation: Gamma supports discovery, CLOB supports orders and live market state, and Data API supports account and market activity. WebSockets provide updates; they do not replace the underlying settlement rules.
A page is not a position identifier
An event groups related markets for presentation. A binary market asks a particular resolvable question and exposes separate YES and NO outcomes. One event can contain several markets, so its page address is not enough to specify an order. See Polymarket’s market and event model.
In the Conditional Tokens Framework, or CTF, the question ID identifies resolution input. The condition ID is derived from the oracle address, question ID and number of outcome slots. An outcome position ID also depends on the collateral and collection path. These identifiers cannot safely be substituted for one another.
A grouping map, not a hash formula. Select the exact market and outcome before reading its book or placing an order.
Polymarket’s on-chain data guide distinguishes those CTF derivations from Protocol V2 identifiers. A matching title on another site is not proof of the same asset.
Follow one order through the system
First, the interface finds a market and obtains its outcome identifiers and trading configuration. The client prepares an order, and the relevant signer authorizes its terms. Signing an order is not the same action as broadcasting a blockchain transaction.
The signed instruction reaches the central limit order book, or CLOB. The service checks admissibility and looks for compatible orders. A permitted order can remain open if it cannot execute immediately; a match is an agreement to trade under the exchange’s rules, not yet evidence of delivered assets.
Next comes settlement. An execution service submits a transaction to the relevant contracts on Polygon. The settlement route validates the authorized trade and updates assets if execution succeeds. A failed transaction does not become a successful purchase simply because the API previously reported a match.
Solid arrows follow the instruction toward settlement. Dashed arrows show recorded data returning to the interface; they do not move collateral.
Polymarket documents the order lifecycle and separately instructs integrations to wait for fill settlement before checking the resulting position. Transaction inclusion and the required confirmation state matter; an order ID alone is insufficient.
Finally, indexers process recorded changes and APIs serve updated views. The interface can now show the position and activity. These stages need separate status messages, rather than one ambiguous “success”.
The contracts are a family, not one box
A CTF-based system divides responsibilities among several contract families. The names below describe roles; the exact contracts and permissions depend on the route.
A responsibility map. These panels are not a claim that every transaction calls all five families.
| Family | Role |
|---|---|
| Wallets, factories and upgrade infrastructure | Hold assets and apply ownership, signing and implementation rules |
| CTF Exchange or a negative-risk exchange route | Validate and settle the applicable matched orders |
| Conditional Tokens | Track CTF outcome balances and support split, merge and redemption |
| Oracle adapters and resolution routes | Connect an accepted answer to the payout recorded for a condition |
| Fee, reward and escrow support | Serve additional accounting, incentive or funding workflows where configured |
Settlement and resolution answer different questions. Settlement asks whether this trade can move assets. Resolution asks which payout the market’s rules imply. Polymarket’s resolution documentation currently distinguishes UMA-based markets from Chainlink TWAP up/down markets; a matching engine does not decide that result by choosing a trade price.
Version matters. Polymarket currently documents both CTF and Protocol V2 position systems. Protocol V2 uses PositionManager, while CTF uses Conditional Tokens. Its contract registry lists different settlement components. “Exchange V2” is not interchangeable with “Protocol V2”; always identify the market version, ledger and route together.
Data makes the ledger usable, but it can lag
An indexer turns contract events into queryable records. An API can combine those records with market metadata, prices or calculations. That is useful application data, but its update schedule can differ from a transaction receipt or a live order feed.
Polymarket’s on-chain data guide describes transfer and exchange-fill events. Those records do not contain every resting off-chain order. Likewise, calling an indexer an “orderbook subgraph” does not turn it into the live book. A current quote and a historical fill belong to different records.
If a portfolio looks stale, compare its update time with the transaction and relevant ledger. If a quote disappears, inspect the current book. Those are different investigations; refreshing a catalog is not proof of either an unfilled order or missing funds.
A relayer helps submit transactions; it does not remove dependencies
A relayer can submit supported wallet actions such as deployment or approvals. Polymarket’s wallet documentation describes sponsored actions that let the account operate without holding the native gas token for those calls. Gas is still consumed; its cost is paid elsewhere.
A wallet relayer and the exchange’s matching and settlement services have different jobs. Availability, supported calls and sponsorship policies matter. Do not assume every trade passes through a wallet relayer, or that sponsorship proves anything about custody, upgrade authority or oracle correctness.
How Kuest differs: the storefront can change while the route is shared
Kuest’s public architecture guide distinguishes the operator’s brand and catalog from the shared trading infrastructure. Operators can select markets for their audiences while using compatible common execution services.
Shared execution requires matching services, network and assets. Separate branding does not create or guarantee liquidity.
Two branded sites using the same Kuest services and assets can expose common trading interest while presenting different catalogs. For an operator, that means reusing execution infrastructure while curating a focused experience for an audience.
The operator presents the market to traders; a market maker supplies trading interest through orders. Those participant roles are separate from the services that match and settle trades. Creating a market does not itself supply willing counterparties or executable size.
Shared Kuest services do not merge its book with Polymarket’s, and a mirrored question does not make balances transferable between venues.
The contract families above explain responsibilities, not a complete deployment inventory. Before operating a market, verify the actual network, contract addresses, published code, permissions and supported position system. An upstream audit does not automatically cover another deployment or custom changes.
For an operator, the useful review is concrete: which market assets does this site show, which services accept its orders, which contracts settle them, and how fresh are the displayed records? A new brand should make those answers easier to find.
Want to build that experience for your audience? Create your own prediction market through Kuest’s guided setup.