Worked example · 2025-10

Polymarket filter-bypass manipulation — Polygon — 2025-10

Loss: not quantified in a single dollar figure. The attacker, operating under the pseudonym Cyb3rHawk, executed a sustained campaign of filter-evasive trading on Polymarket that exploited a gap between Polymarket's frontend-side trading restrictions (enforced at the UI/API gateway layer) and the underlying smart-contract-level order execution (which did not enforce the same restrictions). By routing orders directly through the Polymarket CTF (Conditional Token Framework) smart contracts on Polygon using custom calldata, the attacker bypassed the trading filters that Polymarket's frontend and standard API pathways imposed on ordinary users. The campaign was publicly documented by the attacker in a series of self-published analyses in October–November 2025, framing the activity as arbitrage rather than exploitation.
OAK Techniques observed: OAK-T17.001 (Cross-Venue Arbitrage-Driven Price-Discovery Distortion): the attacker's core mechanism — routing orders through the smart-contract layer at prices that diverged from the frontend-enforced order-book — distorted the price-discovery function of Polymarket's markets by introducing a two-tier execution surface where filter-exempt orders (submitted via direct calldata) could execute at prices unavailable to filter-bound users (submitted via frontend/API). OAK-T6 (Defense Evasion at enforcement-filter level): the attacker bypassed Polymarket's trading restrictions by exploiting the architectural gap between frontend-side enforcement (where filters were applied) and smart-contract-level order acceptance (where they were not). This is a clean case of enforcement-filter evasion at the application-boundary layer — distinct from protocol-level access-control bypass (T9.004) or smart-contract reentrancy (T5.002) — because the filters existed and were enforced at one architectural layer but not at the layer that served as the ground-truth order book.
Attribution: pseudonymous — the attacker self-identified as Cyb3rHawk and published detailed technical write-ups documenting the campaign, including specific calldata-construction patterns and filter-evasion techniques. The attacker publicly engaged with Polymarket's team and the broader prediction-market community, framing the activity as legitimate arbitrage between frontend-filtered and smart-contract-native order-execution surfaces. No named-individual attribution. No public OAK-G01 / state-actor attribution.
Key teaching point: frontend-side enforcement without smart-contract-level enforcement creates a two-tier execution surface that structurally advantages filter-evading actors. Polymarket's architecture had trading restrictions (position limits, anti-manipulation filters, rate limits) enforced at the frontend and API gateway layers, while the underlying Polygon CTF smart contracts accepted orders from any caller with valid calldata regardless of whether those orders would have passed the frontend-side filters. Any actor capable of constructing valid calldata — via direct contract interaction, custom tooling, or a private RPC endpoint — could bypass the frontend-side enforcement entirely. The defender lesson is that enforcement at the UI/API layer alone does not constitute enforcement of the market's rules; the smart-contract layer is the ground truth, and any restriction that matters must be enforced at that layer or the architecture creates a structural bypass.

Summary

Polymarket is a Polygon-based decentralised prediction market built on the Gnosis Conditional Token Framework (CTF). Users trade outcome tokens representing binary-event resolutions (e.g., "Will X event occur by date Y?"). Polymarket's standard user flow routes through a web frontend and API gateway that enforce a suite of trading restrictions: position-size limits, anti-manipulation filters, rate-limiting, and compliance checks (including geoblocking and sanctions screening). These restrictions are enforced at the application layer — the frontend validates orders before submitting them, and the API gateway performs its own validation before forwarding order calldata to the on-chain CTF contracts.

In October 2025, the pseudonymous actor Cyb3rHawk publicly documented a campaign in which they bypassed Polymarket's frontend-side trading filters by submitting orders directly to the CTF smart contracts on Polygon via custom-constructed calldata. Because the CTF contracts accepted orders from any caller with correctly-formatted calldata — and did not themselves enforce Polymarket's trading restrictions — Cyb3rHawk was able to execute orders that would have been rejected at the frontend level. The campaign exploited the resulting price-discovery distortion: filter-bound users' orders were constrained to the frontend-enforced order book, while filter-exempt orders (submitted via direct calldata) could execute at prices and sizes that filter-bound users could not access, creating an information-and-execution asymmetry between the two user classes.

The attacker framed the activity as arbitrage between two execution surfaces (frontend-filtered vs. smart-contract-native) and published detailed technical documentation including calldata-construction methodologies, RPC-endpoint selection, and filter-characterisation through iterative probing. The case raises structural questions about the enforceability of application-layer trading restrictions in decentralised-market architectures where the smart-contract layer is permissionless.

For OAK's purposes, the case introduces two distinct technique observations: T17.001 (arbitrage-driven price-discovery distortion via asymmetric execution-surface access) and T6 (enforcement-filter evasion at the application-boundary layer). The case is the first OAK worked example documenting a filter-bypass-via-architectural-gap pattern — distinct from protocol-level access-control bypass (T9.004), smart-contract reentrancy (T5.002), and oracle manipulation (T9.001) — where the enforcement layer and the ground-truth execution layer are not the same architectural component.

Timeline (UTC)

