How Polymarket Works | The Tech Behind Prediction Markets

If you’re building a prediction markets platform like Polymarket — or maybe just doing some research — this post is for you.

We’ll walk through the key technical components behind Polymarket, including its hybrid off-chain/on-chain order book, how it manages market conditions with the Conditional Tokens Framework, and how it uses UMA’s optimistic oracle for settlement. This is a straightforward overview of the system’s architecture and mechanics.

So, what exactly is Polymarket?

Let’s dive into Polymarket — a protocol built around prediction markets or event markets. At its core, Polymarket is a platform where future events are listed — events that might or might not happen. The key idea is that users can try to predict the outcome and potentially earn by being right. And yes, it sounds like on-chain betting, but there are important nuances we’ll cover.

As mentioned earlier, Polymarket is an event market. Users can buy and sell shares tied to different events. To put it simply, each event on Polymarket is basically a yes-or-no question — will something happen or not? For example  “Will TikTok be banned again before May?” This is an older example as our original research was done a while ago, but it still works to explain the concept.

For every event, there are two types of shares: YES and NO. These are opposing outcomes of the same event. You can buy or sell either type. The price for each share ranges from $0 to $1 and always adds up to $1 between the two. In other words, 1 dollar equals 100% total probability, split between both outcomes and the price of a share reflects how likely users think a particular outcome is.

Looking back at the example, “Yes” shares are trading at 36 cents each, while “No” shares are at 66 cents. This means the market thinks there’s a 66% chance TikTok won’t get banned before May, and a 36% chance that it will. A key point is that if you add the prices of both opposing outcomes, you get roughly $1. That makes sense, because it’s basically adding up the probabilities of the two possible outcomes — which should total 100%.

Now, a bit more about event publishing.

Every event has a deadline to verify the result — in the example, it’s right there in the title: before May. When the deadline passes, the outcome gets finalized. At this point, shares for the correct outcome rise to $1, while shares for the wrong outcome become worthless.

So if a user bought $100 worth of NO shares at $0.66. That’s about 151.5 shares. If the event doesn’t happen, those shares settle at $1 and the user ends up with $151.5 — a $51.5 profit. If the event does happen, those NO shares go to zero, and the user takes the full $100 loss.

It’s also worth noting that not all users wait for the event to end. Some sell their shares earlier to profit from shifts in how the community feels about the event’s likelihood. In other words, Polymarket is a trading platform that publishes markets as events where you can trade shares the usual way like any other asset and speculate on the odds shifts.

Order Book

When we say “you can trade shares the usual way,” we’re talking about an order book. In Polymarket’s case, it’s not the standard order book you'd see on a typical exchange — it has a few key differences.

First, it’s a CLOB — a central limit order book. “Central” means all orders are collected in a single place. On Polymarket, each event has its own dedicated order book where you can view every order placed in that market. This setup makes it easier to observe supply and demand and ensures transparency across the board. “Limit” just means that the book handles limit orders — orders that come with specific execution conditions or time constraints.

Second, Polymarket’s documentation refers to the order book as hybrid-decentralized. That means it combines both off-chain and on-chain components. Off-chain, there’s a backend operator responsible for tracking and matching orders, as well as preparing the data needed for market orders. On-chain, a smart contract receives that data and handles the calculations and actual order execution. This contract also interacts with the shares themselves (spoiler: shares are also contracts), and manages settlement in USDC.

Third, the order book is purpose-built for trading binary options. When a user places a limit order, the system also displays a mirrored order for the opposite outcome.

Say a user places a limit order to buy 100 YES shares at $0.40. The system will automatically show a mirrored order: a sell order for 100 NO shares at $0.60. The original order doesn’t actually change — the inversion is purely visual. A buy becomes a sell, and the price is displayed as 1 minus the original price.

That’s how the unified order book for binary markets works. Every order placed on one side is reflected as its inverse on the other, keeping both outcomes aligned and the market consistent.

