Polymarket Toàn Tập Giải Mã Thuật Toán Cốt Lõi

Original: @MrRyanChi, Founder of @insidersdotbot Prediction Market Trading Platform

Prologue: The Polymarket B-Side You Don't Know

Over the past six months, hundreds of millions of articles about prediction markets have appeared on Twitter.

90% of them talk about how AI programming leads to get-rich-quick stories. This is the "Yuan" (fate/destiny), your first step into this nascent market.

Another 9% cover specific trading strategies, market insights, and smart money strategy analysis. This is the "Dao" (the path), your initial attempt to formulate your own trading strategy and understand how to make money in prediction markets.

However, the "Fa" (the method/law), which is the underlying trading design, PnL calculation, and rules of money flow within prediction markets, although talked about by that 1%, is mostly scattered across some short, concise tweets. These reclusive experts seem unwilling or lack the energy to share their complete methodology with everyone at once.

Therefore, today, with insiders.bot just launched and Polymarket having just completed its v2 update, I want to deconstruct the underlying "Fa" of this market we've been trading in, starting from the most fundamental technology, all at once.

Last October, I wrote a simplified version, giving everyone a rough understanding of Polymarket's core components. This time, I want to truly show you all the technical design details and explain them clearly in layman's terms.

This article encapsulates the hard work of our team over the past eight months.

Over these eight months, the @insidersdotbot team deconstructed all of Polymarket's underlying smart contracts and algorithmic architecture to achieve the fastest trading and the most accurate PnL calculation. This is something only our self-built API can achieve, and no one else has managed to do so until today.

So, I think we might be the most qualified people to deconstruct Polymarket's underlying "Fa."

In this article, I will guide you through how the underlying ctf-exchange-v2 smart contract handles every unit of capital, how the Relayer prepays your Gas for you, and understand how Negative Risk mathematically ensures value conservation.

This is not a simple science article. It is a complete algorithmic deconstruction of Polymarket's underlying mechanisms from a developer's perspective.

Let's start with the basics. That is, when you place an order, what exactly are you sending?

P.S This article has also been adapted for writing style and structure via AI. Feel free to send it to your OpenClaw, Manus, Hermes, or any AI Agent as training material!!!

Chapter 1: From Click to On-Chain, What Actually Happens

1.1 An Order is Not a Transaction, It's an "Intent"

In a traditional decentralized exchange (like Uniswap), when you trade, your wallet pops up a confirmation box, you need to pay Gas fees, and then you send a Transaction to the blockchain's memory pool (Mempool) to wait for miners to include it.

But on Polymarket, when you place an order, your wallet usually prompts a "Sign" request, not a "Transaction" request. Moreover, you don't need to pay any Gas.

This is not just an optimization of user experience; it is a fundamental difference in the underlying architecture.

On Polymarket, an Order is essentially a piece of structured data conforming to the EIP-712 standard. This data contains what you want to do:

• Are you the Maker or the Taker? Which Token (tokenId) do you want to buy?
• How much are you willing to give (makerAmount)?
• How much do you want to receive (takerAmount)?

When you sign it, you are simply stamping this data with your private key, proving "I indeed want to do this." Then, this signed data is sent to Polymarket's centralized server, stored in an off-chain Central Limit Order Book (CLOB).

At this stage, nothing has happened on the blockchain. Your money is still in your wallet, and tokens haven't been transferred. Your order is just a row of data in a database.

1.2 Implicit Expression of Price

Let's pause time at the moment you send the order. If you look closely at the order structure of Polymarket's underlying contract, you'll notice something very counter-intuitive: There is no "Price" field in the order signature data.

How is that possible? How can you trade without a price?

In Polymarket's protocol design, the price is implicit. It is calculated from the quantity you are willing to give and the quantity you want to receive.

If you want to buy 100 YES contracts at a price of $0.60:

• You need to give: $60 pUSD (makerAmount = 60)
• You want to receive: 100 YES contracts (takerAmount = 100)
• Implied Price = makerAmount / takerAmount = 60 / 100 = $0.60

If you want to sell 100 YES contracts at a price of $0.60:

• You need to give: 100 YES contracts (makerAmount = 100)
• You want to receive: $60 pUSD (takerAmount = 60)
• Implied Price = takerAmount / makerAmount = 60 / 100 = $0.60

