Reading Polymarket Trade Events Without Counting Volume Twice

Building a Polymarket volume dashboard requires more than adding up trade events. The key task is to identify which logs describe distinct trades and which describe the same activity from another participant’s perspective.

In an analysis published on December 9, 2025, at 02:34 UTC+8, Paradigm reported that most Polymarket analyses and dashboards were double-counting volume by summing every OrderFilled event. Its explanation connects the exchange contracts’ execution flow to the accounting choices an indexer—a tool that collects and organizes blockchain data—must make.

Disclosure: Paradigm is an investor in Kalshi, a Polymarket competitor. The analysis concerns raw trading-volume measurement, not wash trading or other classifications of activity.

One trade, two sets of fill events

According to Paradigm, Polymarket trade transactions on Polygon contain at most one group of matched orders. Each group has one taker—the participant whose order is matched against existing orders—and at least one maker supplying those orders.

The contracts emit two kinds of trade events: OrderFilled and OrdersMatched. The sequence is important:

1. Maker-focused fills: One OrderFilled event is emitted for each maker. Its taker field identifies the overall transaction taker, and neither participant field identifies an exchange contract.
2. A taker-focused fill: One additional OrderFilled summarizes the overall taker’s fills. Counterintuitively, its maker field identifies that taker, while its taker field identifies the exchange contract.
3. A matching summary: One OrdersMatched event records the same makerAmountFilled and takerAmountFilled values as the taker-focused fill.

The second step does not represent an additional trade with the exchange. It summarizes activity already represented by the maker-focused events. Paradigm illustrates the consequence with a simple sale of YES tokens for $4.13: summing both sides records $8.26 instead.

The events themselves are not incorrect. The accounting error arises when an application treats overlapping representations as separate economic activity.

Why the contract appears on both sides of transfers

Paradigm traces this behavior through the CTF and NegRisk CTF exchange contracts, which use the same event-emitting code described in the analysis.

Execution enters through matchOrders(), which calls _matchOrders(). The exchange receives the taker’s tokens, processes maker orders, performs any necessary split or merge operations, transfers tokens and fees, and emits the fill records and matching summary.

In this flow, the exchange acts as a router: it sends or receives each token transfer, but does not supply funds, take a position or become the economic counterparty. The trades remain between the taker and the makers.

That distinction explains why a transfer involving the exchange address is not, by itself, evidence of another trade to count.

Splits and merges make cash-flow accounting harder

Not every match is a conventional swap of tokens for USDC. Polymarket uses complementary YES and NO tokens, with two operations linking them to their backing:

• Split: Exchange $1 for one YES token and one NO token.
• Merge: Exchange one YES token and one NO token for $1.

A split can match two participants buying opposite outcomes. A merge can match two participants selling opposite outcomes. Splits increase open interest—the outstanding positions in the market—while merges decrease it. Ordinary swaps leave open interest unchanged.

These operations also explain why the maker and taker can have different dollar cash flows in the same match.

In Paradigm’s worked example, a taker sold YES shares through two legs:

Leg	Taker activity	Maker activity
Swap	Sold 3,157.02 YES tokens for $28.41	Bought those tokens for $28.41
Merge	Supplied 6,842.98 YES tokens and received $61.59	Supplied 6,842.98 NO tokens and received $6,781.39

Summing all OrderFilled events produces 20,000 contracts and $6,899.80 in reported USDC volume. That adds the maker and taker representations together. The unequal cash flows in the merge leg do not make that combined total a valid one-sided volume measure.

Choose a metric before aggregating

Paradigm distinguishes two categories:

• Notional volume: The number of contracts traded, counted once, including contracts split or merged.
• Cash-flow volume: The dollar amount exchanged at execution.

For ordinary swaps, the maker and taker have the same cash-flow volume. For splits and merges, an analyst can use maker-side cash flow, taker-side cash flow, their average or another measure such as share-priced volume. These choices can differ materially for an individual trade.

In the historical aggregates examined by Paradigm, however, the measures produced similar totals over days or months—roughly half the sum of all OrderFilled events. That aggregate relationship should not be mistaken for equal maker and taker cash flows in every transaction.

Filtering the event stream

The analysis gives a concrete way to separate the two representations using the taker field of OrderFilled:

• Taker-side records: Keep events where taker equals either exchange address below.
• Maker-side records: Keep events where taker equals neither exchange address.

The exchange addresses identified in the source are:

• CTF: 0x4bfb41d5b3570defd03c39a9a4d8de6bd8b8982e
• NegRisk: 0xc5d563a36ae78145c45a50134d48a1215220f80a

This filtering separates the records; the selected volume metric still determines how their asset IDs and filled amounts should be interpreted.

At publication, Paradigm said DefiLlama, Allium, Blockworks and others were updating their dashboards to remove double-counting. For builders, the underlying lesson is narrower and reusable: trace what each event represents in contract execution before treating it as an independent unit of economic activity.

Original article: Polymarket Volume Is Being Double-Counted — Paradigm