This design is based on Polymarket’s core assumption: one YES share and one NO share always equal one dollar. That comes from the basic definition of probability — when you have two opposite outcomes, the probability of one is 100% minus the probability of the other.

Because of this, any order can be interpreted as its opposite. It might feel a bit abstract at first, but we’ll keep referring back to this principle — and it’ll make more sense as we go.

How Prices and Probabilities Form in Polymarket Markets

Let’s recall, we have events, outcomes, shares, and prices. You can buy or sell shares and end up with a profit or loss. But how are these prices formed? How are probabilities calculated, and what are they based on?

Polymarket doesn’t set prices manually. Everything runs on basic supply and demand — users post buy and sell orders, and the prices emerge from that interaction.

When a new market is created, there are no shares yet — no prices, no implied probabilities. The very first prices appear when traders start posting limit orders. As soon as two matching orders appear — one for YES and one for NO — and their prices add up to $1, a match happens. Shares get minted, and those prices become the market’s starting point.

Here’s how that works in practice:

Let’s look at an example with a new market. Alice places a limit order to buy 100 YES shares at 60 cents. Bob places a limit order to buy 50 NO shares at 40 cents. When these orders execute, Alice receives 50 YES shares (paying $30), Bob receives 50 NO shares (paying $20), and the initial market price (which equals the probability) is set at 60 cents for YES and 40 cents for NO.

After that, the market price for the event’s shares is displayed as follows:

• If the spread is less than or equal to $0.10, the market price is shown as the midpoint of the spread — that is, the midpoint between the highest buy order and the lowest sell order.
• In this example, the highest buy price for YES shares is 34 cents, and the lowest sell price is 36 cents. The spread is therefore $0.02, which is less than 10 cents. So, the displayed market probability is 35%.
• If the spread is greater than 10 cents, the market price shown is the price of the last executed trade.

How Orders Get Executed on Polymarket

There are several ways orders get executed on Polymarket. Here are the main types: direct matching, minting, and merging. Let’s go through each one in detail.

1. Direct Match (Normal Scenario)

This is the most straightforward type of match.

Let’s say:

• Alice posts a limit order to buy 100 YES shares at $0.35
• Bob posts a limit order to sell 100 YES shares at $0.35

Since the prices match, the trade is executed.

This is the standard case where one user wants to buy and another is willing to sell at the same price. To fulfill the match, the system performs the following operations.

Here’s what happens:

1. The system takes 100 YES shares from Bob
2. Takes $35 from Alice
3. Sends 100 YES shares to Alice
4. Sends $35 to Bob

Simple one-to-one swap between users. No new shares are created, and no shares are destroyed.

2. Minting (Creating New Shares)

Now let’s say:

• Alice places a buy order for 100 YES shares at $0.35
• Bob places a buy order for 50 NO shares at $0.65

We already saw a similar case back when we talked about initial price formation.

Since their prices add up to $1, this match is valid under the core rule: $1 = 1 YES + 1 NO

Here’s how the system processes it:

1. Takes $17.50 from Alice (50 × $0.35)
2. Takes $32.50 from Bob (50 × $0.65)
3. Mints 50 YES shares and sends them to Alice
4. Mints 50 NO shares and sends them to Bob

So even though Alice requested 100 YES shares, she only receives 50 — because Bob’s order only covers that much. The rest of Alice’s order stays open.

Also, this isn’t a trade between users. No money moves from Alice to Bob or vice versa. The protocol itself receives the funds and issues new shares — that’s why it’s called “minting.”

3. Merge (Burn Shares)

Now let’s look at the reverse of the minting case.

• Alice places a sell order for 100 YES shares at $0.35
• Bob places a sell order for 50 NO shares at $0.65

Just like in the previous scenario, their prices add up to $1 — so the system can match them, this time by removing shares from circulation.

Here’s how the execution works:

