Paradigm founder flags Polymarket volume bug in widely used trading datasets

New analysis shared by a leading crypto investor has raised questions about how Polymarket volume is reported across major data platforms.

Paradigm founder highlights data-counting error

On December 9th, Paradigm founder Matt Huang reposted on X a research by on-chain analyst @notnotstorm on social media, drawing attention to a potential trading volume error on the prediction platform Polymarket. According to the research, a bug in the way activity is aggregated leads to publicly disclosed figures that significantly misrepresent actual user activity.

In this Paradigm founder tweet, Huang emphasized that the issue is not limited to Polymarket’s own dashboards. Rather, most external dashboards and analytics tools that rely on the same raw feeds likely inherited the same miscalculation, spreading inaccurate figures across multiple platforms. However, the core problem appears to originate from how trades are being summed and classified in the underlying feeds.

Double-counted Polymarket volume trading activity across public datasets

The research cited by Huang suggests that double counted volume is the root of the discrepancy. In practice, this means that many tools may record both sides of a trade as separate contributions to overall turnover. As a result, what looks like a surge in polymarket trading volume could, in reality, reflect the same transactions being added twice instead of once.

That said, the implications go beyond one specific dashboard. Because multiple public data sources and third party datasets pull from Polymarket’s figures, inaccurate onchain market data may have been propagated across widely followed analytics platforms and community-built dashboards. Moreover, analysts who relied heavily on these feeds for historical comparisons and growth curves could now face the task of revisiting earlier conclusions.

Impact on market metrics and comparisons

One major concern is how this bug may affect interpretations of Polymarket monthly volume and any derived metrics, such as average ticket size or user turnover. If double-counting is systematic, the apparent size of the Polymarket total volume over time may have been materially overstated across many reports. However, the underlying user behavior and market structure remain the same; it is the measurement that requires correction.

The discovery also complicates comparisons like Kalshi vs Polymarket volume or broader trend analyses. Many investors, researchers and media outlets rely on these cross-platform benchmarks to assess traction in the prediction market sector. Moreover, if only one platform’s trades were misreported, previous narratives about relative market share may need to be reconsidered.

Volume data sources and need for recalibration on Polymarket

The original research, amplified by Huang, indicates that popular analytics stacks, including various Polymarket volume Dune dashboards and other custom query environments, may have adopted similar aggregation logic. That said, once the precise Polymarket volume bug is fully documented, it should be possible to rebuild historical time series that correctly reflect single-counted transactions.

For now, market participants are advised to treat any historical polymarket volume figures with caution, especially where they form the basis for valuation models, user growth projections or sector-wide comparisons. Moreover, this episode underscores the importance of scrutinizing how trading volume error definitions and counting methods are implemented in code, rather than assuming that all platforms share the same volume meaning when publishing numbers.

In summary, the research reposted by Matt Huang suggests that a structural counting flaw may have distorted how Polymarket’s activity is reflected across multiple analytics products. While the underlying markets continue to function, the industry will likely need to revise historical datasets and tighten methodologies to ensure that future on-chain trading statistics are both transparent and comparable.