icono_instalar_ios_web icono_instalar_ios_web icono_instalar_android_web

Una mirada detallada a la tecnología detrás de Polymarket

AnálisisHace 3dysreleased 6086cf...
29 0

Artículo original de Pavel Naydanov

Compilado por Odaily Planet Daily Golem ( @web3_golem )

Una mirada detallada a la tecnología detrás de Polymarket

Editors note: Polymarket has received more attention in this US election, not only because the cumulative transaction volume of the prediction theme exceeded 3.6 billion US dollars, but also because it successfully predicted Trumps victory in advance compared with polls and traditional media, making people more aware that Polymarket is not just a betting website, but will become a more authentic and reliable news website (recommended reading: Vitaliks New Article: From Prediction Market to Information Finance ). Polymarket may be the most beautiful landscape in this round of blockchain innovation.

So, how is Polymarket, which has the significance of blockchain revolution, technically implemented? Smart contract developer Pavel Naydanov has made a detailed breakdown and explanation of the technology used by Polymarket, which is of enlightenment significance to developers (especially the rising stars who build prediction markets). Odaily Planet Daily has compiled the part involving technical implementation as follows. Next, lets delve into the technical details of each aspect of the protocol.

CTF: Simbólicoizing Results

All event outcomes on Polymarket are tokenized:

  • Such tokens can be called Share tokens;

  • Shares are purchased with underlying assets, so they are fully collateralized;

  • Shares can be sold to obtain the underlying asset.

Share token is an ERC-1155 implementation based on the Gnosis Conditional Token Framework (CTF) , which has proven its effectiveness and has been tested with multiple protocols. CTF can support up to 256 results per event.

Each prediction is identified in the CTF by assigning a unique condition ID consisting of a hash of three parameters:

  • Oráculo : The address of the oracle that will determine the outcome of the event. This ensures that only the specified oracle can settle the prediction.

  • Question ID : A prediction identifier, set by the creator of the prediction question. This can be a simple counter where each new prediction increments the previous one, or a more complex scheme using hashes of text and other data;

  • outcomeSlotCount : The number of possible outcomes to predict.

The following diagram intuitively shows how CTF (Conditional Token Framework) works:

Una mirada detallada a la tecnología detrás de Polymarket

Users provide the underlying asset when placing a bet and receive a Share token, which is called a conditional token in CTF. After the oracle confirms the prediction, users can claim rewards from CTF based on the prediction results.

When a user receives a conditional token, they are considered to have committed to a specific stance. In CTF, a stance represents a set of possible outcome combinations for each prediction. CTF generates these stances for each prediction, and each stance corresponds to one of the possible outcome combinations that a user can choose.

Por ejemplo:

What will be the highest-grossing movie of 2024?

  • Inside Out 2

  • Deadpool 3

  • Joker 2

  • Despicable Me 4

  • Dune 2

  • Mad Max 4

  • otro

Users can vote that Inside Out 2 will become the highest-grossing film, or that Dune 2 will definiciónnitely not be the highest-grossing film of 2024. This combination of predictions will be considered their stance.

CTF provides two interesting mechanisms for handling positions: split and merge . The split mechanism allows a single position to be split into multiple separate results, while merge combines different results into a single position. These mechanisms allow users to manage their positions flexibly.

CTF provides Polymarket with four important advantages:

  • Share tokens can be used to confirm a user’s vote on a specific prediction result;

  • Implemented a flexible system to combine users votes into various positions;

  • Based on the oracle’s signal, the responsibility for result calculation is delegated to the CTF;

  • Rewards are calculated based on the number of Share tokens of the winning result.

It is also worth mentioning that CTF allows organizing related activities, where users positions can be merged. However, there are currently no such examples on Polymarket. To learn more about CTF, you can get it in the official documentation .

Order mechanism

Una mirada detallada a la tecnología detrás de Polymarket

To make purchases, the Polymarket interface offers three types of orders:

  • Mercado — buy immediately at the current market price;

  • Limit – a delay order, which allows you to specify a price at which the purchase will be made;

  • AMM — Buy at a price automatically determined similar to that on decentralized exchanges, based on the amount of reserves in the pool.