1. The system takes 50 YES shares from Alice
2. Takes 50 NO shares from Bob
3. Burns those 100 shares (they’re removed from supply)
4. Sends $17.50 to Alice (50 × $0.35)
5. Sends $32.50 to Bob (50 × $0.65)

Same thing as in previous example:

• Poor Alice only gets part of her order filled — she wanted to sell 100 YES shares, but only 50 were matched. The rest of her order stays in the book.
• Bob’s order is fully executed.

And again, this isn’t a user-to-user trade. There’s no exchange of funds between Alice and Bob. The protocol takes the shares, burns them, and pays out the corresponding dollar amounts to each user directly.

Understanding Order Inversion and the Unified Order Book

Let’s revisit the rule:
$1 = 1 YES + 1 NO

And talk about order inversion: what happens when orders invert—and why.

Say Alice places a buy order for YES shares at 80 cents. That order is inverted to mean she’s selling NO shares at 20 cents. Then Bob comes along ready to buy NO shares at 20 cents. But Alice isn’t actually selling anything—she wants to buy. And NO shares don’t even exist yet.

Because of the rule, these orders can still match since they’re complementary. The system mints YES shares for Alice and NO shares for Bob.

This is how a unified order book works for each event. Even though the interface shows separate tabs for YES and NO, with what looks like separate order books, orders for one outcome actually appear as inverses in the other’s book—and vice versa.

Types of Orders: Market vs. Limit

Let’s quickly run through the types of orders on Polymarket. In the interface, you’ll see two main options for buying or selling: Market and Limit orders.

Limit orders are what we’ve been talking about so far. They’re orders with specific conditions that have to be met for the trade to happen. For example, Alice places a limit order to sell YES shares at 40 cents. That order will only fill if there’s a buyer willing to pay 40 cents per share. Limit orders can also have an expiration time—say, to sell at 40 cents within a day. If the order doesn’t get filled by then, it’s automatically canceled.

Market orders, on the other hand, are instant buys or sells at the current market price (which we’ve already explained how it’s set). But to be clear, a market order is still an order—it just doesn’t have conditions set by the user. Instead, the platform automatically finds the best available price for the number of shares the user wants to trade.

Market Order with Partial Fills Example

Let’s walk through an example using the order book screenshot for TikTok market. What do we see? This is the order book for the YES outcome of the event. The red side shows sell orders, the green side shows buy orders, and the gap between them is the spread. You can also see the last trade price, the number of shares available at each price, and their total value.

Now, say Alice wants to sell 100 YES shares at the market price. At 34 cents, there are only 40.27 shares available to buy. So, Alice will sell 40.27 shares at 34 cents, and the remaining shares will sell at the next best price — 33 cents.

The total Alice will get from selling all 100 shares at market price is:
40.27 × $0.34 + (100 - 40.27) × $0.33 = $33.40.

After the trade, the bid for 40.27 shares at 34 cents disappears since those shares have been bought. The bid at 33 cents decreases by the remaining shares sold (from 292.33 down to 232.6), and the spread widens to 3 cents.

This example also highlights how orders can be partially filled. When you place a market order, it can be split across multiple trades depending on the available shares and sizes in the order book. The system always matches your order at the best possible prices available at that moment.

This covers the basic theory of how Polymarket works. Now, let’s quickly dive into the technical side and see how the system is built.

How Polymarket Works Technically

Let’s quickly run through how the system works from a technical standpoint. As mentioned, the order book is hybrid decentralized — meaning it combines off-chain and on-chain parts. Users create orders off-chain, an operator matches them off-chain, and then triggers their execution via smart contracts.

Creating and Managing Orders

When a user creates an order, they generate a data structure signed with their private key using the EIP-712 standard. Orders stay off-chain until execution, which lets users update or cancel them without needing on-chain transactions.

CTFExchange.sol - Execution Contract

The contract that handles order execution is CTFExchange.sol. It’s divided into several clear sections. Some parts manage user roles, others handle fees (which we haven’t brought up yet to keep things simple—and because fees are currently set to zero. But the fee system is built in, and Polymarket’s docs include the formulas for how fees would be calculated). There’s also a section for signature verification and other functions.

