Author: Pavel Naydanov
Compiled by: Golem, Odaily Planet Daily
Editor's Note: Polymarket has gained more attention in the recent US election, not only because the cumulative trading volume of the prediction topics has exceeded $3.6 billion, but also because it successfully predicted Trump's victory ahead of polls and traditional media, making people more aware that Polymarket is not just a betting website, but will become a more real and reliable news website (recommended reading: "Vitalik's New Article: From Prediction Markets to Information Finance"). Polymarket may be the most brilliant "landscape" in this round of blockchain innovation.
So, how is the "blockchain revolutionary" Polymarket technically implemented? Smart contract developer Pavel Naydanov has made a detailed breakdown and explanation of the technologies used by Polymarket, which may be enlightening for developers. Odaily Planet Daily has compiled the part involving technical implementation, and now let's dive into the technical details of each aspect of the protocol.
CTF: Tokenizing Outcomes
All event outcomes on Polymarket are tokenized:
Such tokens can be called Share tokens;
Shares are purchased with the underlying asset, so they are fully collateralized;
Shares can be sold to obtain the underlying asset.
The Share tokens are implemented using the Gnosis Conditional Token Framework (CTF), an ERC-1155 framework that has proven its effectiveness and has been tested by various protocols, with CTF supporting up to 256 outcomes per event.
Each prediction is identified in the CTF by assigning it a unique condition ID, which is a hash of three parameters:
Oracle: the address of the oracle that will determine the outcome of the event, ensuring that only the specified oracle can settle the prediction;
Question ID: the identifier of the prediction, set by the creator of the prediction question. This can be a simple counter, incrementing the previous prediction question, or a more complex scheme using text and other data hashes;
outcomeSlotCount: the number of possible outcomes for the prediction.
The diagram below illustrates how the CTF (Conditional Token Framework) works:
Users provide the underlying asset when placing a bet and receive Share tokens, referred to as conditional tokens in the CTF. After the oracle determines the outcome, users can claim their rewards from the CTF based on the prediction result.
When users receive the conditional tokens, they are considered to have taken a specific position. In the CTF, a position represents a combination of possible outcomes for each prediction. The CTF generates these positions, each corresponding to a combination of possible outcomes that the user can choose from.
For example:
What will be the highest-grossing movie of 2024?
Inside Out 2
Mad Max 4
Deadpool 3
Joker 2
Despicable Me 4
Dune 2
Other
A user can vote that "Inside Out 2" will be the highest-grossing movie, or that "Dune 2" will absolutely not be the highest-grossing movie of 2024. This combination of predictions will be considered their position.
The CTF provides two interesting mechanisms for handling positions: splitting and merging. The splitting mechanism allows a single position to be divided into multiple separate outcomes, while merging combines different outcomes into a single position. These mechanisms allow users to flexibly manage their positions.
The CTF provides four key advantages for Polymarket:
Share tokens can be used to confirm users' votes on specific prediction outcomes;
It implements a flexible system that aggregates users' votes into various positions;
It delegates the responsibility of outcome calculation to the CTF based on the oracle's signal;
It calculates rewards based on the number of Share tokens of the winning outcome.
Additionally, it's worth mentioning that the CTF allows organizing related activities where users' positions can be merged. However, there are no such examples on Polymarket yet. To learn more about the CTF, you can refer to the official documentation.
Order Mechanism
To make purchases, the Polymarket interface provides three types of orders:
Market - Buy immediately at the current market price;
Limit - A delayed order that allows you to specify the price at which to buy;
AMM - Buy at a price automatically determined similar to a decentralized exchange, based on the reserves in the pool.
Currently, the AMM order functionality seems to be non-functional, as no predictions allowing purchases through AMM have been found. A comment from a user on Polymarket's Discord provides some explanation for this situation.
AMM is outdated
According to Polymarket's documentation, the AMM was developed as part of the smart contract for the Conditional Token Framework. Therefore, the AMM is used to determine the purchase price of the Share tokens. This basic mechanism requires liquidity to ensure stable pricing and reduce volatility. Liquidity providers need economic incentives to earn rewards from each purchase to keep the system running.
It's possible that Polymarket was initially entirely based on the CTF, using the AMM to determine prices. But over time, the protocol developed a hybrid solution with an order book, and the other two types of orders (limit and market) started working on this custom solution.
CLOB and BLOB
CLOB (Central Limit Order Book) or BLOB (Binary Limit Order Book) is a system that represents a hybrid decentralized order book. In this system, dedicated operators are responsible for handling order matching and triggering the execution of smart contracts.
Without going into too much detail, the system is as shown in the following diagram:
Users create the orders they want to execute, which can be limit orders or market orders; the operators match the user orders and initiate the execution on the smart contract, creating an order means creating a data structure signed with the user's private key according to the EIP-712 standard. Since the orders are stored off-chain before execution, the order terms can be quickly and freely adjusted or even completely canceled.
However, all content related to the order book and order matching can only be accessed via the API, and for convenience, Polymarket provides two client-side implementations: one using JavaScript and one using Python.
Nevertheless, the Exchange.sol smart contract is public and responsible for creating user positions in the CTF. It also allows managing user positions and transferring assets between them, ensuring the security and transparency within the protocol.
This smart contract has been audited, and the audit report is attached to the repository.
Smart Contracts
The Exchange smart contract actually has a more specific name, CTFExchange.sol. It is not very large, only about 100 lines of code, but it does have a large number of dependencies.
Most of them are small smart contracts that implement limited functionality:
BaseExchange.sol: An abstract smart contract that implements the ability to receive ERC-1155 tokens and also handles preventing re-entrancy attacks;
Auth.sol: A role manager that defines the verification functions and modifiers to set roles, the admin and operator of CTFExchange.sol;
Assets.sol: Defines two types of assets, the underlying asset (collateral) and the CTF address;
Fees.sol: Defines the protocol fees;
Pausable.sol: Defines the ability to pause the operation of the smart contract, a form of centralization that the protocol agrees to adopt in the event of unforeseen circumstances. Only applicable to the admin role;
AssetOperation.sol: Defines the operations on the underlying asset and the CTF, including the transfer, splitting, and merging of positions;
Signature.sol: Defines the code for verifying the user's signature used for order validation;
Hashing.sol: Defines the hash of the order parameters used for signature verification;
Registry.sol: Defines the process of registering predictions in the system and registering tokens for predictions.
All content related to the actual execution of orders is implemented in the smart contract Trading.sol. Traversing the code and studying the smart contracts is also straightforward. The structure clearly defines the entry points through functions.
fillOrder() — executes an order between the user creating the order and the user whose order (another order) was selected;
fillOrders() — same as fillOrder(), but for 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 the call enters the smart contract, the result is always the same: two users will exchange tokens based on their orders.
Protocol Fees
Fees are charged based on the output asset. For binary predictions, the fees are symmetric, meaning that: if a user sells tokens at $0.99, they will pay the same fee as the buyer who buys tokens at $0.01.
The calculation formula is simple, taken from the official documentation:
Liquidity Incentive Program
The overall goal of this program is to incentivize market liquidity.
For an order book-based exchange to function, there need to be people creating limit orders, which provide the liquidity that allows market orders to be executed immediately. The users who create these limit orders are called market makers. The tighter the limit orders are to the "market price", the faster market orders can be executed, and the higher the trading volume, which is beneficial for the end-user. Additionally, the more liquidity, the harder it is to manipulate the market.
To ensure sufficient liquidity, Polymarket has devised a special incentive program to encourage users to create limit orders. The closer the limit orders are to the average market price, the higher the reward. The rewards will be paid out automatically at midnight UTC every day.
The system is modeled after dYdX, for more information you can refer to the original dYdX liquidity incentive program and Polymarket's detailed liquidity reward calculation formula.
Oracles
Oracles are used to provide prediction outcomes - whether the event occurred or not. Oracles are one of the most critical components of the protocol, but they are provided by a third-party service, not the Polymarket team, and this oracle is called UMA.
UMA is a decentralized oracle specifically designed to record any type of data on the blockchain, except for unverifiable data. The oracle is optimistic, meaning the data is assumed to be correct unless there is a dispute. UMA has its own arbitration system to resolve disputes, with arbitrators being real people - participants in the UMA ecosystem, particularly UMA token holders. This system is called the DVM (Data Verification Mechanism).
The following process is used to determine the prediction outcome and record it on the blockchain:
Statement: The prediction and reward are added to the oracle. Anyone who successfully disputes the prediction outcome can claim the reward;
Challenge period: During this period, anyone can challenge the prediction outcome. If no challenge occurs and the time expires, the prediction outcome is considered ready for final settlement, indicating its accuracy;
Dispute: Any protocol participant can dispute the outcome, whether to claim the reward or for fairness. In reality, this rarely happens, as game theory suggests most participants behave honestly.
Voting: If a dispute is initiated, UMA token holders will vote to resolve the dispute. UMA is the protocol token used for voting, and participants are rewarded for participating in the vote.
Settlement: The final stage is the settlement process, where the data is actually recorded on the blockchain. After this, the prediction outcome can be considered reliable.
The entire protocol is based on game theory, with any malicious behavior being economically disadvantageous for participants.
Participants who submit prediction outcomes for voting provide collateral to the smart contract. If their outcome is challenged, they will lose the collateral; otherwise, they will reclaim the collateral and receive a reward. This creates a strong incentive to only submit accurate outcomes.
Participants who dispute prediction outcomes also provide collateral. If they are correct, they will reclaim the collateral and receive a reward; otherwise, they will lose the collateral. This incentivizes participants to only challenge outcomes they are confident are incorrect.
Participants who resolve disputes must stake UMA tokens and will receive a reward for resolving the dispute. If they vote incorrectly or abstain from voting, they will lose a portion of their staked balance; otherwise, they will receive the reward. There is no way to be negligent.
Notably, the voting process in disputes uses a commit/reveal scheme in two stages:
Commit: Participants secretly vote by submitting the hash of their vote to the smart contract, meaning no one can determine how a participant voted just by looking at the hash.
Reveal: After the voting phase ends, participants reveal their votes, and the smart contract verifies that they match the previously submitted hash.
This two-stage voting process prevents voters from colluding to discredit the oracle or attack services that rely on the prediction outcome. Additionally, prediction outcomes can be challenged multiple times, and in such cases, UMA allows the decision-making process to be restarted after previous disputes are resolved.
The dispute initiation process is as follows:
Conclusion
Polymarket, which appears to be a simple betting and prediction system, actually contains three main modules, each developed by different protocols and teams:
CTF (Conditional Token Framework): Manages the positions, shares, and portfolios in the predictions, a flexible framework created by Gnosis that is well-suited for prediction markets.
CLOB (Centralized Limit Order Book): Polymarket's internal solution for implementing the order book and limit orders. The CLOB allows users to effectively participate 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 through the blockchain.
While Polymarket is a betting system, from a technical standpoint, the protocol successfully combines technologies from different projects, making it particularly appealing to developers.
