Inside Polymarket Data: How Trades Work and How to Calculate Volume Correctly

If you are building prediction market analytics, tracking on-chain volume, or aggregating trades at the protocol level, this post is for you.

We recently came across Paradigm’s research showing that several analytics platforms significantly overreported Polymarket trading volume due to flawed data methodology. That prompted us to dig deeper into how Polymarket trades are actually executed on-chain.

In this post, we are going to break down the full trade execution flow, highlight the specific on-chain events that matter for volume accounting, and explain how to calculate trading volume correctly for analytics dashboards.

Make sure to follow us on X to stay updated on our upcoming technical deep dives on protocol design and architecture 🌚

If you want deeper technical context on Polymarket and related topics, start here:

• How Polymarket works
• How resolution works with UMA
• Deep Dive into How to Index Blockchain Data

So, what happens when a trade executes on Polymarket?

When a trade executes on Polymarket, a single taker order is matched against one or more maker orders within a single transaction. The exchange contract routes tokens between participants, performs any required split or merge operations, emits multiple trade-related events, and finalizes position changes.

The exchange itself does not take positions, provide liquidity, or assume counterparty risk. All economic exposure is transferred directly between the taker and the makers involved in the match.

Key roles in a Polymarket trade

• Taker: The participant whose order initiates the trade. The taker consumes liquidity and is the common counterparty across all matches in the transaction.
• Maker: A participant who previously placed a limit order. A single taker trade can match against multiple makers.
• Exchange contract (CTF / NegRisk): A routing contract that facilitates execution, performs split and merge operations when required, and emits events. It is not a trading counterparty.

Polymarket’s execution model is non-trivial. It uses a unified order book for binary markets, supports split and merge mechanics, and allows multi-leg matches that do not behave like conventional spot swaps.

We’ve already covered the architecture, smart contracts, and execution paths in our technical deep dive on how Polymarket works. So we’re not covering most mechanics in this post, we only focus on trade structure elements that matter for interpreting Polymarket data, specifically when computing trading volume from on-chain events.

Polymarket trade structure and execution model

Polymarket trades are executed by the CTFExchange.sol smart contract. The contract does not act as a counterparty. Its role is strictly to route tokens, perform split or merge operations when required, and emit execution events.

Every trade follows the same execution path and event sequence.

Contract Entry and Execution Flow

1. matchOrders() → _matchOrders()

Each trade transaction enters the exchange through matchOrders(), which immediately delegates to the internal _matchOrders() function. At this point:

• The taker is fixed
• The set of matched maker orders is fixed
• No assets have moved yet

There is exactly one taker per transaction and at least one maker.

2. Taker Asset Transfer

Before any matching occurs, the taker’s assets are transferred into the exchange contract.

This transfer is mechanical. The exchange temporarily holds the tokens only to route them during execution. It does not assume risk and does not open a position.

3. Maker Matching Loop: _fillMakerOrders()

The core execution happens inside _fillMakerOrders(), which iterates over each matched maker order.

For each maker, the contract performs the following steps in order:

1. Compute maker-side fees
2. Perform split or merge operations if required
3. Transfer maker assets from the maker to the exchange
4. Transfer taker assets from the exchange to the maker
5. Transfer maker fees from the exchange to the fee collector
6. Emit an OrderFilled event describing this maker’s portion of the trade

This loop executes once per maker. If a taker order matches against multiple makers, these steps repeat for each one.

4. Final Settlement and Aggregate Events

After all makers are processed:

1. Remaining maker-side tokens are transferred from the exchange to the taker
2. Taker-side fees are transferred to the fee collector
3. An aggregate OrderFilled event is emitted
4. A final OrdersMatched event is emitted

The last two events describe the entire set of matches executed in the transaction.

Event Sequence Summary

Every Polymarket trade emits events in the same order:

1. One or more maker-focused OrderFilled events (one per maker)
2. Exactly one aggregate OrderFilled event
3. Exactly one OrdersMatched event

No additional economic activity occurs after this point.

Let’s look how it works on example:

Consider a simple trade with one taker and one maker.

• Alice submits a market order to buy YES shares
• Bob has an existing limit order selling YES shares
• The trade matches Alice and Bob

Step-by-step Polymarket trade execution

1. Alice calls matchOrders()
2. Alice’s USDC is transferred to the exchange
3. _fillMakerOrders() processes Bob’s order:
   
   • Bob’s YES tokens move to the exchange
   • Alice’s USDC moves from the exchange to Bob
   • Fees are computed and transferred
   • An OrderFilled event is emitted with:
     
     • maker = Bob
     • taker = Alice
4. The exchange transfers the purchased YES tokens to Alice
5. An aggregate OrderFilled event is emitted
6. An OrdersMatched event is emitted

At no point does the exchange buy, sell, or hold exposure. The only trade that occurred was between Alice and Bob. The exchange simply routed assets and recorded the execution.

How Many Events Can a Single Polymarket Trade Emit?

While the execution sequence above is deterministic, the number of on-chain events emitted by a single Polymarket trade can be surprisingly large.