Trading Logic: Assets.sol and Trading.sol

The main trading logic is split between Assets.sol and Trading.sol. Assets.sol defines the assets the exchange deals with, while Trading.sol handles how trades are executed. Simply put, Trading.sol contains the core exchange logic—taking some assets, giving others, running a few checks, and emitting events. Assets.sol just defines which assets are being traded, which is the part we’re most interested in.

What Are the Assets?

First, there’s the familiar USDC — the payment token and the base asset. Then there are the shares users buy and sell. These shares are also tokens, but they follow the ERC1155 standard. The shares are implemented using a framework created by Gnosis called the Conditional Tokens Framework — which is why the exchange contract starts with “CTF.”

Why Use the Conditional Tokens Framework (CTF)?

ERC-1155 is a multi-token standard that allows you to mint many tokens under each tokenId — sort of like fungible tokens inside an NFT. That’s what makes it perfect for prediction markets.

Each tokenId in this setup is calculated in a specific way, which makes it easy to determine winning outcomes later. Within each tokenId, the shares for a specific event outcome are issued.

How tokenIds are calculated:

When a market is created, three parameters need to be defined to uniquely determine the conditions of that market:

1. questionId
   First, the market is defined by a question that will later have a clear answer chosen from a set of options. This question, along with the market details, is stored on IPFS, and a hash is generated — this becomes our questionId.
2. outcomeSlotCount
   Secondly, we need to specify that there are only two possible outcomes—this input is called outcomeSlotCount. Just to clarify, we’re talking about a universal contract developed by Gnosis. Polymarket uses it only for binary cases, so this input is always set to two. However, others can build their own logic and applications on top, allowing for more outcomes. The framework supports up to 256 outcomes.
3. oracle address
   The third input is the oracle address that’s responsible for deciding the outcome. Since we’re dealing with real-world events, we need an oracle to reliably feed accurate info into the blockchain. Polymarket uses the UMA (Universal Market Access) oracle for this. I’ll get into more details about UMA after we finish going through the CTF framework. But for now, just know that from the very beginning, each market is assigned an oracle address — and only that oracle gets to decide the outcome.

From Parameters to conditionId

So, we’ve defined three parameters: the question hash, the number of possible outcomes, and the oracle address. We then input these into keccak256 to generate the conditionId — the hash representing the market’s condition.

Defining collectionIds

Next, we define the collectionIds — one for each possible outcome (e.g., YES shares and NO shares).
This doesn’t mean creating separate NFT collections — it’s just how the system refers to them internally. All shares live within a single ERC-1155 collection deployed by Gnosis

The collectionIds are generated based on the shared conditionId hash from the previous step combined with the indexSet variable, which is unique for each outcome. The indexSet is a 256-bit array that must be a non-empty subset of all possible outcomes. In the binary case, our indexSet input will be either 01 or 10, representing either the first or the second outcome, respectively.

Creating tokenIds (aka positionIds)

After defining the collectionIds for each possible outcome, we create the tokenId. In the documentation, these are called positionIds and depend on the collectionId and the collateralToken address — which in our case is USDC.

How Collateral Works

The collateral token is set during the CTF phase and fully backs the issued shares. You send USDC to the collection contract, which mints shares in return. When the shares are burned, the contract returns the collateral.

Settling the Market

This way, we see that the tokenId for each possible event outcome is calculated using a specific algorithm. So, when it’s time to settle, it’s easy to compute the tokenId of the winning outcome — and the holders of those winning shares can then claim their share of the market’s total pool.

A Final Note on the Oracle Used with CTF

To wrap up, we also need to mention the oracle that works in tandem with the CTF. It’s a decentralized optimistic oracle. Here's a brief explanation of how it functions:

When a market is created via the CTF, it’s assigned a questionId, a defined number of outcomes, and the UMA oracle address as the resolver.