When	Event	OAK ref
Pre-event	Polymarket operates on Polygon CTF smart contracts; trading restrictions enforced at frontend/API layer; CTF contracts accept orders from any caller with valid calldata	T6 surface (latent architectural gap)
Pre-event	Frontend-side filters include position-size limits, anti-manipulation thresholds, rate limiting, compliance checks; no equivalent enforcement at the CTF smart-contract layer	T6 surface (enforcement asymmetry)
2025-10 (campaign onset)	Cyb3rHawk develops custom trading bot / calldata-construction tooling that submits orders directly to CTF contracts bypassing the frontend/API gateway	T6 evasion begins
2025-10 (sustained window)	Cyb3rHawk executes filter-evasive orders across multiple Polymarket markets; exploits price-discovery gap between frontend-filtered order book and smart-contract-native execution surface	T17.001 price-discovery distortion
2025-10 onward	Cyb3rHawk publishes self-documentation on X, GitHub, and personal blog detailing the calldata-construction methodology, RPC-endpoint selection, and filter-characterisation process	(public self-disclosure; transparency signal)
2025-10–2025-11	Polymarket community and external researchers analyse the architectural gap; public debate on whether frontend-side enforcement without on-chain enforcement constitutes a valid market-operations model	(community / industry analysis)
2025-10–2025-11	Cyb3rHawk engages publicly with Polymarket team; frames activity as legitimate arbitrage; no public acknowledgement of remediation by Polymarket as of the date of this example	(engagement without resolution)
Continuing	T6 architectural-gap pattern publicised as a structural vulnerability class for prediction-market and order-book DEX architectures where enforcement is frontend-side only	(cohort signal for future cases)

What defenders observed

Frontend-side enforcement without smart-contract enforcement is structurally bypassable. The core architectural vulnerability is the enforcement-layer asymmetry: Polymarket's trading restrictions were enforced at the frontend/API gateway layer, while the Polygon CTF contracts — the ground-truth execution surface for the market — accepted orders from any caller with valid calldata. Any actor with the technical capability to construct valid calldata directly can bypass the frontend-side enforcement entirely. The defender lesson is that enforcement at the UI/API layer is an operational convenience, not a structural control, for any protocol where the smart-contract layer remains permissionless at the calldata-acceptance level.
The two-tier execution surface creates a structural information and execution asymmetry between user classes. Filter-bound users (routing through frontend/API) trade against a constrained order book; filter-exempt users (routing through direct calldata) trade against the full smart-contract-native order book. The price-discovery function of the market is distorted because filter-bound users' prices reflect only the filtered subset of available execution, while filter-exempt users can execute against the full set. This is a T17.001 distortion pattern that is structurally different from traditional oracle-manipulation or AMM-exploitation cases.
Self-documentation by the actor is a novel transparency signal that does not constitute remediation or mitigation. Cyb3rHawk's public write-ups provide detailed technical documentation of the filter-evasion methodology — useful for defender analysis — but the publication itself neither remediates the architectural gap nor mitigates the distortion for filter-bound users. Defender / compliance teams should treat actor-side self-documentation as an informational input to vulnerability assessment, not as an outcome that resolves the underlying architectural issue.
The architectural-gap pattern generalises beyond Polymarket to any DEX or prediction-market with frontend-side enforcement only. Order-book DEXes, prediction markets, NFT marketplaces, and any protocol that enforces trading restrictions at the application layer while maintaining a permissionless smart-contract acceptance surface are structurally exposed to the same filter-bypass class.

What this example tells contributors writing future Technique pages

T17.001 (Cross-Venue Arbitrage-Driven Price-Discovery Distortion) should include the asymmetric-execution-surface subclass as distinct from cross-venue arbitrage between separate protocols. The Cyb3rHawk case is the canonical worked example: the "venues" are the frontend-filtered order book and the smart-contract-native order book within the same protocol, rather than two distinct protocols (e.g., Binance-vs-Uniswap). The mechanism is the same — arbitrage between two execution surfaces with different constraint sets — but the technique page should distinguish the single-protocol-asymmetric-layer subclass from the cross-protocol-venue subclass.
T6 (Defense Evasion) should have an enforcement-filter-bypass subclass at the application-boundary layer, distinct from protocol-level access-control bypass (T9.004). The Cyb3rHawk case is the canonical worked example for this subclass. The evasion surface is not a smart-contract access-control flaw (the CTF contracts accepted the calldata correctly per their design) but rather an architectural gap between the enforcement layer and the execution layer. This is a distinct T6 surface that the technique classification should capture.
Self-documentation by actors creates a new dimension for attribution and evidence quality. Cyb3rHawk's self-documentation is a transparency-positive signal for the corpus (detailed technical information at zero analytical cost to industry forensics providers) but does not change the pseudonymous attribution status. Contributors should preserve the distinction: self-documentation is an evidence-quality signal, not an attribution-upgrade signal.
The filter-bypass-via-architectural-gap pattern is a cross-cutting Mitigations-layer entry. The Mitigations layer should include a mitigation entry for enforcement-layer-consistency: any trading restriction — position-size limits, anti-manipulation filters, rate limiting, compliance checks — that is enforced at the application layer must also be enforced at the smart-contract layer, or the architecture creates a structural bypass. Polymarket October 2025 is the canonical worked example.

Public references

[cyb3rhawkselfpub2025] — Cyb3rHawk self-published technical write-ups (X threads, GitHub gists, personal blog) documenting the Polymarket filter-evasion methodology, calldata-construction patterns, and RPC-endpoint selection.
[polymarketctfdocs] — Polymarket / Gnosis Conditional Token Framework smart-contract documentation on Polygon — primary reference for the smart-contract-level order-acceptance surface.
[polymarketuifilters2025] — Polymarket frontend and API gateway documentation describing the trading-restriction enforcement layer (position limits, anti-manipulation filters, rate limiting, compliance screening).
[cointelegraphcyb3rhawk2025] — CoinTelegraph / industry press coverage of the Cyb3rHawk Polymarket filter-bypass campaign and the resulting debate on enforcement-layer architecture.
[blockseccyb3rhawk2025] — BlockSec / on-chain forensic commentary on the Cyb3rHawk order-execution patterns and the price-discovery distortion across affected Polymarket markets.
[zachxbtcyb3rhawk2025] — ZachXBT / independent on-chain investigator analysis of the Cyb3rHawk wallet cluster and order-execution timeline.