In-Depth Exposé on Polymarket's Underlying Technical Implementation
TechFlow Selected TechFlow Selected
In-Depth Exposé on Polymarket's Underlying Technical Implementation
Polymarket successfully combined technologies from different projects, offering particular value as a reference for later entrants.
Navigating Web3 tides with focused insightsAuthor: Pavel Naydanov
Translation: Golem, Odaily Planet Daily
Editor's Note: Polymarket has gained increased attention during this U.S. election—not only because the cumulative trading volume for prediction topics surpassed $3.6 billion, but also because it successfully and earlier than polls or traditional media predicted Trump’s victory. This has led people to recognize that Polymarket is not merely a betting site, but could evolve into a more authentic and reliable news source (Recommended reading: "Vitalik’s New Article: From Prediction Markets to Information Finance"). Polymarket may well be the most striking highlight of this wave of blockchain innovation.
So, how is Polymarket—hailed as revolutionary in the blockchain space—technically implemented? Pavel Naydanov, a smart contract developer, breaks down and explains in detail the technologies adopted by Polymarket, offering insights particularly valuable for developers. Odaily Planet Daily has translated the technical implementation section below. Now, let’s dive into the technical details of this protocol.
CTF: Tokenizing Outcomes
All event outcomes on Polymarket are tokenized:
-
Such tokens are referred to as Share tokens;
-
Shares are purchased with a base asset, making them fully collateralized;
-
Shares can be sold back to obtain the base asset.
Share tokens are ERC-1155 tokens built on Gnosis' Conditional Token Framework (CTF), a framework proven effective and tested across multiple protocols. CTF supports up to 256 possible outcomes per event.
Each prediction is identified within CTF via a unique condition ID, which is a hash composed of three parameters:
-
Oracle: The address of the oracle that will determine the outcome of the event, ensuring only the designated oracle can settle the prediction;
-
Question ID: A prediction identifier set by the creator. This could be a simple counter incremented with each new prediction, or a more complex scheme using hashes of text and other data;
-
OutcomeSlotCount: The number of possible outcomes for the prediction.
The diagram below visually illustrates how the CTF (Conditional Token Framework) works:
When users place bets, they provide the base asset and receive Share tokens—called conditional tokens in CTF. After the oracle resolves the prediction, users can claim rewards from the CTF based on the outcome.
When users receive conditional tokens, they are considered to have taken a specific position. In CTF, a position represents a combination of possible outcomes for a given prediction. CTF generates these positions for every prediction, with each position corresponding to one of the possible outcome combinations users can choose.
For example:
What will be the highest-grossing movie of 2024?
-
Inside Out 2
-
Mad Max: Fury Road 4
-
Deadpool 3
-
Joker 2
-
Despicable Me 4
-
Dune 2
-
Other
A user might bet that "Inside Out 2" will be the top-grossing film, or that "Dune 2" definitely won’t be. This combination of predictions constitutes their position.
CTF provides two interesting mechanisms for handling positions: split and merge. The split mechanism allows a single position to be divided into individual outcome tokens, while merge combines different outcome tokens into a single position. These mechanisms enable users to manage their positions flexibly.
CTF offers four key advantages to Polymarket:
-
Share tokens confirm a user’s vote on a specific prediction outcome;
-
It enables a flexible system that allows users to combine votes into various positions;
-
Responsibility for calculating results based on oracle signals is delegated to CTF;
-
Rewards are calculated based on the number of Share tokens held for the winning outcome.
It’s also worth noting that CTF allows for structured events where user positions can be merged. However, there are currently no such examples on Polymarket. For more information about CTF, refer to its official documentation.
Order Mechanism
To make purchases, the Polymarket interface offers three types of orders:
-
Market — Immediate purchase at the current market price;
-
Limit — Delayed order allowing users to specify a price at which to buy once reached;
-
AMM — Purchase at an automatically determined price similar to decentralized exchanges, based on pool reserves.
Currently, the AMM order function appears inactive, as no predictions allow purchases via AMM. A comment from a user in Polymarket’s Discord somewhat explains this situation.
AMM is outdated
According to Polymarket’s documentation, AMM was developed as part of the smart contracts under the Conditional Token Framework. Thus, AMM was used to determine the purchase price of Share tokens. This basic mechanism requires liquidity to ensure stable pricing and reduce volatility. Liquidity providers need economic incentives—rewards from each transaction—to keep the system running.
Initially, Polymarket may have been fully based on CTF with AMM determining prices. Over time, however, the protocol developed a hybrid solution featuring an order book, and the other two order types (limit and market) began operating on this custom solution. This solution is known as CLOB (Central Limit Order Book) or BLOB (Binary Limit Order Book).
CLOB and BLOB
CLOB (Central Limit Order Book) or BLOB (Binary Limit Order Book) is a system representing a hybrid decentralized order book. In this system, designated operators handle order matching and initiate execution on smart contracts.
In short, the system works as shown in the diagram below:
Users create orders to execute—either limit or market orders. Operators match these orders and trigger execution on the smart contract. Creating an order means generating a data structure signed with the user’s private key according to the EIP-712 standard. Since orders are stored off-chain before execution, their terms can be quickly and freely adjusted—or even canceled entirely.
However, all aspects related to the order book and order matching are accessible only via API. For convenience, Polymarket provides two clients: one in JavaScript and one in Python.
Nonetheless, the Exchange.sol smart contract is publicly available and handles the creation of user positions within CTF. It also enables management of user positions and asset transfers between them, ensuring security and transparency within the protocol.
The smart contract has been audited, and the audit report is attached in the repository.
Smart Contracts
The Exchange smart contract actually has a more specific name: CTFExchange.sol. It isn't very large—only about 100 lines of code—but it does have numerous dependencies.
Most of these are small smart contracts implementing limited functionality:
-
BaseExchange.sol: An abstract smart contract that implements the ability to receive ERC-1155 tokens and also prevents reentrancy attacks;
-
Auth.sol: A role manager that defines verification functions and modifiers to assign roles—the admin and operator of CTFExchange.sol;
-
Assets.sol: Defines two assets—the base asset (collateral) and the CTF address;
-
Fees.sol: Defines protocol fees;
-
Pausable.sol: Defines the ability to pause smart contract operations, a form of centralization adopted by the protocol in unforeseen circumstances. Accessible only to the admin role;
-
AssetOperation.sol: Defines operations involving the base asset and CTF, including transfer, split, and merge of positions;
-
Signature.sol: Contains code for verifying user signatures when validating orders;
-
Hashing.sol: Defines the hashing of order parameters for signature verification;
-
Registry.sol: Defines the process of registering predictions and their associated tokens within the system.
All logic related to actual order execution is implemented in the Trading.sol smart contract. Reviewing and studying the contract code is straightforward. The structure clearly defines entry points through functions:
-
fillOrder() — Executes an order between the creator of the order and a chosen taker order (another order);
-
fillOrders() — Same as fillOrder(), but processes a list of orders;
-
matchOrders() — The operator selects two different orders and executes them.
All of the above functions can only be called by the operator.
Regardless of how execution enters the smart contract, the result is always the same: two users exchange tokens according to their orders.
Protocol Fees
Fees are charged on the output asset. For binary predictions, fees are symmetric, meaning: if a user sells a token for $0.99, they pay the same fee rate as the buyer purchasing a token for $0.01.
The calculation formula is simple and taken from the official documentation:
Liquidity Rewards Program
The overall goal of the program is to incentivize market liquidity.
For an order-book-based exchange to function effectively, users must create limit orders, which provide the liquidity enabling immediate execution of market orders. Users who create limit orders are known as market makers. The tighter the limit orders are to the market price, the faster market orders execute and the higher the trading volume—clearly beneficial for end users. Additionally, greater liquidity makes market manipulation harder.
To ensure sufficient liquidity, Polymarket has established a special rewards program to encourage users to create limit orders. The closer a limit order is to the average market price, the higher the reward. Rewards are automatically distributed at midnight UTC every day.
The system is modeled after dYdX. For further details, refer to the original dYdX liquidity incentive program and Polymarket’s detailed liquidity reward calculation formula.
Oracle
The oracle is used to provide prediction outcomes—whether an event occurred or not. The oracle is one of the most critical components of the protocol, but it is operated by a third-party service, not the Polymarket team. This oracle is called UMA.
UMA is a decentralized oracle designed to record any type of data on the blockchain, except for data that cannot be verified. The oracle is optimistic, meaning data is assumed correct unless disputed. UMA has its own arbitration system to resolve disputes, with arbitrators being real individuals—participants in the UMA ecosystem, specifically UMA token holders. This system is known as DVM (Data Verification Mechanism).
The following process is used to determine prediction outcomes and record them on the blockchain:
-
Statement: A prediction is added to the oracle along with a reward. Anyone who successfully challenges the outcome can claim the reward;
-
Challenge Period: A window during which anyone can dispute the prediction outcome. If no challenge occurs and the period expires, the outcome is considered ready for final settlement, confirming its accuracy;
-
Dispute: Any protocol participant can dispute the outcome, either to claim the reward or to uphold fairness. In practice, this rarely happens, as game theory suggests most participants act honestly.
-
Voting: If a dispute is initiated, UMA token holders vote to resolve it. UMA is the protocol token used for voting, and participants are rewarded for taking part.
-
Settlement: The final stage is the settlement process, where data is officially recorded on the blockchain. After this, the prediction outcome is considered reliable.
The entire protocol is grounded in game theory, making malicious behavior economically irrational for any participant.
-
Participants submitting outcomes for voting must post collateral to the smart contract. If their outcome is challenged and overturned, they lose their collateral; otherwise, they retrieve it and receive a reward. This creates a strong incentive to submit only accurate outcomes.
-
Participants challenging outcomes also post collateral. If they are correct, they recover their collateral and receive a reward; otherwise, they lose it. This encourages participants to challenge only outcomes they are confident are wrong.
-
Participants resolving disputes must stake UMA tokens and are rewarded for doing so. If they vote incorrectly or fail to vote, they lose part of their stake; otherwise, they earn rewards. There is no room for complacency.
Notably, the voting process in disputes uses a commit/reveal scheme in two stages:
-
Commit: Participants secretly vote by submitting a hash of their vote to the smart contract, meaning no one can discern how they voted just by viewing the hash;
-
Reveal: After the voting period ends, participants reveal their actual votes, and the smart contract verifies whether they match the previously submitted hashes.
This two-stage voting process prevents voter collusion that could undermine the oracle or attack services relying on prediction outcomes. Additionally, prediction outcomes can be challenged multiple times—in such cases, UMA allows restarting the decision process after a previous dispute concludes.
The dispute initiation process is illustrated below:
Conclusion
Polymarket, though appearing to be a simple betting and prediction system, actually integrates three main modules—each developed by different protocols and teams:
-
CTF (Conditional Token Framework): Manages combinations, positions, and Shares within predictions. This flexible framework created by Gnosis is ideally suited for prediction markets.
-
CLOB (Central Limit Order Book): Polymarket’s internal solution for implementing order books and limit orders. CLOB enables users to participate efficiently in the ecosystem and helps aggregate liquidity.
-
UMA: A decentralized oracle with a unique dispute-resolution arbitration system. UMA is the core of the system, transmitting prediction outcomes onto the blockchain.
While Polymarket is fundamentally a betting system, technically it successfully integrates technologies from different projects—an approach particularly appealing to developers.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@hackernoon