During market creation, a resolve request is sent to the oracle contract—indicating that this specific market will eventually require a resolution.

It’s called optimistic because anyone can call the propose method to suggest an outcome, posting a $750 bond. If no one challenges the proposal within two hours, it’s automatically accepted.

If the proposed result is incorrect or disputed, others in the system can call dispute, also posting a bond. There’s an incentive to challenge if you believe the original proposer is wrong—disputing successfully lets you claim their bond.

Once disputed, the outcome is determined by a vote among UMA tokenholders.

The process is decentralized, but admin functions do exist and can be used if intervention is necessary.

How Settlement Works

Once the final outcome is confirmed by the oracle, a reportPayouts call is sent to the CTF contract. This stores the result on-chain. After that, token holders can call the redeemPositions method. It burns their shares and returns their portion of the collateral.

In practice, this means a shared pool is formed during trading, split between two outcomes—but only the holders of the winning outcome can redeem their share. The losing side gets nothing.

Key Takeaways

What Is Polymarket

• Polymarket is a prediction market protocol for trading outcomes of real-world events.
• Events are structured as binary questions with YES or NO outcomes.
• Users buy shares representing their belief in an outcome.

Market Mechanics

• Each event has YES and NO shares priced between $0 and $1, summing to $1.
• Prices reflect the market’s perceived probability of an outcome.
• When the event is resolved, the correct outcome settles at $1; the incorrect at $0.
• Traders can hold until settlement or exit earlier by selling shares.

Order Book Design

• Polymarket uses a hybrid-decentralized central limit order book (CLOB).
• Orders are matched off-chain, while settlement and execution happen on-chain.
• Every event has a unified order book, with mirrored orders for the opposite outcome.
• The system enforces the rule: 1 YES + 1 NO = $1.

Price Discovery

• Initial prices are formed when buy/sell orders match and shares are minted.
• Market prices are based on the midpoint of buy/sell spreads (if tight) or last trade (if wide).
• Prices and probabilities are entirely determined by user activity — supply and demand.

Order Execution

1. Direct Match: User-to-user trade with no minting or burning.
2. Minting: New shares are created when orders for opposite outcomes match in price.
3. Merging: Existing shares are burned when opposite sell orders match.

Orders Types

• Limit orders specify a price and wait for a match; market orders execute immediately at the best available price.
• Market orders can result in partial fills depending on order book depth.

Order Handling & Matching

• Orders are created and signed off-chain using EIP-712.
• An backend matches orders off-chain.
• Matched orders are executed on-chain via smart contracts.

Execution Contract

• CTFExchange.sol handles on-chain order execution, signature verification, and fee logic (fees currently set to zero).

Trading Logic Contracts

• Assets.sol defines tradable assets (USDC and outcome shares).
• Trading.sol executes trades and emits events.

Assets & Shares

• Shares are ERC-1155 tokens representing outcome positions.
• Implemented using Gnosis’s Conditional Tokens Framework (CTF).
• USDC is used as collateral to mint and redeem shares.

Token Structure via CTF

• Each market is defined by:
  
  • questionId (IPFS hash of the market question)
  • outcomeSlotCount (always 2 on Polymarket)
  • oracle address (UMA’s optimistic oracle)
• These form a conditionId using keccak256.
• Each outcome generates a collectionId via an indexSet.
• Final tokenId (aka positionId) is derived from collectionId + collateralToken.

Collateral Flow

• USDC is deposited to mint shares.
• Shares are burned to redeem USDC after market resolution.
• Only winning outcome token holders receive payouts.

Oracle and Market Resolution

• UMA’s optimistic oracle resolves outcomes.
• Any user can propose a result by posting a bond.
• If unchallenged within 2 hours, it’s accepted.
• Disputes trigger a UMA tokenholder vote.
• Final outcome is posted via reportPayouts.
• Users redeem shares through redeemPositions.
• Losing outcome tokens become worthless.

‍