Polymarket底层算法全解

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

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

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

90% of them talk about how AI writing programs bring get-rich-quick stories. This is the "fate" (Yuan), your first step into this nascent market.

Another 9% cover specific trading strategies, market sharing, and analysis of smart money strategies. This is the "way" (Dao), your first step towards developing your own trading strategy and understanding how to make money in the prediction market.

However, the "method" (Fa)—the underlying trading design, PnL calculation, and rules of money flow within the prediction market—although discussed by that 1%, is mostly scattered across short, concise tweets. These reclusive masters never seem willing or lack the energy to share their complete method with everyone at once.

So, today, with insiders.bot just launched and Polymarket having completed its v2 update, I want to deconstruct the underlying "method" of this market we've been trading from the most fundamental technical level.

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 in plain language.

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

During these eight months, the @insidersdotbot team has deconstructed all of Polymarket's underlying smart contracts and algorithmic architecture to achieve the fastest trading and most precise PnL calculation. Only our own API can achieve this; no one else has done it until today.

So, I think we might indeed be the ones best suited to deconstruct the underlying "method" of Polymarket.

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

This is not a simple introductory piece. It is a complete algorithmic breakdown of Polymarket's underlying mechanisms from a developer's perspective.

Let's start with the basics: What exactly are you sending when you place an order?

P.S. This article has also been adapted for style and structure with 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 Orders Are Not Transactions; They Are "Intentions"

On a traditional decentralized exchange (like Uniswap), when you trade, your wallet prompts a confirmation box. You need to pay Gas fees and send a transaction to the blockchain's mempool to wait for miners to include it.

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

This is not just a UX optimization; it's a fundamental difference in the underlying architecture.

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

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

When you sign, you are simply using your private key to stamp this data, proving "I really want to do this." Then, this signed data is sent to Polymarket's centralized server and stored in an off-chain central limit order book (CLOB).

At this stage, nothing happens on the blockchain. Your money is still in your wallet, tokens haven't moved. Your order is just a database entry.

1.2 Implicit Price Expression

Let's pause time at the moment you send this order. If you examine the order structure of Polymarket's underlying contracts closely, you'll find something very counterintuitive: The order signature data does not contain a "Price" field.

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 amount you are willing to give up and the amount you want to receive.

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

• You give up: $60 pUSD (makerAmount = 60)
• You want to receive: 100 YES contracts (takerAmount = 100)
• Implicit price = makerAmount / takerAmount = 60 / 100 = $0.60

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

• You give up: 100 YES contracts (makerAmount = 100)
• You want to receive: $60 pUSD (takerAmount = 60)
• Implicit price = takerAmount / makerAmount = 60 / 100 = $0.60

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

1.3 Operator: Polymarket's "Traffic Cop"

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

This brings us to 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 only the specific address controlled by Polymarket 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 trades on-chain yourself. All matching must be submitted by the Operator.

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

On a traditional on-chain order book, if someone places a large order at a low price, all arbitrage bots compete in the mempool (by raising Gas fees) to be the first to fill that order, leading to skyrocketing Gas and a terrible user experience.

On Polymarket, all orders are in the off-chain CLOB. The Operator's matching engine calculates who should trade with whom on the server, packages the results into a single transaction, and sends it on-chain.

Because only the Operator can submit matching results, even if bots in the mempool see this transaction, they cannot front-run it because they lack the 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 custody are decentralized (executed by the smart contract).

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

P.S: However, I should mention that we @insidersdotbot recently seem to have found a potential exploit in this mechanism that could allow copy-traders to front-run or achieve significantly reduced latency. If there are any updates, we will announce them on our official account immediately.

Chapter 2: The Economics of the Relayer

2.1 The "Gas-Free" Illusion

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

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

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

2.2 The Relayer Relay Network

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

In earlier architectures, such services often relied on enterprise-grade services like OpenZeppelin Defender Relay, maintaining 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 and send it to the Relayer. The Relayer acts as the "Transaction Sponsor," submits the transaction to the chain, and uses its own fund pool to prepay the Gas for you.

Relayer Architecture and Economic Cycle

2.3 You Get What You Pay For? Or Not?

In many early meta-transaction architectures, after the Relayer prepaid Gas, it would usually deduct a fee (e.g., 0.3% or a fixed 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 entire cost for you.

The official documentation clearly states: "Polymarket pays gas for all operations routed through the relayer." Whether it's deploying a wallet, approving tokens, splitting, merging, or redeeming, all are gas-free with no hidden operational fees.

Why is Polymarket willing to do this seemingly unprofitable thing?

Because Gas costs on Polygon are extremely low (usually just a few cents), and the seamless experience of being gas-free 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 these minimal Gas costs.

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

The biggest hidden cost is latency. Your order doesn't just go through Polymarket's matching engine; for direct on-chain operations, it also goes through Relayer validation, Gas estimation, and queue allocation.

Chapter 3: Three Matching Methods, and How Can Buyers Trade with Buyers?

Now we enter the most hardcore, counterintuitive part of the entire Polymarket architecture.

On a traditional exchange (like Binance's order book), matching logic is simple: Alice wants to buy 1 token for $60, Bob wants to sell 1 token for $60. The exchange matches them. The token goes from Bob to Alice, and the 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 "minted out of thin air" and "burned into nothingness."

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

General Structure of Complementary, Mint, and Merge

3.1 COMPLEMENTARY: Traditional Second-Hand Trading

This is the easiest matching method to understand and the only method traditional exchanges have.

Scenario: The market has existed for a while, and everyone holds chips.

• 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 of the system remains unchanged.
• Lowest Gas Consumption: Only basic transfers are involved, no complex CTF operations.
• Standardized: In a mature, liquid market, this is how the vast majority of daily trades occur.

3.2 MINT: Creating Liquidity Out of Thin Air

This might be the most revolutionary innovation in Polymarket, and perhaps in the entire history of finance.

To explain 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 has the token the other wants!

On a traditional order book, these two orders can only stare at each other, never to be filled. On Polymarket, if encountering BUY vs BUY (with complementary tokens), the Operator matches these two orders together!

1. The smart contract deducts $60 pUSD from Alice's account.
2. The smart contract deducts $40 pUSD from Bob's account.
3. The smart contract takes this $100 pUSD, locks it as collateral, then calls the _mint function