Currently, the AMM order functionality appears to be inactive, with no predictions found that would allow purchases through the AMM. A comment from a user in the Polymarket Discord goes some way to explaining the situation.

Una mirada detallada a la tecnología detrás de Polymarket

AMMs are outdated

According to Polymarket ’s documentation , AMMs are developed as part of the Conditional Token Framework smart contract. Therefore, AMMs are 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 to receive rewards from each purchase to keep the system running.

Probably initially Polymarket was completely based on CTF, using AMM to determine prices. But over time, the protocol developed a hybrid solution with an order book, and two other types of orders (limit and market) started working on this custom solution. This solution is called CLOB (Central Limit Order Book) or BLOB (Binary Limit Order Book).

CLOB and BLOB

A CLOB (Central Limit Order Book) or BLOB (Binary Limit Order Book) is a system that represents a hybrid decentralized order book where dedicated operators handle order matching and initiate the execution of smart contracts.

Without going into too much detail, the system looks like this:

Una mirada detallada a la tecnología detrás de Polymarket

The user creates an order to be executed, which can be a limit order or a market order; the operator matches the users order and initiates execution on the smart contract. Creating an order means creating a data structure signed with the users private key according to the EIP-712 standard. Since orders are stored off-chain before execution, the order terms can be adjusted quickly and free of charge, or even canceled completely.

However, everything related to order books and order matching can only be accessed through the API. For convenience, Polymarket provides two clients: one using JavaScript and one using Pitón .

Sin embargo, the Exchange.sol smart contract is public and is responsible for creating user positions in the CTF. It also allows for the management of user positions and the transfer of assets between them, ensuring security and transparency within the protocol.

Una mirada detallada a la tecnología detrás de Polymarket

The smart contract has been audited and El informe de auditoría is attached to the repository.

Smart Contracts

El Intercambio smart contract actually has a more specific name, CTFExchange.sol . It’s not very large, only about 100 lines of code, but it does have a lot of dependencies.

Una mirada detallada a la tecnología detrás de Polymarket

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 is also responsible for preventing reentrancy attacks;

  • Auth.sol : Role manager, defines authentication functions and modifiers to set roles, admin and operator of CTFExchange.sol;

  • Assets.sol : defines two types of assets, base assets (collateral) and CTF addresses;

  • Fees.sol : defines the protocol fees;

  • Pausable.sol : defines the ability to suspend smart contract operations, a centralized form of protocol agreement in the event of unforeseen circumstances. Only available to the admin role;

  • AssetOperation.sol : defines the operations of the underlying assets and CTF, including position transfer, splitting and merging;

  • Signature.sol : defines the code for the user signature used when verifying an order;

  • Hashing.sol : defines the hash value of order parameters for signature verification;

  • Registry.sol : Defines the process of registering predictions in the system and registering tokens for predictions.

Everything related to the actual execution of an order is implemented in the smart contract Trading.sol . It is also simple to walk through the code and study the smart contract. The structure clearly defines the entry point via a function:

  • fillOrder() — executes an order between the user who created the order and a pending order (another order) selected by the user;

  • fillOrders() — same as fillOrder(), but for a list of orders;

  • matchOrders() — operator selects two different orders and executes them.

All of the above functions can only be called by operator.

Una mirada detallada a la tecnología detrás de Polymarket

Regardless of how the call enters the smart contract, the outcome is always the same: the two users will have exchanged tokens according to their orders.

Agreement Fees

Fees are charged based on the output asset. For binary predictions, the fees are symmetric, meaning: if a user sells a token at $0.99, they will pay the same fee as a buyer who buys the token at $0.01.

The calculation formula is very simple, taken from the official documentation :

Una mirada detallada a la tecnología detrás de Polymarket

Liquidity Rewards Program

The overall goal of the program is to incentivize market liquidity.

For an order book based exchange to work, someone needs to create limit orders. Limit orders provide liquidity that allows for immediate execution of market orders. Users who create limit orders are called market makers. The more close a limit order is to the market price, the faster the market order can be executed and the greater the volume, which is a definite benefit to the end user. In addition, the greater the liquidity, the more difficult it is to manipulate the market.