(Note: Although in the latest V2 SDK, developers can directly pass price and size, the SDK, when signing at the bottom layer, still converts them into makerAmount and takerAmount. The cleverness of this design is that the smart contract doesn't need to understand what "price" means; it just needs to handle the logic of "exchange asset A for asset B." This greatly simplifies on-chain computation logic and reduces Gas consumption.)

1.3 Operator: Polymarket's "Traffic Cop"

Since orders are off-chain, how do they translate into real on-chain asset transfers?

This introduces the core black-box role in Polymarket's architecture: the Operator.

In the ctf-exchange-v2 smart contract, there is a crucial modifier: onlyOperator. This means that only the specific address controlled by the Polymarket team has the authority to call execution functions like matchOrders and fillOrder.

This is completely different from traditional DeFi. On Uniswap, anyone can call the router contract. But on Polymarket, you cannot match orders on-chain yourself. All matching must be submitted by the Operator.

Why this design? To eliminate MEV (Miner Extractable Value) and Front-running.

In a traditional on-chain order book, if someone places a large limit order at a low price, all arbitrage bots will compete in the Mempool (by raising Gas fees) trying to eat that order before others. This leads to skyrocketing Gas fees and a terrible user experience for regular traders.

On Polymarket, all orders are in the off-chain CLOB. The Operator's Matching Engine calculates on the server who should match with whom, packages the result into a single transaction, and sends it on-chain via the Operator.

Because only the Operator can submit matching results, even if bots in the Mempool see this transaction, they cannot front-run it because they don't have permission to call the execution functions.

This is a typical "hybrid decentralized" architecture. Matching and ordering are centralized (decided by the Operator), but settlement and asset custody are decentralized (executed by the smart contract).

The Operator can decide who gets matched first, but it can absolutely never steal your funds because it must provide the EIP-712 data you signed, and the contract will strictly verify the signature.

P.S: However, I should mention this. We at @insidersbot recently seem to have discovered a potential exploit in this mechanism, which could allow copy-trading to front-run, or achieve drastically reduced latency. If there are any updates, we will announce them immediately on our official account.

Chapter 2: The Economics of the Relayer

2.1 The Illusion of "Gasless" Transactions

One of Polymarket's biggest selling points is offering "Gasless Transactions" to users. You only need pUSD to trade; you don't need to buy POL (formerly MATIC) and hold it in your wallet.

But the laws of blockchain physics are immutable: whenever a state change occurs on Polygon (like asset transfer), someone must pay the Gas fee.

Since you didn't pay, who did? The answer is: the Relayer.

2.2 The Relayer's Relay Network

Polymarket doesn't let users send transactions themselves. Instead, it deploys a set of infrastructure called the Relayer Client (relayer-v2.polymarket.com).

In early architectures, such services often relied on enterprise-grade services like OpenZeppelin Defender Relay, using a Signer Pool to resolve nonce conflicts under high concurrency.

When your App creates a transaction (e.g., Approve tokens, Redeem profits), you sign it with your private key and send it to the Relayer. The Relayer acts as a Transaction Sponsor, submitting this transaction to the chain and paying the Gas fee upfront from its own fund pool.

Relayer Architecture & Economic Cycle

2.3 There's No Such Thing as a Free Lunch?

In many early Meta-transaction architectures, after the Relayer prepays Gas, it usually deducts a fee (e.g., 0.3% or a fixed fee of a few dollars) from the user's deposit to cover the Gas cost.

But Polymarket is extremely aggressive: in the current V2 architecture, they genuinely pay the full cost for you.

The official documentation explicitly states: "Polymarket pays gas for all operations routed through the relayer." Whether it's deploying a wallet, approving tokens, splitting (Split), merging (Merge), or redeeming (Redeem), everything is gas-free and incurs no hidden operational fees.

Why is Polymarket willing to make this losing proposition?

Because Gas costs on Polygon are extremely low (usually just a few cents), and the seamless experience offered by gasless trading can attract a massive influx of Web2 users. As long as users generate a tiny Taker fee during their trades (explained later), it's enough to cover this negligible Gas cost.

Knowing this, the next question naturally arises: What impact does this "gasless" architecture have on our trading?

The biggest hidden cost is Latency. Your order must not only pass through Polymarket's matching engine but, for direct on-chain operations, also go through the Relayer's verification, Gas estimation, and queue allocation.

Chapter 3: Three Matching Methods, and Why Can a Buyer Match with a Buyer?

Now we enter the most hardcore and counter-intuitive part of the entire Polymarket architecture.

In a traditional exchange (like Binance's order book), the matching logic is very simple: Alice wants to buy 1 token for $60, Bob wants to sell 1 token for $60. The exchange matches them together, the token goes from Bob to Alice, and money goes from Alice to Bob. End of story.

But on Polymarket (based on the Conditional Token Framework CTF), things are completely different. Because here, tokens can be "printed out of thin air" and "destroyed into nothingness."

When you open the source code of ctf-exchange-v2, you will find three completely different underlying asset settlement paths: COMPLEMENTARY, MINT, and MERGE.

Complementary, Mint, Merge General Structure

3.1 COMPLEMENTARY (Complementary Matching): Traditional Secondary Trading

This is the easiest type of matching to understand and the only type a traditional exchange has.

Scenario: The market has existed for some time, and everyone holds tokens.

• Alice wants to buy 100 YES at $0.60.
• Bob holds YES and wants to sell 100 YES at $0.60.

The Operator finds these two orders (BUY vs SELL), packages them, and submits them on-chain. The smart contract executes a direct peer-to-peer transfer:

1. Transfer 100 YES from Bob's address to Alice.
2. Transfer $60 pUSD from Alice's address to Bob.

This mechanism has the following mathematical and engineering characteristics:

• Zero-Sum Game: The total token supply within the system does not change at all.
• Lowest Gas Consumption: It only involves basic transfers, not the complex operations of CTF.
• Standardized: In a mature, liquid market, the vast majority of daily trades occur this way.

3.2 MINT (Mint Matching): Creating Liquidity Out of Thin Air

This might be the most revolutionary innovation in Polymarket, or even in the entire history of finance.

To explain this better, consider this scenario: A brand new market has just launched, and no one holds any YES or NO tokens.

• Alice is extremely bullish and wants to buy 100 YES at $0.60.
• Bob is extremely bearish and wants to buy 100 NO at $0.40.

Note: They are both buyers! Neither of them has the token the other wants!

In a traditional order book, these two orders would just stare at each other, never able to match. On Polymarket, if