The Ghosts of Polymarket: When Off-Chain Matches Meet On-Chain Reverts Yiming Shen1,2 , Yuhan Jin2 , Shuohan Wu2 , Yanlin Wang1 , Jiachi Chen2
arXiv:2606.16852v1 [cs.CR] 15 Jun 2026
1
Sun Yat-sen University
Abstract—Polymarket has emerged as a prominent prediction market platform and one of the fastest-growing applications in DeFi. To achieve low-latency trading, it adopts a hybrid architecture that matches orders off-chain but settles them onchain for final execution. This design creates a consistency gap we call Ghost Fills: an order that is successfully matched offchain may later fail during on-chain settlement. To understand the security implications of this gap, we investigate such failed settlements by building G HOST H UNTER, which reconstructs them from on-chain traces and attributes to concrete attack patterns. Across 1,952,440 reverted match-order transactions, we find that attackers exploit the time gap between matching and settlement to invalidate already matched orders before they are finalized on-chain. We then identify four attack vectors from these incidents: nonce bump, balance drain, allowance revoke, and proxy trap, realized via 35 evolving variants. These vectors allow attackers to selectively revert 980,133 filled orders, enabling risk-free prediction, arbitrage-bot hunting, and liquidity reward manipulation, realizing at least $1.49M in profit, which places $1.78 B USD at risk and 2.17 M POL (about $212 K) paid by operator. During peak hours, more than 24.3% of all filled orders reverted, causing de facto DoS attacks. We also find that code derived from the flawed contract still appears in 167 independent contracts across 10 chains holding at least $23 M in user funds, extending the impact beyond Polymarket. We have disclosed our evidence to affected parties, and the issue has been partially mitigated.
2
Zhejiang University
However, this architecture with split execution leaves a critical window between off-chain matching and on-chain settlement: an order can appear filled off-chain while its corresponding settlement transaction has not, or may never be finalized at all. Users, AI agents [58], and trading bots [31] observing the fill through Polymarket’s UI or CLOB API [43] may treat it as a completed trade, even though the on-chain transaction remains pending and may still revert. Acting on such a fill leaves them exposed to adverse price movements in the interval. We refer to this phenomenon as Ghost Fills. This failure is especially damaging in prediction markets that host many short-cycle contracts (e.g., 5-min BTC price prediction [35]), where the value of a fill can shift within seconds as external information arrives. A Ghost Fill is therefore not merely a failed transaction; it shifts the risk of delayed settlement onto the party that trusted the reported fill. This emergence of Ghost Fills raises questions: are they merely isolated order failures? Do they expose a structural vulnerability in the boundary between off-chain matching and on-chain settlement? Moreover, given the open-source nature of blockchain, new projects often inherit or fork existing code (i.e., contract reuse) [55]; does such reuse propagate the vulnerability to a broader ecosystem? To understand the broader risks they reveal, we focus on three research questions:
1. Introduction
RQ1. How prevalent and costly are Ghost Fills? RQ2. How do attackers exploit Ghost Fills? • RQ3. How far do Ghost Fill risks spread through contract reuse?
Over the past few years, Polymarket [44] has emerged as a breakout Web3 application, attracting broad public attention by allowing users to trade on the outcomes of real-world events. More broadly, it illustrates the potential of Web3 to move beyond token-centric speculation and support concrete, user-facing applications. By the time of writing, Polymarket had grown to more than $450M in total value locked (TVL), over 100K daily active addresses [13], and roughly 1.9M filled orders per day [10]. To sustain this volume while keeping low-latency trading, Polymarket adopts a hybrid architecture that maintains an off-chain central limit order book (CLOB) for fast matching and uses on-chain settlement on Polygon for final execution [43]. Through this split execution model, Polymarket preserves the trust guarantees of decentralized settlement while achieving the performance of conventional Web services.
To answer these questions, we build G HOST H UNTER, a trace-based measurement pipeline for Ghost Fills. It first collects reverted matchOrders transactions from Polygon [34] and maps each on-chain failure surface. We then classify Ghost Fills on them to measure their prevalence, cost, and affected markets. To understand why these failures occur, G HOST H UNTER further performs causal failure analysis by examining the on-chain evidence associated with each failure surface. This analysis separates incidental failures from deliberate cancellations and uncovers four attack types with 35 variants that exploit this settlement window for profit. Finally, to assess whether the same risk extends beyond Polymarket, G HOST H UNTER scans verified contracts across 401 chains that reuse Polymarket-like exchange designs. We have the following major findings: • RQ1: Ghost Fills are widespread and costly. From 202508-15 to 2026-05-06, GhostHunter identifies 1,952,440 re-
• •
verted matchOrders transactions involving 233,887 distinct participants. Their daily rate rose sharply in early 2026 and peaked at 8.5% of all settlements. These failures are dominated by empty collateral balances and rejected tokendelivery callbacks and affect fills involving $1.78 B of collateral while burning 2.35 M POL in operator gas. This shows that Ghost Fills are not isolated anomalies but a costly failure mode of Polymarket’s hybrid settlement design. • RQ2: Attackers exploit four evolving vectors. G HOST H UNTER attributes 980,133 of the 1,952,440 Ghost Fills (50.2%) to attacks spanning nonce bump, balance drain, allowance revoke, and proxy trap. These attacks involve 35 implementation variants, reflecting an active catand-mouse cycle against Polymarket’s patches and monitoring. Together, they place $1.44 B of collateral at risk and burn 2.17 M POL in operator gas ($212 K), accounting for 92% of all gas burned by reverts. At their May 4 peak, they drove the hourly revert rate over 24.3%, creating a de facto denial of service. • RQ3: Ghost Fill risk has spread across chains. After scanning 30,650,071 Sourcify-verified contracts, G HOST H UNTER finds 167 independent polymarket-like deployments across 10 chains, including 71 byte-identical function copies holding at least $23 M in user funds. We further confirm Ghost Fills on the two largest live deployments. However, Code reuse does not always make exploitation: the same settlement gap remains largely harmless in NFT trading, but becomes profitable in prediction markets where a reported fill is worth voiding. We further analyze how these attacks operate in practice. Attackers exploit the Ghost Fill window not merely to cancel trades, but to enable risk-free prediction, arbitrage-bot hunting, and liquidity-reward [40] manipulation. We estimate their realized profit at $1.49 M, and the true amount is likely higher because some companion addresses cannot be linked with confidence. These activities are concentrated among a small number of adversaries acting at scale. They use Sybil strategies to mass-produce disposable wallets and launder the funds used to pay gas, weakening per-account blacklisting. We reported our evidence to Polymarket through three rounds of responsible disclosure. Polymarket has already shipped mitigations [38], [42]. However, these mitigations remain constrained by the timing gap in the hybrid architecture: an off-chain fill remains provisional until its on-chain settlement succeeds. As of this writing, Ghost Fills persist on Polymarket. This paper makes three contributions: We reveal Ghost Fills as a security failure mode in hybrid prediction markets and show how attackers deliberately induce them through Cancellation Attacks, across four attack vectors: nonce bumping, balance draining, allowance revocation, and proxy traps. • We build G HOST H UNTER , a trace-based analysis engine that measures the prevalence, cost, timing, affected markets, and attacker behavior behind Ghost Fills. With G HOST H UNTER we attribute 980,133 reverts to Cancellation Attacks, catalog 35 implementation variants •
across the four vectors, and quantify their impact on Polymarket users and settlement operators. • We show that Ghost Fill risk spreads through contract reuse, finding 167 reused contracts across 10 chains. We responsibly disclosed our evidence to the affected third parties, and we release the artifacts needed to reproduce our measurements: https://github. com/shenyimings/ghost-hunter.
2. Background 2.1. Prediction Markets A prediction market lets participants trade contracts whose payoff is tied to a future event, so that a contract’s live price reads as the crowd’s implied probability of that event [56]. Polymarket pioneered this design at Web3 scale and remains the largest venue of its kind [13]. Like any liquid exchange, it sustains an ecosystem of specialized actors around the order flow [22]: retail traders take directional positions, market makers quote both sides, and arbitrage bots keep related contracts consistent. All of them act on the same public feed of reported fills. A fill that is reported but never settles, therefore harms not only its counterparty but every actor that already traded on it.
2.2. Polymarket Design Hybrid architecture and order lifecycle. Polymarket splits a trade across two layers. Matching occurs off-chain in a central limit order book (CLOB) [43], while settlement occurs on-chain on Polygon [34]. A user signs an order off-chain and submits it to the CLOB, which checks the signature, balance, and allowance before listing the order. When the crossing orders arrive, the CLOB matches them, reports the fill to both sides immediately [45], and queues the match for settlement. A Polymarket-operated account, the operator, then submits an on-chain matchOrders transaction to the Exchange contract, which verifies the signatures and transfers collateral and outcome tokens [36]. Settlement is atomic: either the whole trade commits, or the transaction reverts and on-chain state is unchanged [45]. Outcome tokens. The asset transferred at settlement is an outcome token, minted by the Conditional Tokens Framework (CTF) [36] as an ERC1155 token on Polygon [17]. A binary market has two (Y ES andN O), and the winning token redeems one-for-one against collateral once the event resolves through the UMA optimistic oracle [15]. Markets with more than two mutually exclusive outcomes (i.e., NegRisk) settle through a separate NegRisk CTF Exchange contract [36], which our measurement also covers. Accounts and order signing. Polymarket is noncustodial: a user’s funds stay in an account the user controls, whether a plain EOA or a smart-contract wallet such as a Polymarket proxy or a Gnosis Safe [19], and never in Polymarket’s hands. The protocol separates two roles that
the contract tracks independently. The maker is the wallet that owns the collateral and outcome tokens backing an order; the signer is the key that signs it, which may be the maker itself or a delegate authorized to act for it.
2.3. On-Chain Settlement on Polygon Transactions, contracts, and gas. Polymarket settles on Polygon PoS, an EVM blockchain that orders transactions into blocks roughly every two seconds [33]. A transaction invokes a smart contract function all within one atomic unit: if any step reverts, the whole transaction rolls back and no state change persists [61]. Every step also costs gas, paid in the network token POL by whoever sends the transaction [3]. For Polymarket Exchange, that sender is always the official operator, so the operator bears the gas cost of a settlement even when the transaction reverts. Transaction ordering. Unlike Ethereum [3], where transactions usually route through private channels (i.e., PBS [16]), Polygon PoS exposes a public mempool in which a pending transaction is visible to anyone before inclusion [50]. Validators order pending transactions largely by the gas fee each offers, so a party that wants its transaction to land ahead of another’s can simply bid a higher fee [6]. Settlement requirements. When matchOrders executes on-chain, it re-checks four conditions against current state: 1) the order’s nonce must still match the maker’s current nonce, advanced by an public incrementNonce() call, that invalidates all of the maker’s orders at once (V1 only); 2) the maker must still hold enough collateral or outcome tokens to deliver; 3) the allowance the maker granted the Exchange must still cover the transfer; and 4) the recipient of each ERC1155 transfer must accept the delivery callback [36].
2.4. Ghost Fill Exploits: A Motivating Example The settlement gap described in Section 2.2 is not only a structural failure mode but also an opportunity for abuse. An attacker can deliberately mutate its own on-chain state inside the matching-to-settlement window to force the settlement to revert, thereby manufacturing a Ghost Fill for profit. We call this behavior a Cancellation Attack. Figure 1 shows the attack on a 5-min Bitcoin market [35]. The attacker signs an order in the last few seconds, betting that BTC will close Up, and lets the CLOB match it against a counterparty, while the operator’s matchOrders settlement remains pending in the mempool. Once the window closes with BTC Down, the signed order has become a losing leg 1 . The attacker then front-runs the pending settlement with a high-gas incrementNonce() call. Because this call advances its nonce, the stale order now fails the onchain nonce check and matchOrders reverts. The attacker thus secures a risk-free prediction at the expense of the counterparty end-window trader or market-making bot. 1. A leg is one of the orders that compose a matched trade; a losing leg here is such an order whose predicted outcome turns out to be wrong.
Market: Bitcoin Up or Down 5 minutes Rule: This market will resolve to Up if BTC price in 5 min is greater than or equal to the beginning. Otherwise, it will resolve to Down On-chain CTF Exchange
Off-chain CLOB
Attacker signs Up order (maker)
t1
CLOB matches taker bot fill conformed off-chain ¥ t2 Operator initiates settlement BTC outcome revealed: Down
Attacker broadcasts incrementNonce() tx with high gas W
Attacker: not yet bump nonce = N (valid)
matchOrders() transaction pending on mempool
t3 t4
t5
Operator clears all involving t6 pending orders
incrementNonce() tx front-run nonce = N + 1
matchOrders: nonce N already consumed revert⇒ Ghost Fill q
Net effect: attacker’s losing leg is voided on-chain, securing risk-free prediction, at the expense of end-window trader/market-making bot.
Figure 1. An example of Ghost Fill exploits: In a 5-minute BTC price prediction market, an attacker exploits the time gap between the outcome of prediction and on-chain settlement by front-running a high gas incrementNonce() transaction to secure risk-free prediction.
Definitions: A Ghost Fill is a user-side phenomenon: CLOB reports an off-chain fill to both sides, but the on-chain settlement transaction reverts, leaving no actual transfers; A Cancellation Attack is an attackerside behavior: a deliberate action taken after the offchain match and before settlement that invalidates the matched order so its settlement is forced to revert.
3. Threat Model A trade in Polymarket involves several roles. The maker (M ) owns the collateral or outcome tokens that back an order. The signer (S ) signs the order—either the maker itself or a delegate key acting on its behalf. The operator (O) is the Polymarket-controlled account that submits the on-chain matchOrders transaction once the off-chain order book reports a match; Polymarket runs several operator accounts in parallel to sustain throughput. The attacker (A) is an ordinary market participant who controls one or more funded accounts-either externally owned accounts (EOAs) or contract accounts (CAs) [3], and whose companions (A′ ) are further attacker-controlled accounts used to collect profit. The adversary has only the capabilities of a regular Polymarket user. Between the moment the CLOB reports a match and the moment the operator’s matchOrders settles on-chain, the adversary can act on accounts it controls to make the pending settlement revert. When necessary, the adversary can outbid the pending settlement transaction with a higher gas price [29]. Since Polymarket may blacklist abusive addresses, the adversary can also operate many
4.1. Data Collection
Tx Analysis Engine Data Source On-chain reverts
On-chain traces
Off-chain markets
Cross-chain Verified Contracts
Tx Collector
Results
Tx Tracer
RQ1 Ghost Fill
matchOrders(. . . ) transferFrom REVERT 0x. . .
prevalence
Heuristic Rule Loader proxy trap
nonce bump
RQ2 Cancellation
approve revoke
balance drain
Attacks
Reuse Analysis
RQ3
selector-set Jaccard J(A, B)
Risk spread
Figure 2. Overview of G HOST H UNTER Pipeline.
unlinkable accounts and form a Sybil cluster in which A and A′ appear unrelated on-chain [14]. Such cancellations serve three main purposes: (i) capturing the benefit of a favorable match while voiding any leg that turns losing once the outcome is known; (ii) harming participants such as AI agents [58] and arbitrage bots [31] that act on the reported fill before settlement confirms it; and (iii) degrading settlement availability through repeated cancellation, constituting a DoS against the platform. Scope. Our measurements span two protocol generations and six contracts of Polymarket (Table 3). In V1, an on-chain matchOrders call is sent to one of two Fee Module contracts for binary and neg-risk markets. Each Fee Module wraps an underlying Exchange that performs the token transfers. V1 uses USDC.e as collateral and gives each order a per-maker nonce, incremented through a public incrementNonce() function. The platform-wide cutover to V2 occurred on Apr 28, 2026. V2 routes matchOrders directly to two new exchange contracts and removes the Fee Modules entirely [42]. It switches collateral to pUSD and replaces the nonce with a timestamp-based uniqueness check.
4. G HOST H UNTER Figure 2 presents the overview of G HOST H UNTER. We first collect all reverted on-chain matchOrders transactions of Polymarket and trace their on-chain execution to recover the revert reason and classify each failure. This step supports the measurement of Ghost Fill prevalence and impact (RQ1). G HOST H UNTER then performs causal attribution for attacker-caused cases. It applies a set of vector-specific heuristic rules to each reverted transaction and emits a structured record containing the attack vector, the causal action, and the addresses involved (RQ2). Finally, G HOST H UNTER performs a cross-chain similarity analysis over verified contracts on 64 chains to identify deployments that reuse Polymarket-like designs (RQ3).
We conduct our measurement from Aug 15, 2025, when the V1 Fee Module went live [42], to May 6, 2026, spanning both the V1-to-V2 cutover and the Deposit Wallet upgrade (see Section 8.4). We draw on three datasets. On-Chain Transaction. Our primary dataset consists of all reverted matchOrders transactions sent to the settlement contracts listed in Table 3. We query Google BigQuery’s public Polygon tables [21] for transactions to these contracts whose receipts indicate failure, recording their block numbers, contract addresses, transaction hashes, timestamps, transaction indices, raw calldata, gas usage, and gas prices. We further retrieve the full execution trace of each reverted transaction from an Alchemy archive node [1]. This process yields 1,952,440 reverted transaction data. Off-Chain Market. On-chain data identifies settlement contracts and outcome tokens, but not the markets associated with those tokens. We therefore supplement the transaction dataset with Polymarket’s Gamma API [39], which maps each outcome token to its market slug [41], event category, resolution time, and liquidity reward parameters. For attacker profit analysis, we further derive each address’s realized profit from the platform’s data API [37]. Cross-Chain Verified Contracts. To assess whether Polymarket-like designs are reused beyond Polymarket, we use the verified-source dataset published by Sourcify [51], comprising 32,103,371 contracts across 401 chains. We query and filter this dataset through BigQuery to identify contracts with interfaces similar to Polymarket’s exchange contracts. All SQL queries are released in Appendix D.
4.2. Transaction Analysis G HOST H UNTER analyzes each reverted matchOrders transaction by turning raw on-chain evidence into a uniform set of facts, and then applying attribution rules over those facts. For each transaction, G HOST H UNTER first decodes the matchOrders calldata to recover the orders, participants, token amounts, and settlement contract. It then parses the execution trace to identify the internal calls made during settlement, the call that failed, and the corresponding revert reason. We further map each revert reason to its require/revert site in the official source code, which allows us to group reverts into the failure surfaces. Evidence Schema. The evidence needed to explain a revert may come from multiple sources. Some live in the failed transaction itself: the decoded order fields and the execution trace. Confirming whether the revert was deliberate also requires causal transactions in nearby blocks. We represent this evidence as a flat set of relational facts, summarized in Figure 3. We organize the facts into three groups: skeleton facts describe the order and its settlement context; frame facts describe calls inside the failed transaction; causal facts describe participant actions in the surrounding blocks.
Skeleton (decoded order and context) revert(t) reverted matchOrders version(t, ν) contract version exchange(t, x) settlement exchange x maker(t, m), taker(t, m) order owner m gas(t, γ) gas price paid by t Frame (execution trace of t) f rame(t, c) internal call c sel(c, σ) selector of c target(c, w) callee w of c err(c, ε) c reverted with ε holder(c, a) owner a of failed transfer Causal (actions in surrounding blocks) bump(s, x, b) s bumped nonce on x at b exec(s, p, b) s ran execTransaction on p inner(p, w, σ) p’s inner call to w moveOut(a, b, v, γ) a moved out v at b paying γ approve(a, x, v, b) a set x’s allowance to v Derived part(t, a) a is a participant of t near(b, t, δ) b within δ blocks before t gasRatio(γ, t, ρ) ρ = γ/γt , gas of action over t Figure 3. Relational fact schema underlying G HOST H UNTER’s rules.
Rule Matching. Each rule describes one attack vector as a conjunction of facts. The rule first checks whether the revert is consistent with the attack vector. For example, a nonce-bump rule requires an InvalidNonce revert, while an allowance-revoke rule requires a failed transferFrom caused by insufficient allowance. If this holds, the rule then looks for causal evidence showing that a participantcontrolled action occurred before settlement and explains the failure. This two-stage design keeps the rules conservative: the revert reason narrows the set of plausible explanations, and the causal evidence determines whether the revert should be attributed to an attack. Rules are applied in a fixed priority order; see Algorithm 1. When multiple rules match the same transaction, G HOST H UNTER assigns the label of the highest-priority rule to avoid double counting. Rule Construction. Because there is no ground-truth dataset of Cancellation Attacks, we build the rule set through iterative snowball sampling [20], [57]. We first group reverted transactions by revert reason and manually inspect samples from each group, including their calldata, execution traces, surrounding transactions, and state changes. When we observe a recurring mechanism, we encode it as a conjunction of on-chain facts and added to the rule set. We then rerun G HOST H UNTER, audit the matched cases for false positives, and sample the remaining unmatched cases to identify mechanisms missed by the current rule set. This process repeats until additional samples yield no new patterns. The resulting rules serve as our definition for attack-caused Ghost Fills: a revert is attributed to an attack when a participant-controlled action invalidates an alreadymatched order before its settlement confirms.
4.3. Attack Vector Rule We find four attack vectors and encode as heuristic rules:
Proxy Trap. This occurs when a participant uses a wallet whose ERC1155 receiver callback rejects token delivery from the exchange. Unlike the other vectors, no separate causal transaction is needed: the trap is embedded in the wallet code and triggered on every settlement attempt. The rule matches any revert in which a onERC1155Received callback targeting a participant wallet fails. proxy trap(T) :revert(T), frame(T, C), sel(C, onERC1155Received), target(C, W), err(C, Reverted), part(T, W).
In practice, the callback failure can appear as a direct revert, an out-of-gas error caused by deliberate gas burning, or a stack overflow caused by forced recursion. Since the failing callback belongs to the participant wallet itself, the rule does not require any lookback-window evidence. Nonce Bump. This occurs when a participant invalidates an already matched order by increasing the signer nonce on the exchange [36]. The settlement then fails with InvalidNonce because the nonce embedded in the signed order no longer matches. We detect two forms of this vector: a direct call to incrementNonce(), and an indirect call issued through a Gnosis Safe transaction. nonce bump(T) :revert(T), version(T, v1), err(_, InvalidNonce), part(T, S), exchange(T, X), bump(S, X, B), near(B, T, 5). OR revert(T), version(T, v1), err(_, InvalidNonce), part(T, S), exchange(T, X), exec(S, P, _), inner(P, X, incrementNonce).
The first clause requires the nonce update to occur within the five-block window. This reduces false positives because nonce updates can happen during normal account management, whereas a nonce update immediately before a reverted settlement is stronger evidence of cancellation. The second clause carries no window: Polymarket’s official proxy wallet exposes no direct path to incrementNonce() [43], so reaching it requires a custom execTransaction that calls the exchange directly or buries the call inside a multiSend batch. We treat any revert paired with such a call as a deliberate cancellation regardless of timing. Allowance Revoke. This occurs when a participant revokes or reduces the exchange’s allowance on the collateral token shortly before settlement, causing transferFrom to fail with insufficient allowance: allowance revoke(T) :revert(T), frame(T, C), sel(C, transferFrom), err(C, InsufficientAllowance), holder(C, A), exchange(T, X), approve(A, X, V, B), near(B, T, 5).
Our rule identifies the account whose transferFrom failed, and then queries the collateral token’s Approval events using this account as the owner and the exchange as the spender. This captures allowance changes initiated through both EOAs and proxy wallets. It labels a revert only when the new approved amount is below the amount required by the failed settlement transfer.
Total
Total matchOrders
Revert rate
Affected collateral
$219M
0.1M
100k
$0M V2 cutover
Reverts [log]
8%
10k 4%
1k
Revert Rate
balance drain(T) :revert(T), frame(T, C), sel(C, transferFrom), err(C, InsufficientBalance), holder(C, A), move out(A, B, _, G), near(B, T, 5), gas ratio(G, T, R), R > 1.
Reverted matchOrders
4.5M
Affected collateral
Balance Drain. This occurs when a participant moves collateral out of the funding wallet before settlement, leaving the exchange’s transferFrom with insufficient balance. Our rule targets front-running drains: the outgoing transfer must fall within the five-block window and carry a higher gas price than the reverted matchOrders transaction, ensuring it landed ahead of settlement [52]:
0%
2025-09 2025-10 2025-11 2025-12 2026-01 2026-02 2026-03 2026-04 2026-05
Figure 4. Overview of daily matchOrders transactions.
The gas ratio(G, T, R) fact sets R to the drain transaction’s gas price divided by the reverted settlement transaction’s gas price. Requiring R > 1 helps separate timed frontrunning from unrelated balance movements. We identify the affected wallet from the failed transferFrom frame and ignore transfers to the exchange itself, which correspond to normal settlement flows rather than drains. Finally, we check the block-level state diff to confirm that the flagged transfer reduced the wallet’s collateral balance below the amount required by settlement. When multiple rules match the same reverted transaction, G HOST H UNTER keeps only one label. We use the rule order above as the priority order: proxy trap, nonce bump, allowance revoke, and balance drain. This order gives precedence to rules with more specific failure mechanisms before applying the more general balancedrain rule.
4.4. Cross-Chain Reuse Analysis To assess how widely the flawed exchange design has spread beyond Polymarket, we search for contracts whose on-chain interface resembles the official Polymarket exchange contracts. We base this search on each contract’s function-selector set. Selector-Set Similarity. Each externally callable function is identified on-chain by a function selector (i.e., the first four bytes of the Keccak hash of its signature [7].) The selector set of a contract thus serves as a fingerprint for identifying code reuse. We quantify the similarity between two contracts using the Jaccard index [18]: for two selector sets A and B , J(A, B) = |A∩B| |A∪B| . We take the four official Polymarket V1 contracts in Table 3 as search targets and recover their selector sets from the verified source code in Sourcify. We then compare every other Sourcify-verified contract against them using the Jaccard score, retaining the maximum score for each contract. Examination. The selector scan produces a ranked list of candidate contracts, which we narrow through several filtering steps. First, we remove testnet deployments and contracts with no evidence of real use. For each remaining contract, we collect its transaction count and check whether it was still active at the end of our study window. Two authors then independently inspect the remaining candidates.
They remove contracts whose selector overlap is coincidental and confirm whether each candidate actually implements a Polymarket-like hybrid exchange design. Finally, for confirmed deployments, we identify the operating entity using block-explorer labels [33] and public web records, and obtain total value locked from DeFiLlama [12] when available. This yields 167 contracts across 10 chains, which we analyze in Section 7.
5. Answer to RQ1: Prevalence of Ghost Fills After running G HOST H UNTER over the study window, we find 1,952,440 reverted matchOrders transactions as Ghost Fills. We measure their volume over time (Section 5.1), failure surfaces (Section 5.2), affected markets and users (Section 5.3), and financial impact (Section 5.4).
5.1. Overall Volume and Temporal Distribution Ghost Fills are widespread. Across the window, G HOST H UNTER labels 1,952,440 reverted settlement transactions involving 233,887 distinct participants. The counts are similar across the protocol cutover: 1,090,016 under V1 and 862,423 under V2. However, V1 accumulated this volume over roughly nine months, while V2 reached a near-equal count in barely one week at comparable daily settlement volume. Finding 1: V2’s first week produced nearly as many Ghost Fills (862,423) as V1’s full nine months (1,090,016). At comparable daily settlement volume, V2’s daily revert rate runs more than an order of magnitude above V1’s. The revert rate rose sharply over time (Figure 4). Through late 2025, reverts were sporadic, typically a few hundred per day against a rising settlement load. From early 2026, they increased by more than two orders of magnitude; on the worst day, 8.5% of all matchOrders transactions reverted. The Deposit Wallet upgrade on May 4, 2026 (Section 8.4) reduced the daily rate from roughly 8% to 0.3% within two days. This drop suggests mitigation, but the residual rate remains above the 2025 baseline.
5.3. Affected Markets, Users, and Order Patterns
TABLE 1. FAILURE CLASSIFICATION BY REVERT REASON . Failure surface Insufficient Balance ERC1155 callback Insufficient Allowance Order validation (operator) Order validation (user) Fee computation Condition token Other / unknown Total
V1
V2
947,019 51,000 50,445 742,957 21,259 46,875 44,401 202 25,790 0 1 21,096 265 218 837 75
Total
%
998,019 51.1 793,402 40.6 68,134 3.5 44,603 2.3 25,790 1.3 21,097 1.1 483 < 0.1 912 < 0.1
1,090,016 862,423 1,952,440
100
5.2. A Taxonomy of Failure Surfaces A matchOrders can fail at several checks as depicted in Section 2.3. We decode each transaction’s revert reason, map it to the corresponding require or revert site in the official exchange source (Section 4.2), and group the sites into the eight failure surfaces in Table 1. This mapping is deterministic: each revert reason maps to one surface, and the taxonomy covers 99.9% of reverts. Two surfaces account for the majority. Insufficient balance failures make up 51.1% of all reverts: the exchange’s transferFrom found a short balance when settlement executed. A reverted ERC1155 receiver callback explains another 40.6%: the exchange could not deliver outcome tokens because the recipient wallet rejected the callback. An insufficient allowance (3.5%) blocks the same transfer one step earlier. Operator-side order validation (2.3%) covers reverts that the operator itself could have caught, such as an expired or already-filled order. User-side order validation (1.3%) is the InvalidNonce bucket, and on-chain fee computation (1.1%) is basically V2-only FeeExceedsMaxRate fault. The version split shows that the dominant failure surface changed after the cutover. Under V1, reverts concentrate in Balance (947,019), and all InvalidNonce failures (25,790) occur before V2 removed the nonce-based vector. Under V2, reverts concentrate in the ERC1155 callback surface (742,957 of 793,402), and the V2-only fee-computation fault appears. Thus, V2 changed where Ghost Fills fail, rather than eliminating them. Finding 2: Removing the incrementNonce() in V2 did not reduce Ghost Fills; The dominant failure surface shift to the dominant failure to rejected tokendelivery callback. The long tail contains direct evidence that some failures are engineered. A few reverts carry custom strings compiled into wallet code, such as GRIEFING ACTIVE, poc-v4: griefing on, and ghost-fill: receiver invalidated. These strings are rare, with only a few transactions each, but they show the potential for deliberate reverts. We therefore move beyond surface-level failure reasons to distinguish malicious Ghost Fill exploits (i.e., those caused by Cancellation Attacks) in RQ2.
We join each revert to its market through the Gamma API, resolving 99.8% of reverts. Ghost Fills concentrate in fast, recurring markets. The most common tags are Crypto, Up or Down, 5Min, each associated with more than one million reverts. The most affected individual markets are five-minute Bitcoin direction markets. High-stakes event markets also appear: “English Premier League Winner” alone has 14,900 reverts and $2.8 M of collateral at risk. It is a NegRisk multi-outcome market, a setting we revisit when analyzing arbitrage-bot hunting in Section 8.1. Reverted transactions are concentrated across accounts, but not dominated by a small fixed set. The busiest participant appears in 120,181 reverts (6.2%). The top ten takers account for 11.5% of all reverts, the top 100 for 33.5%, and the top 1,000 for 70.7%. The remaining reverts spread across a long tail of more than 138,000 takers. Finding 3: Ghost Fill activity is concentrated but broadly distributed. The top 1,000 takers account for 42.7% of reverts, while the remaining majority spans more than 138,000 takers.
5.4. Estimated Financial Impact We measure direct exposure as the collateral leg of the order that failed to settle, converted to USD. Summed over all reverts, $1.78 B failed to settle on-chain. The distribution is heavy-tailed: the median revert risks only $11 of collateral and the 90th percentile $505, but the tail runs to single orders above $1 M. Most Ghost Fills are small, and a few are very large. The operator cost is directly observable. Every reverted settlement consumes gas, totaling 2.35 M POL over the window, about $230 K at the end-of-window POL price2 . The platform bears this cost even though the settlement fails. Ghost Fills also create a user-visible consistency failure: the interface reports a fill that later disappears. Users have attributed such reversals to platform-side manipulation on social media [5], [54]. We do not quantify this reputational cost, but the volume measured above shows that the failure mode was frequent enough to be sensible. Answer to RQ1: Ghost Fills are widespread. Over the study window, G HOST H UNTER labels 1,952,440 reverted settlements involving 233,887 participants, with daily reverts peaking at 8.5% of all matchOrders transactions. These failures hamper $1.78 B of collateral to settle and burn 2.35 M POL (about $230 K) of operator gas. They concentrate on insufficient collateral balance (51.1%) and rejected token-delivery callbacks (40.6%). Across the V1-to-V2 cutover, the dominant surface shifts from the former to the latter. 2. We value gas at the POL price of $0.098 on 2026-05-06. [9]
Allowance Revoke
Balance Drain
Nonce Bump
6.2. Proxy Trap
Revert rate
V2 cutover
105
8%
104
4%
103
102 2026-01
Revert rate
Reverted matchOrders [log]
Proxy Trap
0%
2026-02 2026-03
2026-04
2026-05
Figure 5. Daily reverted matchOrders attributed to each Cancellation Attack vector, with the V1-to-V2 cutover marked. nonce bump disappears at the cutover while others persist.
6. Answer to RQ2: Cancellation Attack Vectors RQ1 grouped every revert by the on-chain check that failed during settlement. RQ2 asks which of those failures were deliberate cancellations. Each failed check reads participant-controlled state (Section 2.3), so a participant can change that state after an off-chain match but before settlement and force matched orders to revert. We therefore map the RQ1 failure surfaces to four cancellation vectors: proxy trap, nonce bump, balance drain, and allowance revoke. G HOST H UNTER’s four rules attribute 980,133 of the 1,952,440 Ghost Fills (50.2%) to Cancellation Attacks, placing $1.44 B of collateral at risk. These attacks burn 2.17 M POL (about $212 K) in operator gas, 92% of all operator gas spent on Ghost Fills. Figure 5 breaks this cost down by vector.
6.1. Evaluation Following prior works’ guidance [25], [28], we validate G HOST H UNTER’s classifications by manually inspecting a random sample from each vector, sized at 95% confidence and a 5% margin of error: 384 transactions for proxy trap (790,913 reverts) and balance drain (136,879 reverts), and 379 for allowance revoke (27,338 reverts) and nonce bump (25,003 reverts) [4]. For each sampled transaction, we examine the on-chain execution trace, the causal transaction in the surrounding blocks, and the wallet bytecode where applicable. Every sampled proxy trap transaction is correctly labeled: no honest settlement path causes the ERC1155 receiver callback to fail, so the rule has no false positives by construction. The remaining three vectors also yield no misclassifications, consistent with the behavioral definition of Cancellation Attack set in Section 4.3.
Proxy trap is the dominant vector that surged under V2: G HOST H UNTER attributes 790,913 of the 980,133 attributed reverts to it, almost all under V2. A participant wallet is engineered so that the exchange’s ERC1155 receiver callback reverts during settlement, preventing outcome-token delivery and reverting the transaction. We observe it on both roles: 486,228 reverts trapped the maker side and 304,684 the taker side. A trapped wallet remains armed across many blocks; the most prolific one produced 1,480 ghost-fill reverts, including 589 in a single seven-block window of roughly twelve seconds. This vector exhibits the greatest implementation diversity, yielding a family of variants whose only shared feature is a reverting callback. Implementation Variants. We recover 29 distinct trap implementations from on-chain bytecode and catalog them in Table 5, falling into three escalating styles. The simplest variants exhaust the gas that the exchange forwards into the callback. The largest (F-1), deployed behind 4,363 wallets, has its receiver delegatecall back into itself on every token receipt, recursing without a base case until the entire gas budget is consumed and settlement reverts with out of gas. A related implementation, F-4, instead creates the 1,024 nested calls needed to reach the EVM call-stack depth limit. Both approaches are detectable: benign settlements do not trigger gas exhaustion or call-stack overflows inside a receiver callback. Later variants hide the trap behind a plausible revert reason. One handler (F-5) reverts with the exchange’s own OrderFilledOrCancelled() selector, so an operator inspecting the failure reads it as a benign indication of a double-fill order, not a deliberate trap. Another (S-2) impersonates the OpenZeppelin ERC20: transfer amount exceeds balance string, so the revert looks like an ordinary balance shortfall rather than an engineered callback. Before this high-volume, disguised deployment, we also find a handful of early proof-of-concept contracts that revert with strings naming the abuse outright, such as ghost-fill: receiver invalidated (F-10) and poc-v4: griefing on (F-11), marking these as the proofof-concept for the mass deployment that followed. The newest carrier removes the proxy wallet entirely. EIP-7702 [47] lets an externally owned account attach contract code to itself through a type-4 set-code transaction, while keeping the same address, balance, and storage. After delegation, the account has nonzero code size, so the exchange treats it as a contract recipient and invokes the ERC1155 receiver callback. We observe this pattern in EOA 0x542e...a62a (D-1). A single type-4 transaction delegates the account to a griefing implementation and arms it. While disarmed, the callback returns the expected ERC1155 magic value, allowing the wallet to trade normally. Once armed through a self-call, the same callback reverts with GRIEFING ACTIVE, causing every subsequent token delivery to fail. Figure 6.2 shows the recovered implementation core. This variant extends proxy trap to plain EOAs and
1 2
contract GriefingHandler { bool private armed;
Proxy Wallet
Fee Module
Funding Wallet
0x9DD9. . . cAE23
matchOrders()
0x4BFE. . . 0b8d
3
function setArmed(bool v) external { require(msg.sender == address(this)); armed = v; }
4 5 6 7
272.5 USDC.e
gas=604 Gwei
signs order; CLOB matches off-chain ¥
2. matchOrders() sent — queued in mempool
8
function onERC1155Received(address, address, uint256, uint256, bytes calldata) external view returns (bytes4) { require(!armed, "GRIEFING_ACTIVE"); // reject delivery if armed on return this.onERC1155Received.selector; }
9
10 11
12 13 14
1. fund order
gas 245 Gwei (low)
3. drain collateral W 272.5 USDC.e gas 2,350 Gwei (front-run)
4. matchOrders() mined
gas=245 Gwei
try transferFrom()
TRANSFER FROM FAILED
}
CLOB clears; Ghost Fill q
5. re-fund next order
Figure 6. Core of the EIP-7702 griefing implementation delegated by 0x542e. . . a62a: a normal receiver until a self-call arms it.
evades detectors that inspect only contract wallets. Finding 4: proxy trap is engineered and evolving. We recover 29 implementations, ranging from gas burns and stack overflows to callbacks that mimic benign exchange or ERC-20 errors, and finally to an EIP-7702 variant that traps a plain EOA. Market Concentration. proxy trap is also the most market-concentrated vector. 99.2% of its reverts land in recurring crypto markets and only 0.1% in NegRisk markets, against a 9.4% NegRisk share across all Ghost Fills. The reverts cluster in the five-minute Bitcoin up-or-down markets, which carry the highest churn on the platform. Because a trap fires on every match its wallet joins, placing it in the busiest market maximizes the number of fills it can ghost before the market resolves. Finding 5: proxy trap is also the costliest vector. Its naive gas-exhaustion variants consume the whole transaction gas budget, so each revert burns 2.7 POL against 0.06 for the normal. The vector alone accounts for 2.15 M POL (about $211 K), 91.7% of all operator gas spent on Ghost Fills, and constitutes a denial-of-service to the settlement system.
6.3. Nonce Bump nonce bump is a V1-only vector: the signer calls incrementNonce() on the exchange, which invalidates the signed nonce of an already-matched order, so the settlement reverts with InvalidNonce(). G HOST H UNTER attributes 25,003 reverts to it across 2,697 distinct signers. V2 replaced the per-maker nonce with a timestamp check and removed the function, closing the vector entirely. The vector escalated into a cat-and-mouse dynamic under V1. The first-generation (N-1) broadcast
.. .
272.5 USDC.e
.. . ×369 rounds º attack continues
.. .
Figure 7. An instance of collateral withdrawal via balance drain.
incrementNonce() openly as a top-level EOA transaction, often with a high gas price, so the bump would land just before the operator’s settlement. Such top-level calls are trivial to watch for, and Polymarket began monitoring the function and banning the signers who issued them. The attackers responded by hiding the call. Polymarket’s official proxy wallet exposes no path to incrementNonce by design, so attackers hand-craft a Gnosis Safe execTransaction that invokes the exchange directly (N-2). The later attackers buried even that (N-3): the signer issues an execTransaction with operation = DELEGATECALL into the Safe MultiSend helper, whose batched payload carries the bare incrementNonce() selector as one of its inner calls. The bump then runs as an internal call inside an innocuous-looking Safe transaction and is invisible to any monitor that scans only top-level calldata for the selector. We confirmed instances from the proxy maker 0x9391...8127, whose bumps appear only inside such nested multiSend batches. Finding 6: The nonce bump vector runs an arms race: once Polymarket monitor and ban the EOAs that broadcast incrementNonce() openly, attackers hide the same call inside an internal call transaction, which is invisible to top-level transaction scanners. nonce bump over-indexes on neg-risk markets (23% of its reverts, against the 9.4% platform baseline), indicating the profit strategy of attackers with this vector ties to negrisk arbitrage-bot hunting discussed in Section 8.1.
6.4. Collateral Withdrawal The remaining two vectors both make a participant’s collateral unavailable just before settlement, and both survived the V2 cutover. They sit on opposite sides of the trade:
Balance Drain. balance drain moves all collateral out of the paying wallet, so the exchange’s transferFrom finds an empty balance; G HOST H UNTER attributes 136,879 reverts to it across 24,821 addresses, the widest attacker population of any vector. The proxy wallet 0x9dd9...ae23 is representative of 348 such reverts. Its signer front-runs each pending settlement with a high-gas execTransaction priced at 2,349.6 Gwei in a turn (standard gas for 276 Gwei [32]), landing first in its block, which sweeps the wallet’s USDC.e out [8], so the lower-gas matchOrders that follows in the same block reverts. It recycles its collateral through a fixed deposit-drain loop (B-1) that runs 369 rounds in all to initiate Cancellation Attacks (Figure 7). A more elaborate variant (B-2) batches the drain across many wallets at once. A single EOA 0x83d4...de5f empties about twenty funded wallets in one Multicall3 aggregate3 transaction, placed near the top of its block, that converts their combined 17.7K USDC.e of collateral into DAI through a Uniswap V3 pool, producing 20 related matchOrders reverts once together. Allowance Revoke. allowance revoke instead shrinks or zeroes the exchange’s token allowance, so the same transfer fails one step earlier, on the allowance check; G HOST H UNTER attributes 27,338 reverts to it across 12,080 addresses. For instance, the EOA 0x2539...6739 produced 954 reverts this way, 861 of them (90%) in the same block as the matchOrders they cancelled, almost all by calling approve(exchange, 0) on USDC.e (A-1). Because revoking touches no balance, it needs only a modest gas premium rather than the steep one a drain requires, and the allowance can be reinstated at any time, so the orders keep appearing fillable while none can settle. Finding 7: Attackers apply two strategies to bypass Polymarket’s active monitoring. 1) Technical escalation: the attack itself keeps evolving to stay ahead of each new detection rule. 2) Sybil strategy [14]: generating tens of thousands of throwaway addresses, each attack once and then discarded, so blacklisting individual accounts does little to stem them. The two vectors split along market lines. balance drain tracks the binary-crypto baseline, with 89.9% of its reverts in recurring crypto markets and 5.9% in NegRisk. allowance revoke over-indexes on NegRisk (24%, against the 9.4% baseline) and shows the lightest crypto skew of any vector.
6.5. Benign Reverts Not every revert outside the four vectors is an attack: three recurring failure modes are platform-side bugs. 1) The
ex ch a co nge ll at ct er f al ad mi ns is Ad m ad in dA d re min mo v re eAd no mi u n ma nce tc Ad hO mi wi rd n th er d s on raw 11 Fe 55 es on Re 11 cv 55 Ba tc h
balance drain is overwhelmingly the taker pulling its own collateral (91% of its reverts), whereas allowance revoke is most often a maker cutting the exchange’s allowance (64%). Each is a front-running race in which the draining or revoking transaction outbids the settlement it cancels.
J
FeeModule
ref
FeeModule (fork)
1.00
Polygon
NegRiskFeeMod. (fork)
1.00
Blast
BlastFeeModule (fork)
1.00
Polymarket
Base
BSC
FeeModuleV2
Base
IntegratorFeeLayer
BSC
FeeModuleV3
0.85
+1
+8
0.55
+10 0.27
Figure 8. Function-selector barcode comparison: a bar marks a present selector, a red gap a missing one, and orange ticks the selectors outside.
V2 fee check, FeeExceedsMaxRate(), fires on legitimate market-sell orders because the contract validates the fee against the taker’s signed limit price rather than the proceeds the match actually delivers. It reverts a flow the official interface itself produces, and accounts for the 21,076 V2 fee-computation reverts in Table 1. 2) NegRisk settlements occasionally run out of gas because each additional maker forces another on-chain split-mint, and gas grows with the maker count. Finally, 3) a taker can lose a settlement race when its concurrent same-block orders together exceed its balance while each is individually fundable, a TOCTOU gap [30] in the operator’s off-chain balance check; one market-making bot 0x850a...ce8b alone accumulated 1,103 such reverts this way. We reported all three to Polymarket through the disclosure in Section 8.3. Answer to RQ2: G HOST H UNTER attributes 980,133 of the 1,952,440 Ghost Fills to Cancellation Attacks through four vectors, placing $1.44 B of collateral at risk. Behind these vectors lie 35 distinct implementation variants and a Sybil strategy across tens of thousands of addresses, a dynamic arms race against Polymarket’s official patches and monitoring.
7. Answer to RQ3: Spread of Risk RQ1 and RQ2 measure Polymarket alone. The settlement gap they exploit, however, is not a Polymarket-specific bug; it is a property of the hybrid exchange design. We therefore measure how widely the design has been reused on other prediction platforms, then examine when reusing this architecture turns the latent gap into an exploitable vulnerability.
7.1. Cross-Chain Reuse of the Exchange The reuse of the design of Polymarket is common, along with a long-tailed distribution. Across all verified contracts on 401 chains, 31,897 share at least one function selector with a Polymarket contract, 96% score a Jaccard below 0.2,
TABLE 2. R EUSES OF THE P OLYMARKET EXCHANGE DESIGN . Platform Category
Chain
P***n O***e S***t L***s P***e B***d
BSC BSC SX Base BSC Eth.
Prediction Prediction Prediction Prediction Prediction NFT market
TVL Ghost Fills $1*.** M $7.** M $0.6* M $0.6* M $0.2* M $1.** M
Yes (∼0.2%) Yes (∼17.1%)‡ Potential† Yes (∼1.0%) Yes (∼8.9%) None
‡ Its own audit report identifies nonce bump griefing attack vector. † Its
documentation admits potential Ghost Fill patterns.
the level that common ERC-20 and ERC-1155 templates produce on their own, and 494 contracts reach a Jaccard of 0.5 or higher. We therefore cut at 0.5 and manually inspect the remaining contracts to exclude non-similarities, testnet deployments and a handful of duplicate or Polymarketowned addresses. Dropping these leaves 167 independent reuses across 10 chains, concentrated on Base and BSC. 71 of them still score a perfect 1.0, reproducing an official exchange’s interface down to its original contract names, CTFExchange, NegRiskFeeModule. Figure 8 shows a similarity comparison example. These are production systems, not abandoned clones: 31 remained active past the end of our window and average 369 K settled matches each, the largest a fee module on Base carrying 5.1M. Attributing the deployments to operating entities shows that Polymarket’s exchange design has been reused by several prediction market projects (Table 2). Because our search covers only verified source code, every reuse count is a lower bound. The Ghost Fill rates in the table are peak daily revert rates, computed as reverted matchOrders transactions divided by all matchOrders transactions on that day. Three active prediction-market reuses still show Ghost Fills: P***n, O***e, and L***s. P***n has moved from plain EOAs to an ERC-4337 EntryPoint and an officially designated smart-account model. This setup mitigates the main cancellation vectors, and its observed daily revert rate is only 0.2%. L***s reproduces Polymarket’s structure more closely and ghosts roughly 1.0% of daily matches; its NegRisk path also exhibits the same out-of-gas failure discussed in Section 6.5. O***e is the most affected active fork in our sample: on 2026-05-12, its CTF Exchange processed 6,448 matchOrders transactions, of which 1,104 reverted (17.1%). Its own audit also identifies the incrementNonce denial-of-service vector we classify in Section 6.3. P***e appears to be an earlier form of P***n and is no longer active, but we include it to show the design lineage. S***t documents the possibility of Ghost Fills, although we do not confirm live reverted settlements in our window. Finding 8: The flawed hybrid exchange is a reusable template, not an isolated bug. It is live on 167 independent deployments across 10 chains holding at least $23 M in user funds, 71 of them byte-identical interface copies, and we confirm Ghost Fills settling on the two largest forks.
7.2. From Reuse to Exploitation Code reuse alone does not explain exploitation. Polymarket’s exchange follows the Wyvern-style hybrid model [27]: users sign orders off-chain, and an on-chain matchOrders call settles the matched orders later. This design has been used since 2018 and still appears in NFT marketplaces such as B***d. In that setting, the same settlement gap exists, but it rarely creates a profitable cancellation strategy. Prediction markets, however, change the incentive semantics of the same architecture. Outcome information can render a matched order’s expected value negative before onchain settlement, giving participants a direct incentive to cancel. Wyvern-style hybrid settlement tolerated reversible fills in NFT markets because price movements between matching and settlement were typically small and symmetric; in prediction markets, the same gap becomes a profitable cancellation primitive. Finding 9: A proven architecture can become unsafe when reused under different economic semantics, turning a long-tolerated consistency gap into an exploitable cancellation vector. The Polymarket-like forks inherit the same cancellation vectors but have not shown the same attack peaks: they lack Polymarket’s liquidity, trading frequency, and permatch rewards (Section 8.1) that together make cancellation profitable at scale. The risk is latent rather than absent; if these deployments grow into the same incentive regime, the same vectors can activate. Answer to RQ3: The flawed exchange design is reused by 167 independent contracts across 10 chains holding at least $23 M in user funds, 71 of them functionidentical copies with Ghost Fills on four competing prediction markets. It shows the risk extends beyond Polymarket, and any such deployment may be exposed once the payoff for exploiting grows large enough.
8. Discussion 8.1. Profit Measurement To understand how attackers profit by forcing settlements to revert, we first sum the realized profit of every distinct attacker from Polymarket API. The total reaches $1.49 M across 4,940 profit addresses, and it badly understates the real haul, because using the address that initiates Cancellation Attacks to gain profit is not the only way. We therefore infer the profit strategies from the market distribution of attackers and discussion of anecdotal reports from social media [23], [49]. The strategies described below are real case supports and likely a subset of all. Risk-Free Prediction. This strategy runs the motivating example (Section 2.4) at scale in the five-minute crypto
up/down markets. An actor places an order just before resolution and waits. If it lands in the money, the match settles and pays out; otherwise, the actor cancels and the losing fill ghosts, so no position is ever held at a loss. The clearest case we find is 0xc393...b18f. All 360 of its orders sit in five-minute crypto markets; it realized $15,904, and G HOST H UNTER records 120 Cancellation Attacks among them. Of the 287 positions it lets settle, 286 win (99.7%). Every match it involves is timestamped after the outcome has already been revealed. Beyond these visible winners, another 18,968 addresses (40.9%) attack only crypto markets yet never settle a single successful match, so Polymarket records no profit for them. They fit the companion pattern (Section 3): the profit lands on a clean address we cannot link back, so the actor’s true take runs well above the $1.49 M we can attribute. Arbitrage-Bot Hunting. A second strategy turns the Cancellation Attack against arbitrage bots that patrol Polymarket for mispriced complementary outcomes. In a women’s short-track speed-skating market [46], an actor ran a cluster of ten Sybil wallets, each posting a fake arbitrage opportunity across the mutually exclusive sub-markets to lure a bot into building a position. The actor then cancelled, forcing the bot to hedge and dump its remaining inventory at a loss into a low bid that 0x6e7e...7282 had rested in advance; that wallet redeemed the position after settlement for $4,415.37. Liquidity-Reward Manipulation. Polymarket offers an official liquidity-rewards program for liquidity providers [40]. This incentive enables a third manipulation strategy. The maker posts a reward-eligible quote, accrues a reward score, and cancels as soon as the quote is matched. It therefore earns the payout without taking real inventory risk. We confirm it by cross-referencing attacker addresses with the on-chain reward distributor: $13,397.65 in liquidity rewards flowed to 1,567 attacker addresses. The clearest case is 0x0fb5...d1a0. This address launched 466 Proxy Traps over three days, settled no successful fills, and still received $4,425.88 from the reward program. Because it realized no trading profit and completed no match, the payout appears to be entirely farmed reward.
8.2. Organized Exploitation The attacker accounts are not the independent users they appear to be on-chain. Address-association analysis ties the cancellations to a small number of operators acting at scale. G HOST H UNTER attributes Cancellation Attacks to 46,389 distinct addresses, yet 65.6% of them cancel only once before going dormant. The wallets are mass-produced: the funder 0xbf1d...a492 seeded 24,539 fresh wallets in a five-day burst at nearly one per minute, and the account 0xd4bc...9f13 deployed 792 Gnosis Safe proxy wallets across 3,333 transactions in three days. The funding behind these wallets shows the same hand. Most funds trace to centralized-exchange and DEX wallets, where the trail ends at the custodial boundary; a minority
is laundered deliberately. We observe peel chains [26], as shown in Figure 9. A hub receives a round sum, forwards to each throwaway wallet only the gas needed for one cancellation, recovers the unspent change after the attack settles, and passes the remainder to the next hub. No wallet is left holding a balance worth clustering. The same operators register vanity addresses that share leading and trailing bytes and seed one-wei dust between the look-alikes, crowding the address graph with near-duplicates. Others route the gas through the Tornado Cash mixer and successive hops to sever the trail before it reaches an attacker.
8.3. Responsible Disclosure We disclosed our findings to Polymarket in three rounds before, during, and after the V2 cutover. We also tried our best to contact the third-party deployers from Section 7 whose contracts reuse the vulnerable design, warning each of the exposure it inherits.
8.4. Mitigations Polymarket has answered Ghost Fills with two upgrades. The V2 cutover [42] removed incrementNonce(), eliminating the nonce bump vector but leaving the other vectors intact, and cancellation attacks spiked for the week that followed. Then Polymarket shipped the Deposit Wallet [38], which routes a participant’s collateral through a platformcontrolled wallet and revokes the participant’s authority to move funds or change allowances before settlement. The rollout came with a campaign to blacklist the attacker accounts still active. Both upgrades leave the structural cause untouched, so Ghost Fills keep surfacing. Platform-side recommendations. A durable fix must shrink the window between match and settlement that every vector exploits. Short of that, Polymarket can close the TOCTOU gap by escrowing a maker’s collateral at order placement and reserving it against the open order, so the book matches only within already-locked capacity. The more complete remedy attacks the window itself. Polygon is a general-purpose chain whose block time fixes that window and exposes settlement to congestion the platform does not control. It’s worth considering migrating settlement onto a dedicated, performance-tuned chain of its own until offchain matching and on-chain settlement are effectively simultaneous. Participant-side recommendations. The arbitrage bots, market-making bots, and AI agents that act on a reported match before it settles are the parties most exposed to Ghost Fills. Until that gap closes, they can defend themselves: treat a CLOB fill as provisional and confirm it on-chain before building on it, subscribing to the mempool and waiting for the settling matchOrders to be mined, just as an exchange waits for block confirmations on a deposit. Keeping a shared blacklist of makers with a history of cancellations further lets them refuse the counterparties most likely to ghost.
9. Threats to Validity Internal Validity. Our definition of a Cancellation Attack is deliberately conservative, so the per-vector counts in Section 6 are a lower bound. G HOST H UNTER flags a causal transfer only when it lands within five blocks of the match and pays elevated gas (a gas ratio above one). We set the five-block window to match the roughly five-second gap between the off-chain Operator broadcasting a match and the settling transaction landing on-chain. A looser rule would catch more drains that amount to the same attack, but it would also count benign users who happen to move funds near a match, which we avoid to keep the counts accurate. The Ghost Fill total in Section 5 gives the matching upper bound, since every Ghost Fill runs through our pipeline and G HOST H UNTER would capture it even if all of them were attacks. The true attack volume lies between the two. We value affected collateral and gas in USD at May 6, 2026 token prices, so market volatility means these figures may differ from the value at the time of each event. External Validity. Two limits bound how far our numbers reach. We do not fully quantify attacker profit or victim loss, because each would require the attacker’s intent, which we can only infer; the full CLOB order flow of every affected account, which Polymarket keeps private; and a link across an attacker’s Sybil addresses, which they build to be unlinkable. The publicly available orderbook feeds are sparse snapshots of resting quotes that miss some the fills that a Ghost Fill cancels. Our scope is likewise bounded in time and to one venue. Ghost Fills are rare before 2026 (Figure 4), placing the earlier period before the Fee Module went live out of scope; the cross-chain spread in Section 7 counts only Sourcify-verified open-source contracts, so closed-source reuse stays unmeasured and that figure too is a lower bound.
10. Related Work
10.2. MEV and Front-Running Daian et al. [11] introduce maximal extractable value (MEV) and show that arbitrage bots front-run ordinary trades on decentralized exchanges through priority gas auctions, turning transaction ordering into a consensus-layer security risk. Torres et al. [52] measure front-running on Ethereum at scale and separate it into displacement, insertion, and suppression. On the defensive side, Yang et al. [59] systematize thirty MEV countermeasures and study the deployed auction-based solutions empirically, finding that they introduce censorship of their own. These attacks extract value by reordering or inserting transactions in a single onchain execution environment. Ghost Fills exploit a different boundary: the attacker does not reorder honest transactions but cancels its own already-matched order, destroying value agreed off-chain by forcing its on-chain settlement to revert. Ordering helps some vectors, yet the Proxy Trap tampers with the wallet’s own implementation so that settlement fails regardless of where the transaction lands.
10.3. Smart Contract Security Nyx [60] formalizes exploitable contract-layer frontrunning vulnerabilities and detects them statically, pruning unrelated function pairs on a hybrid flow graph before validating with symbolic execution that a malicious user can front-run a victim for profit. SAILFISH [2] targets stateinconsistency bugs such as transaction-order dependence, pairing a lightweight exploration phase with symbolic refinement to flag forty-seven vulnerable contracts on Etherscan. Liu et al. [28] characterize the transaction-reverting statements that Ethereum contracts use to abort anomalous transactions, measuring the security impact of removing each guard. These studies stay within a single layer: a flaw in the contract code. The Cancellation Attacks we study arise from a gap at the off-chain/on-chain boundary between offchain fills and on-chain settlement. So it cannot be revealed by analyzing contracts or transactions in isolation.
10.1. Prediction Market Measurement
11. Conclusion Saguillo et al. [48] study arbitrage on Polymarket and separate market-rebalancing arbitrage from combinatorial arbitrage, estimating roughly $40M in extracted profit. Tsang et al. [53] reconstruct an election market from onchain data and distinguish genuine trading volume from share creation and destruction; they report that arbitrage inefficiencies shrank from hours to under a minute as the market matured. Jia et al. [24] release a lifecycle dataset that spans more than 770K market records, 943M trades, and 2M oracle events. These works focus on how markets price, trade events, and resolve via on-chain reported fill. We study a different, adversarial layer of the system: whether an order matched off-chain actually settles on-chain, and how attackers can force that settlement to fail.
With G HOST H UNTER we labeled 1,952,440 Ghost Fills on Polymarket and showed that beneath them runs a deliberate Cancellation Attack: an actor voids an order it has already matched by forcing its on-chain settlement to revert. G HOST H UNTER attributes 980,133 of the reverts (50.2%) to such attacks, across four vectors and 35 variants that evolved against each defense Polymarket deployed, returning at least $2.95M in profit, burning more than $212 K) of operator gas, and at peak reverting more than a third of hourly settlements. The same flawed exchange is reused by 167 deployments across 10 chains holding at least $23 M in user funds. Because that gap is structural, Polymarket’s upgrades mitigate it without curing it.
Ethical Considerations
[13] DefiLlama. Polymarket TVL, Fees, Revenue & Volume, 2026. URL: https://defillama.com/protocol/polymarket.
This study analyzes only publicly available on-chain data (transaction receipts, contract bytecode, and event logs) and publicly accessible off-chain API data from Polymarket’s CLOB. No private user data, off-chain order-book snapshots, or proprietary systems were accessed. All blockchain addresses used in the analysis are pseudonymous identifiers recorded on a public ledger; we do not attempt to link them to real-world identities. We did not create, deploy, or execute any attack. The four cancellation vectors we document were already being exploited in the wild before our study began; our contribution is to measure and classify existing activity, not to introduce new techniques. The detection rules in G HOST H UNTER operate entirely on historical data and do not interact with live contracts or pending transactions. We disclosed our findings to Polymarket and tried our best to contact the third-party deployers identified in Section 7 whose contracts reuse the vulnerable exchange design; and the entity identities are also redacted.
[14] John R. Douceur. The Sybil Attack. In Peter Druschel, Frans Kaashoek, and Antony Rowstron, editors, Peer-to-Peer Systems, pages 251–260. Springer, 2002.
References
[22] Renke Huang, Jiachi Chen, Yanlin Wang, Tingting Bi, Liming Nie, and Zibin Zheng. An overview of Web3 technology: Infrastructure, applications, and popularity. Blockchain: Research and Applications, 5(1):100173, 2024.
[1]
Alchemy. Alchemy | Blockchain infrastructure for developers, 2026. URL: https://www.alchemy.com.
[2]
Priyanka Bose, Dipanjan Das, Yanju Chen, Yu Feng, Christopher Kruegel, and Giovanni Vigna. SAILFISH: Vetting Smart Contract State-Inconsistency Bugs in Seconds. In 2022 IEEE Symposium on Security and Privacy (SP), pages 161–178, 2022.
[3]
Vitalik Buterin. A next-generation smart contract and decentralized application platform. whitepaper, pages 3(37):2–1, 2014.
[4]
Calculator.net. Sample Size Calculator, 2025. URL: https://www. calculator.net/sample-size-calculator.html.
[5]
Castle. @devjoshstevens Still happening, I’ve probably gotten 2 ghost fills within the past 12 hrs already., 2026. URL: https: //x.com/castletheart/status/2052469456543060439.
[6]
Jiaqi Chen, Yibo Wang, Yuxuan Zhou, Wanning Ding, Yuzhe Tang, XiaoFeng Wang, and Kai Li. Understanding the Security Risks of Decentralized Exchanges by Uncovering Unfair Trades in the Wild. In 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), pages 332–351, 2023.
[7]
Ting Chen, Zihao Li, Xiapu Luo, Xiaofeng Wang, Ting Wang, Zheyuan He, Kezhao Fang, Yufei Zhang, Hang Zhu, Hongwei Li, Yan Cheng, and Xiaosong Zhang. SigRec: Automatic Recovery of Function Signatures in Smart Contracts. IEEE Transactions on Software Engineering, 48(8):3066–3086, 2022.
[8]
Circle. Bridged USDC Standard, 2026. URL: https://www.circle. com/bridged-usdc.
[9]
CoinMarketCap. Polygon (prev. MATIC) price, 2026. URL: https: //coinmarketcap.com/currencies/polygon-ecosystem-token/.
[10] cryptomancers. Polymarket Analysis | Dune, 2026. URL: https: //dune.com/cryptomancers/polymarket-analysis. [11] Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach, and Ari Juels. Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Miner Extractable Value, and Consensus Instability. In 2020 IEEE Symposium on Security and Privacy (SP), pages 910–927, 2020. [12] DefiLlama. Defi dashboard, 2026. URL: https://defillama.com.
[15] Shayan Eskandari, Mehdi Salehi, Wanyun Catherine Gu, and Jeremy Clark. SoK: Oracles from the ground truth to market manipulation. In Proceedings of the 3rd ACM Conference on Advances in Financial Technologies, AFT ’21, pages 127–141. Association for Computing Machinery, 2021. [16] ethereum. Proposer-builder separation, 2026. URL: https://ethereum. org/roadmap/pbs/. [17] ethereum.org. ERC-1155 Multi-Token Standard, 2026. URL: https: //ethereum.org/developers/docs/standards/tokens/erc-1155/. [18] Sam Fletcher and Md Zahidul Islam. Comparing sets of patterns with the Jaccard index. Australasian Journal of Information Systems, 22, 2018. [19] Gnosis. Multisig Wallet for Secure Onchain Asset Management | Safe{Wallet}. URL: https://safe.global/. [20] Leo A. Goodman. Snowball Sampling. The Annals of Mathematical Statistics, 32(1):148–170, 1961. [21] Google BigQuery. Polygon Blockchain Dataset, 2026. URL: https://console.cloud.google.com/marketplace/product/ bigquery-public-data/blockchain-analytics-polygon-mainnet-us.
[23] @itslirrato. Someone is draining negrisk bots, 2026. URL: https: //x.com/itslirrato/status/2024444009851072961. [24] Huaiyu Jia, Luofeng Zhou, Wentao Zhang, Lin William Cong, Siguang Li, and Shuo Sun. Unlocking the Forecasting Economy: A Suite of Datasets for the Full Lifecycle of Prediction Market: [Experiments \& Analysis], 2026. arXiv:2604.20421. [25] Brendan Juba, Christopher Musco, Fan Long, Stelios SidiroglouDouskos, and Martin Rinard. Principled Sampling for Anomaly Detection. In Proceedings 2015 Network and Distributed System Security Symposium. Internet Society, 2015. [26] George Kappos, Haaroon Yousaf, Rainer Stütz, Sofia Rollet, Bernhard Haslhofer, and Sarah Meiklejohn. How to Peel a Million: Validating and Expanding Bitcoin Clusters. In 31st USENIX Security Symposium (USENIX Security 22), pages 2207–2223, 2022. URL: https://www. usenix.org/conference/usenixsecurity22/presentation/kappos. [27] Loı̈c Lesavre, Priam Varin, and Dylan Yaga. Blockchain networks : Token design and management overview. Technical Report NIST IR 8301, National Institute of Standards and Technology (U.S.), 2021. [28] Lu Liu, Lili Wei, Wuqi Zhang, Ming Wen, Yepang Liu, and Shing-Chi Cheung. Characterizing transaction-reverting statements in ethereum smart contracts. In Proceedings of the 36th IEEE/ACM International Conference on Automated Software Engineering, ASE ’21, pages 630–641. IEEE Press, 2022. [29] Zuchao Ma, Muhui Jiang, Feng Luo, Xiapu Luo, and Yajin Zhou. Surviving in Dark Forest: Towards Evading the Attacks from Front-Running Bots in Application Layer. In 34th USENIX Security Symposium (USENIX Security 25), pages 1375–1392, 2025. URL: https://www.usenix.org/conference/usenixsecurity25/ presentation/ma-zuchao. [30] MITRE. CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition, 2026. URL: https://cwe.mitre.org/data/definitions/367. html. [31] Thomas Niedermayer, Pietro Saggese, and Bernhard Haslhofer. Detecting Financial Bots on the Ethereum Blockchain. In Companion Proceedings of the ACM Web Conference 2024, WWW ’24, pages 1742–1751. Association for Computing Machinery, 2024.
[32] PolygonScan. POLY Gas Tracker | PolygonScan, 2026. URL: https: //polygonscan.com/gastracker. [33] PolygonScan. Polygon PoS Chain Average Block Time, 2026. URL: https://polygonscan.com/chart/blocktime. [34] PolygonScan.com. Polygon PoS Chain (POL) Blockchain Explorer, 2025. URL: https://polygonscan.com/. [35] Polymarket. 5-Minute Crypto Odds & Predictions 2026, 2026. URL: https://polymarket.com/crypto. [36] Polymarket. Ctf-exchange. Polymarket, 2026. URL: https://github. com/Polymarket/ctf-exchange. [37] Polymarket. Data API, 2026. URL: https://docs.polymarket.com/ api-reference/introduction. [38] Polymarket. Deposit Wallets, 2026. URL: https://docs.polymarket. com/trading/deposit-wallets. [39] Polymarket. Gamma API, 2026. URL: https://gamma-api.polymarket. com/docs. [40] Polymarket. Liquidity Rewards, 2026. URL: https://docs.polymarket. com/market-makers/liquidity-rewards. [41] Polymarket. Markets & Events, 2026. URL: https://docs.polymarket. com/concepts/markets-events. [42] Polymarket. Migrating to CLOB V2, 2026. polymarket.com/v2-migration.
URL: https://docs.
[43] Polymarket. Polymarket Documentation, 2026. URL: https://docs. polymarket.com/trading/overview.
[56] Wikipedia. Prediction market. 2026. URL: https://en.wikipedia.org/ w/index.php?title=Prediction market&oldid=1358899716. [57] Claes Wohlin, Martin Höst, and Kennet Henningsson. Empirical Research Methods in Software Engineering. In Reidar Conradi and Alf Inge Wang, editors, Empirical Methods and Studies in Software Engineering: Experiences from ESERNET, pages 7–23. Springer, 2003. [58] Yijia Xiao, Edward Sun, Di Luo, and Wei Wang. TradingAgents: Multi-Agents LLM Financial Trading Framework, 2025. arXiv: 2412.20138. [59] Sen Yang, Fan Zhang, Ken Huang, Xi Chen, Youwei Yang, and Feng Zhu. SoK: MEV Countermeasures. In Proceedings of the Workshop on Decentralized Finance and Security, DeFi ’24, pages 21–30. Association for Computing Machinery, 2024. [60] Wuqi Zhang, Zhuo Zhang, Qingkai Shi, Lu Liu, Lili Wei, Yepang Liu, Xiangyu Zhang, and Shing-Chi Cheung. Nyx: Detecting Exploitable Front-Running Vulnerabilities in Smart Contracts. In 2024 IEEE Symposium on Security and Privacy (SP), pages 2198–2216, 2024. [61] Zibin Zheng, Shaoan Xie, Hong-Ning Dai, Weili Chen, Xiangping Chen, Jian Weng, and Muhammad Imran. An overview on smart contracts: Challenges, advances and platforms. Future Generation Computer Systems, 105:475–491, 2020.
Appendix A. Implementation Details of G HOST H UNTER
[44] Polymarket. Polymarket | The World’s Largest Prediction Market, 2026. URL: https://polymarket.com.
TABLE 3. P OLYMARKET CONTRACTS MEASURED IN THIS STUDY.
[45] Polymarket. Prices & Orderbook, 2026. polymarket.com/concepts/prices-orderbook.
Gen. Contract
Address
Active
V1 V1 V1 V1 V2 V2
0xe3f18a... 0xb76889... 0x4bfb41... 0xc5d563... 0xe11118... 0xe2222d...
08/15/25 – 04/28/26 08/15/25 – 04/28/26 08/15/25 – 04/28/26 08/15/25 – 04/28/26 04/28/26 – 04/28/26 –
URL: https://docs.
[46] Polymarket. Winter Games 2026: Speed Skating ST - Women’s 3000m Relay. https://polymarket.com/event/2026-winter-olympicswinter-olympics-2026-speed-skating-st-womens-3000m-relay, 2026. [47] Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, and Shiping Chen. EIP-7702 Phishing Attack, 2025. arXiv:2512.12174. [48] Oriol Saguillo, Vahid Ghafouri, Lucianna Kiffer, and Guillermo Suarez-Tangil. Unravelling the Probabilistic Forest: Arbitrage in Prediction Markets, 2025. arXiv:2508.03474. [49] Said [@said116dao]. I am pausing my LP farming Until the order system update is released As soon as I place a limit order, 2026. URL: https://x.com/said116dao/status/2050889622838804657. [50] Andrei Seoev, Leonid Gremyachikh, Anastasiia Smirnova, Yash Madhwal, Alisa Kalacheva, Dmitry Belousov, Ilia Zubov, Aleksei Smirnov, Denis Fedyanin, Vladimir Gorgadze, and Yury Yanovich. The Bidding Games: Reinforcement Learning for MEV Extraction on Polygon Blockchain, 2025. arXiv:2510.14642. [51] Sourcify. Sourcify Supported Chains, 2026. sourcify.dev/docs/chains/.
URL: https://docs.
[52] Christof Ferreira Torres, Ramiro Camino, and Radu State. Frontrunner Jones and the Raiders of the Dark Forest: An Empirical Study of Frontrunning on the Ethereum Blockchain. In 30th USENIX Security Symposium (USENIX Security 21), pages 1343–1359, 2021. URL: https://www.usenix.org/conference/usenixsecurity21/ presentation/torres. [53] Kwok Ping Tsang and Zichao Yang. The Anatomy of a Blockchain Prediction Market: Polymarket in the 2024 U.S. Presidential Election, 2026. arXiv:2603.03136. [54] User[@Aggy]. Why are limit orders on @Polymarket failing again and again?, 2026. URL: https://x.com/ Aggy 4426/status/ 2050659604103860509. [55] Zexu Wang, Jiachi Chen, Tao Zhang, Yu Zhang, Weizhe Zhang, Yuming Feng, and Zibin Zheng. Copy-and-Paste? Identifying EVMInequivalent Code Smells in Multi-chain Reuse Contracts. Proc. ACM Softw. Eng., 2(ISSTA):ISSTA046:1031–ISSTA046:1053, 2025.
Fee Module NegRisk Fee Module† CTF Exchange NegRisk CTF Exchange CTF Exchange NegRisk CTF Exchange
† The NegRisk Fee Module was upgraded once during the V1 era, which
is labeled “Fee Module V2” by Polymarket, while it is still a V1-generation contract.
G HOST H UNTER is implemented in Python and processes one reverted matchOrders transaction at a time. It replays each transaction through a batched eth call against an archive node, decodes the resulting customerror, Error(string), or Panic(uint256) payload against a selector-to-name map built from the official contract sources, and reconstructs the internal call trace and state diff. The per-vector rules run as priority-ordered plug-ins (Algorithm 1) in the order proxy trap > nonce bump > allowance revoke > balance drain; the highestpriority rule whose guard and causal facts both hold claims the rare revert that more than one rule could explain. Table 3 lists the settlement contracts G HOST H UNTER scans: the four matchOrders endpoints across V1 and V2, together with the two underlying V1 exchanges that hold the per-maker nonce.
Appendix B. Cancellation Attack Measurements Table 4 reports, for each vector, the reverted settlements split across V1 and V2, the count of distinct attacker ad-
Algorithm 1 G HOST H UNTER’s Ghost Fill classify algorithm. 1: procedure C LASSIFY (t; R) 2: input: reverted matchOrders t; rules R by priority 3: output: a labeled Ghost Fill record, or UNCLASSI -
TABLE 5. C ANCELLATION - ATTACK IMPLEMENTATION VARIANTS , GROUPED BY VECTOR . ID
FIED
Φ ← S KELETON(t) ∪ F RAMES(t) ▷ skeleton + frame facts 5: for rule ρ ∈ R in ascending priority do 6: if ρ.GUARD(Φ) then 7: Φ ← Φ ∪ P ROBE(ρ, t) ▷ causal facts 8: if ρ.BODY(Φ) then 9: return ρ.EMIT(Φ) 10: end if 11: end if 12: end for 13: return UNCLASSIFIED 14: end procedure 4:
TABLE 4. Cancellation Attack VECTORS ATTRIBUTED BY G HOST H UNTER : REVERTED SETTLEMENTS (V1 / V2), DISTINCT ATTACKER ADDRESSES , AND COLLATERAL AT RISK (M). Vector
Attkr.
$M
Proxy Trap 47,525 743,388 790,913 6,915 Balance Drain 127,794 9,085 136,879 24,821 Allowance Revoke 20,792 6,546 27,338 12,080 Nonce Bump 25,003 0 25,003 2,697
830.7 494.6 75.0 36.1
Total
V1
V2
Total
221,114 759,019 980,133
Signature / mechanism
Events
Proxy Trap (29 variants) F-1 handler out of gas (recursive delegatecall) F-2 handler reentrancy-sentry out of gas F-3 handler CustomError(0x92bbf6e8) S-1 singleton bare Reverted F-4 handler stack limit reached 1024 F-5 handler OrderFilledOrCancelled() F-6 handler Error(’invalidated’) F-7 handler Error(’rejected’) / ’Rejected’ F-8 handler CustomError(0x1663f706) D-2 EIP-7702 7 forged exchange errors (shared code) F-9 handler Error(’HARD REJECT’) S-2 singleton ERC20: transfer amount exceeds . . . D-1 EIP-7702 GRIEFING ACTIVE / not whitelisted F-10 handler ghost-fill: receiver invalidated F-11 handler poc-v4: griefing on ... ... other 14 single-use handlers
Carrier
790,913 366,000 222,002 88,787 78,664 28,071 5,214 1,353 278 217 215 10 8 7 4 1 ...
Nonce Bump (3 variants) N-1 EOA top-level incrementNonce() broadcast N-2 Safe execTransaction to exchange N-3 Safe nested multiSend delegatecall
25,003
Balance Drain (2 variants) B-1 EOA per-wallet deposit-drain loop B-2 Multicall3 batched cross-wallet sweep
136,879
Allowance Revoke (1 variant) A-1 EOA approve(exchange, 0) pre-settlement
27,338
— 1,436.4 0xf6cd…2a9f
0xe5fe…06bd
0xe7cc…76a4 0x5a1b…2cd9
dresses, the collateral at risk in millions of USD, and the share of reverts landing in NegRisk multi-outcome markets. Table 5 catalogs the 35 implementation variants behind the four vectors. Proxy Trap variants are distinct on-chain bytecodes grouped by carrier: a malicious fallback handler (F), a swapped proxy singleton (S), and a direct contract or EIP-7702-delegated EOA (D). The other three vectors are distinguished instead by how the cancelling action is delivered. Event counts are reverted settlements over V1 and V2 combined, each group row carries the per-vector total, and Proxy Trap’s long tail of single-use handlers is omitted.
Appendix C. Organized Exploitation
0x73d6…01d0
0x8655…aa30 0x3fe9…f51a
gas 0.20
gas 0.28
gas 0.24
Figure 9. Peel-chain laundering of attacker gas: a funding hub forwards each throwaway wallet exactly one cancellation’s worth of gas and reclaims the unspent change after the attack settles.
(2026-04-28 to 2026-05-06), and the matchOrders selector (0x3c2b4399). Listing 2 computes the per-reference selector-set Jaccard score that drives the cross-chain reuse analysis of Section 7. 1 2
Figure 9 traces the gas funding behind one attacker cluster, showing how a hub seeds throwaway wallets and reclaims the unspent change so that no wallet ever holds a balance worth clustering.
3
Appendix D. BigQuery Queries
10
4 5 6 7 8 9 11 12 13
We collect the primary revert dataset with the query in Listing 1, shown for the V1 contracts; the V2 query differs only in the contract address set, the time window
0xc858…c4b7
14 15
SELECT b.block_number, r.to_address AS contract_address, t.transaction_hash, t.block_timestamp, t.transaction_index, t.input AS tx_input, r.gas_used, r.effective_gas_price, CAST(r.gas_used AS BIGNUMERIC) * CAST(r.effective_gas_price AS BIGNUMERIC) AS gas_fee_wei FROM ‘bigquery-public-data.goog_blockchain_polygon_mainnet_us. receipts‘ AS r JOIN ‘bigquery-public-data.goog_blockchain_polygon_mainnet_us. transactions‘ AS t ON r.transaction_hash = t.transaction_hash JOIN ‘bigquery-public-data.goog_blockchain_polygon_mainnet_us. blocks‘ AS b
16 17 18 19 20 21 22 23 24 25
ON r.block_hash = b.block_hash WHERE r.block_timestamp >= TIMESTAMP(’2025-08-15 00:00:00+00’) AND r.block_timestamp < TIMESTAMP(’2026-04-28 00:00:00+00’) AND r.to_address IN ( ’0xb768891e3130f6df18214ac804d4db76c2c37730’, ’0xe3f18acc55091e2c48d883fc8c8413319d4ab7b0’ ) AND r.status = 0 AND STARTS_WITH(t.input, ’0x2287e350’) ORDER BY r.to_address, b.block_number, t.transaction_index;
Listing 1. Reverted matchOrders collection (V1). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
WITH ref_compilations AS ( SELECT DISTINCT vc.compilation_id FROM ‘sourcify_dataset.public_contract_deployments‘ cd JOIN ‘sourcify_dataset.public_verified_contracts‘ vc ON vc.deployment_id = cd.id WHERE cd.chain_id = 137 AND cd.address IN ( FROM_HEX(’4bfb41d5b3570defd03c39a9a4d8de6bd8b8982e’), FROM_HEX(’c5d563a36ae78145c45a50134d48a1215220f80a’), FROM_HEX(’56c79347e95530c01a2fc76e732f9566da16e113’), FROM_HEX(’b768891e3130f6df18214ac804d4db76c2c37730’) ) ), ref_sigs AS ( SELECT DISTINCT rc.compilation_id AS ref_id, ccs. signature_hash_32 FROM ref_compilations rc JOIN ‘sourcify_dataset.public_compiled_contracts_signatures‘ ccs ON ccs.compilation_id = rc.compilation_id WHERE ccs.signature_type = ’function’ ), ref_card AS (SELECT ref_id, COUNT(*) AS n_ref FROM ref_sigs GROUP BY ref_id), inter AS ( SELECT ccs.compilation_id AS cid, rs.ref_id, COUNT(DISTINCT ccs.signature_hash_32) AS n_inter FROM ‘sourcify_dataset.public_compiled_contracts_signatures‘ ccs JOIN ref_sigs rs USING (signature_hash_32) WHERE ccs.signature_type = ’function’ GROUP BY cid, rs.ref_id ), cand_card AS ( SELECT ccs.compilation_id AS cid, COUNT(DISTINCT ccs. signature_hash_32) AS n_cand FROM ‘sourcify_dataset.public_compiled_contracts_signatures‘ ccs WHERE ccs.signature_type = ’function’ AND ccs.compilation_id IN (SELECT DISTINCT cid FROM inter) GROUP BY cid ), jaccard AS ( SELECT i.cid, MAX(SAFE_DIVIDE(i.n_inter, cc.n_cand + rcd.n_ref - i. n_inter)) AS max_jaccard, MAX(i.n_inter) AS best_overlap_count FROM inter i JOIN cand_card cc ON cc.cid = i.cid JOIN ref_card rcd ON rcd.ref_id = i.ref_id GROUP BY i.cid ) SELECT cd.chain_id, CONCAT(’0x’, LOWER(TO_HEX(cd.address))) AS address, cc.name AS contract_name, cc.fully_qualified_name, ROUND(j.max_jaccard, 4) AS max_jaccard, j.best_overlap_count, vc.created_at AS verified_at FROM jaccard j JOIN ‘sourcify_dataset.public_verified_contracts‘ vc ON vc.compilation_id = j.cid JOIN ‘sourcify_dataset.public_contract_deployments‘ cd ON cd.id = vc.deployment_id JOIN ‘sourcify_dataset.public_compiled_contracts‘ cc ON cc.id = j.cid WHERE j.max_jaccard >= 0.10 ORDER BY max_jaccard DESC;
Listing 2. Cross-chain selector-set Jaccard similarity against the four reference Polymarket exchanges.