Independent on-chain research by Onchain Divers analyzed a Polymarket transaction where a single user spent ~7,400 USDC to acquire ~13,276 outcome shares. That single trade produced 111 log entries in one transaction.

Why Event Counts Grow So Large

A Polymarket trade can fan out into many on-chain actions because:

• One taker order can match against many makers
• Liquidity can be sourced from both sides of the binary market
• The exchange performs conditional token splits and merges
• Each maker fill emits its own OrderFilled event
• Additional ERC-20 and ERC-1155 transfer events are emitted for routing

In this example, a single taker order was filled using 14 distinct liquidity sources, combining:

• direct sellers of the target outcome token, and
• indirect liquidity obtained by matching against the opposite outcome via splits.

All of this happened inside one matchOrders() call.

What This Does Not Mean

A high event count does not mean:

• multiple independent trades occurred,
• the exchange acted as a counterparty,
• or additional economic volume was generated.

It means the exchange aggregated liquidity across many paths to satisfy one taker intent.

Why This Matters for Data Interpretation

This is exactly why Polymarket data is frequently misread:

• One user action → dozens of events
• One economic trade → many representations
• Naive aggregation → inflated volume, fake “wash” signals

Without understanding the execution sequence and event semantics described earlier, a transaction with 100+ logs looks chaotic. In reality, it is a single deterministic match executed with maximum liquidity efficiency.

How to Calculate Polymarket Trading Volume Correctly

To get Polymarket volume right, do not sum all OrderFilled events. Each trade generates multiple OrderFilled records, so adding them doubles the true volume. Instead, measure volume using one consistent method: either one-sided volume (taker or maker) or OrdersMatched. Both approaches are valid, but they must be used consistently and not mixed.

What metrics matter for trading volume in prediction markets

In prediction markets like Polymarket, there are two valid ways to define volume:

• Cash flow volume – USDC transferred between participants.
• Notional volume – the number of contracts traded multiplied by the $1 payout per contract.

Both metrics are correct, but they cannot be mixed or double-counted, because one trade can generate multiple on-chain events.

Two valid measurement approaches

• One-sided volume (Taker-side or Maker-side)
• Volume based on OrdersMatched

Both methods work, but must be used consistently.
Before we dive into the methods, let’s look at a trade example.

Example trade

Before we apply the measurement methods, we need to understand what this trade looks like on-chain.

Here is the transaction we will analyze. Here’s the link to explorer

If you open it, you’ll notice something important: the transaction is not a simple swap.Instead, the trade is executed in two legs.

What does the two legs trade mean?

In Polymarket, a single taker order can match against multiple maker orders and can also combine different execution types (swap + merge).

Let’s break down what happens in this transaction.

Leg 1: Swap

• Taker: sells 3,157.02 YES for $28.41
• Maker: buys 3,157.02 YES for $28.41

Cash flow and contract volume are equal for both sides.

Leg 2: Merge

• Taker: sells 6,842.98 YES for $61.59
• Maker: sells 6,842.98 NO for $6,781.39

Contract volume is equal for both sides, but cash flow differs.

Getting volume using the one-sided methodology

Instead of summing all OrderFilled events, you only count one side of the trade.

• Taker-side volume
  Volume from the perspective of the taker (the trader who initiates the match).
  This reflects the economic activity on the market.
• Maker-side volume
  Volume from the perspective of liquidity providers (makers).
  This reflects liquidity contribution, not market activity.

How this works on our example trade

a) Taker-side volume (cash flow + notional)

Here we count only what the taker did in each leg:

• Swap leg: $28.41, 3,157.02 contracts
• Merge leg: $61.59, 6,842.98 contracts

Total taker-side volume:

• Cash flow: $90.00
• Notional: 10,000 contracts

b) Maker-side volume (cash flow + notional)

Here we count only what the makers did:

• Swap leg: $28.41, 3,157.02 contracts
• Merge leg: $6,781.39, 6,842.98 contracts

Total maker-side volume:

• Cash flow: $6,809.80
• Notional: 10,000 contracts

Getting volume using OrdersMatched

Instead of using OrderFilled events, you measure volume using OrdersMatched, which represents the full economic trade.

Why it works

• There is one OrdersMatched event per trade
• It aggregates all partial fills when the taker matches multiple makers
• It describes the trade, not a set of duplicated events

What OrdersMatched gives you

• taker (the initiator)
• takerAmount (USDC moved by taker)
• contractAmount (number of contracts traded)
• marketId + timestamp

Applying OrdersMatched to the example

OrdersMatched reports:

• Notional volume: 10,000 contracts
• Cash flow volume: $90.00

To wrap up, the key point is that Polymarket volume cannot be calculated by summing OrderFilled events, because a single trade emits multiple OrderFilled records and that leads to double counting. The correct approach is to choose one consistent method—either one-sided volume (taker or maker) or the OrdersMatched event—and apply it using a single volume metric, either cash flow or notional. The example trade shows why this matters: the swap leg has equal cash flow on both sides, while the merge leg produces vastly different cash flow values for maker and taker, so adding both sides together creates an inflated volume number that does not reflect market activity. If you want accurate volume reporting, you must explicitly define what you are measuring and stick to one method throughout your dashboard or analysis.