To ensure sufficient liquidity, Polymarket has developed a special reward program to incentivize users to create limit orders. The closer the limit order is to the average market price, the higher the reward. The reward will be automatically paid at midnight (UTC time) every day.

The system is modeled after dYdX . To learn more, you can check out the original dYdX liquidity incentive plan and Polymarket’s detailedliquidity reward calculation formula .

Oráculo

Oracles are used to provide predictions — whether or not an event will occur. Oracles are one of the most important components of the protocol, but they are served by a third party, not the Polymarket team. This oracle is called UMA .

UMA is a decentralized oracle that is designed to record any type of data on the blockchain, except for data that cannot be verified. The oracle is optimistic, and data is assumed to be correct unless there is a dispute. UMA has its own arbitration system to resolve disputes, and the arbitrators are real people – participants in the UMA ecosystem, specifically UMA token holders. This system is called DVM (Data Verification Mechanism).

The following process is used to determine the prediction results and record them on the blockchain:

Una mirada detallada a la tecnología detrás de Polymarket

  1. Statement : The prediction is added to the oracle along with the reward. Anyone who successfully disputes the prediction result can claim the reward;

  2. Challenge period : During this period, anyone can challenge the forecast results. If no challenge occurs and the time expires, the forecast results are considered ready for final settlement, which indicates its accuracy;

  3. Dispute : Any protocol participant can dispute the result, either to claim rewards or for fairness. In practice, this rarely happens because game theory shows that most participants behave honestly.

  4. 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 voting.

  5. Settlement : The final stage is the settlement process, which is the actual recording of the data on the blockchain. After this, the prediction results can be considered reliable.

The entire protocol is based on game theory, and it is economically disadvantageous for any participant to behave maliciously.

  1. Participants who submit predictions for voting provide collateral to the smart contract. If their results are challenged, they lose their collateral; otherwise, they get their collateral back and receive a reward. This creates a strong incentive to only submit accurate results.

  2. Participants who dispute a prediction also put up collateral. If they are correct, they get their collateral back and receive a reward; otherwise, they lose their collateral. This incentivizes participants to only challenge results that they are confident are wrong.

  3. Participants who resolve disputes. They must stake UMA tokens and will be rewarded for resolving disputes. If they vote incorrectly or not at all, they lose part of their staked balance; otherwise, they receive a reward. There is no way to slack off.

Of particular note is that the voting process in dispute is divided into two phases using a commit/reveal scheme:

  1. Commit : Participants vote secretly by submitting the hash of their vote to the smart contract, which means that no one can tell how a participant voted just by looking at the hash.

  2. Reveal : After the voting phase, participants reveal their votes and the smart contract verifies that they match the previously submitted hashes.

This two-stage voting process prevents voters from colluding to discredit the oracle or attack services that rely on the predicted results. At the same time , the prediction results can be challenged multiple times, in which case UMA allows the decision process to be restarted after the previous dispute is concluded.

The dispute initiation process is as follows:

Una mirada detallada a la tecnología detrás de Polymarket

en conclusión

Polymarket, a seemingly simple betting and prediction system, actually consists of three main modules, each developed by a different protocol and team:

  • CTF (Conditional Token Framework) : Manage portfolios, positions, and shares in predictions. This flexible framework created by Gnosis is well suited for prediction markets.

  • CLOB (Central Limit Order Book) : Polymarket’s in-house solution for implementing order books and limit orders. CLOB enables users to efficiently 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 and transmits prediction results through the blockchain.

Although Polymarket is a staking system, technically the protocol successfully combines technologies from different projects, making it particularly attractive to developers.

Lectura relacionada

Después de las elecciones estadounidenses, ¿cuánto tiempo durará el furor del Polymarket y el mercado de predicciones?

¿Cómo superó Polymarket las encuestas tradicionales en las elecciones generales?

This article is sourced from the internet: A detailed look at the technology behind Polymarket

© Copyright Notice

Related articles