Polymarket Data Integrity: Technical Insights into Volume Calculation
NS
NEXUSSSTUDIO Editorial
Research & Development
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
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.
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.
The core execution happens inside _fillMakerOrders(), which iterates over each matched maker order.
For each maker, the contract performs the following steps in order:
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:
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:
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
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
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:
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.
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.
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.
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 volumeVolume from the perspective of the taker (the trader who initiates the match).This reflects the economic activity on the market.
Maker-side volumeVolume from the perspective of liquidity providers (makers).This reflects liquidity contribution, not market activity.
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
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.
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
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 NEXUSSSTUDIO
NexussStudio 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?
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.