About Rock'n'Block

Rock’n’Block is a Web3-native development studio specializing in building production-grade blockchain infrastructure, DeFi protocols, and prediction and perpetual markets. We help founders bring high-performance platforms to life, delivering scalable UX and reliable infra.

Follow us on X for more updates, deep dives, and behind-the-scenes on how we build Web3 platforms.

If you’re launching a prediction markets platform, our end-to-end prediction markets development services cover everything from core protocol design to trading terminals, dashboards, and settlement logic—whether building from scratch or on top of existing protocols.

What we do:

• Build custom Layer-1 chains, DeFi protocols, and decentralized exchanges.
• Develop prediction markets end to end, including CTF implementation, CLOB, oracle integration, and settlement logic.
• Create perpetual DEXes with order books, funding rates, margining, liquidations, and oracle integrations.
• Implement blockchain data streaming for real-time and historical market insights.
• Provide chain-agnostic payment solutions and financial tooling for market participants.

With nearly a decade of hands-on blockchain experience, our team has supported products reaching 71M+ DeFi users, $2.5B in market cap, and helped partners raise $167M.

View Portfolio

Key Takeaways:

What happens when a trade executes on Polymarket?

A single taker order is matched against one or more maker orders inside one transaction. The exchange contract routes tokens, performs splits/merges when needed, emits multiple trade events, and finalizes position changes. The exchange itself does not take risk or act as a counterparty.

Who are the key roles in a Polymarket trade?

• Taker: initiates the trade and consumes liquidity
• Maker: provides liquidity via existing limit orders
• Exchange contract (CTF / NegRisk): routes assets, handles split/merge mechanics, and emits events; it does not hold positions

Why do Polymarket trades emit so many events?

One trade can generate dozens or even hundreds of events because:

• a taker can match multiple makers
• liquidity can be sourced from both sides of the market
• split and merge operations create additional token movements
• each maker fill emits its own OrderFilled event

Does a high number of events mean high volume?

No. A high event count does not mean multiple trades or increased economic volume. It simply reflects the routing and liquidity aggregation required to satisfy one taker order.

What is the correct way to calculate Polymarket trading volume?

You must avoid summing all OrderFilled events. One trade emits multiple OrderFilled records, which leads to double counting. Use either:

• One-sided volume (taker or maker)
• OrdersMatched event

Choose one method and one volume metric consistently.

What are the two valid volume metrics for prediction markets?

1. Cash flow volume – USDC transferred between participants
2. Notional volume – number of contracts traded × $1 payout per contract

Both are valid, but they must not be mixed or double-counted.

Why does maker-side volume differ from taker-side volume?

In trades involving splits or merges, the cash flow can differ between taker and maker. This makes summing both sides incorrect for measuring real market activity.

What is the purpose of the OrdersMatched event?

OrdersMatched is the most reliable indicator of the full economic trade because:

• it is emitted once per trade
• it aggregates all partial fills
• it describes the trade rather than individual fills
• it contains key data: taker, takerAmount, contractAmount, marketId, timestamp

What is the difference between swap and merge legs in Polymarket?

• Swap leg: cash flow is equal on both sides
• Merge leg: cash flow differs between maker and taker, but notional volume remains the same

This is why naive event aggregation inflates volume.

What should analytics dashboards measure to report accurate volume?

For correct volume reporting:

• explicitly define what you are measuring (cash flow or notional)
• choose a single method (one-sided or OrdersMatched)
• do not sum OrderFilled events
• avoid mixing maker-side and taker-side metrics

Polymarket data

Polymarket data is the set of on-chain events and transaction records generated by the Polymarket exchange contracts, including OrderFilled and OrdersMatched events, plus token transfer logs.

OrdersMatched event

OrdersMatched is a single on-chain event emitted once per trade. It aggregates all matched maker orders and reports the trade’s taker, takerAmount, contractAmount, marketId, and timestamp.

OrderFilled event

OrderFilled is an on-chain event emitted for each fill in a trade. A single trade emits one OrderFilled event for the taker and one OrderFilled event for each maker involved. Each event records the party’s portion of the trade, including the amount, tokens, and fees for that fill.

Maker and taker volume

Maker volume measures liquidity provider activity based on maker-side fills. Taker volume measures market activity based on the initiating trader’s fills. One trade can generate different cash flow values for maker and taker when splits or merges occur.

Cash flow volume vs notional volume

Cash flow volume is the USDC transferred between participants. Notional volume is the number of contracts traded multiplied by the $1 payout per contract. Both are valid metrics, but they must not be mixed or double-counted.

Where does Polymarket get its data?

Polymarket data comes from on-chain event logs emitted by its exchange contracts (CTF/NegRisk) and from blockchain transaction history. The primary sources are OrderFilled and OrdersMatched events, along with ERC-20 and ERC-1155 transfer events.

How does Polymarket get its data?

Polymarket data is produced by smart contract execution. When a trade runs, the exchange contract routes tokens, performs split/merge operations, and emits trade-related events. Analytics platforms collect these events from the blockchain to reconstruct trades.

‍

‍