Polymarket V2 Launches, Ghost Fills Addressed but Not Fully Resolved

Author | Asher (@Asher_0210)

Last night, Polymarket entered a maintenance window, paused trading, and cleared the order book before officially launching CLOB V2.

According to previous official disclosures, this upgrade includes new contracts, a new order book, the new collateral token Polymarket USD, and the updated CLOB-Client SDK. For users, changes such as PUSD, the SDK, and order structure may not be immediately noticeable. What truly deserves immediate attention is the long-standing issue of Ghost Fills—commonly referred to by the community as "ghost orders"—that has plagued Polymarket.

V2 did address this issue. The previously most exploitable nonce mechanism has been removed, and both the order structure and cancellation method have changed. However, this does not mean ghost orders have been completely eliminated, because Polymarket’s core trading model still relies on off-chain matching and on-chain settlement; as long as there is a time gap between these two steps, similar issues are difficult to fully eradicate.

A ghost order, in simple terms, is an order that appears to have been matched off-chain but ultimately fails to settle on-chain.

Polymarket uses an off-chain order book matching system, with settlement finalized on-chain. This design offers clear advantages: faster trade execution, lower costs, and better suitability for short-cycle, high-frequency prediction markets like the 5-minute market.

The issue lies precisely in this time difference. Just because the off-chain order book shows a trade has been executed does not mean the on-chain settlement will succeed. In some short-term markets, users may see their order marked as filled and assume they’ve successfully purchased the asset, only to find that when the transaction is finally submitted on-chain, the settlement fails. A trade that appeared completed a moment ago is then revoked by the system the next.

For users, the most frustrating part of this experience isn't simply failing—it's the uncertainty. Thinking a buy or sell order has been completed, only to find out it didn't execute; by the time you place the order again, the price may have changed, and the opportunity may already be gone.

In V1, one of the most exploitable paths for ghost orders came from incrementNonce. The nonce can be understood as a state identifier within an order. Originally intended to help the system manage orders, in the older version, attackers could call incrementNonce to invalidate orders with an old nonce on-chain for a given address.

This creates a time window for attackers to exploit. Attackers can first match orders off-chain, causing the system to display “trade executed”; then, before settlement is finalized on-chain, they update the nonce, causing these orders to ultimately fail. As a result, a transaction that appears to have been completed never actually settles on-chain.

The key issue is that this operation has extremely low cost but can affect a batch of orders. Attackers only need to pay a minimal gas fee to cause orders that should have been filled to fail during settlement. From the frontend perspective, it appears as though orders are filled and then fail, resulting in unstable transaction outcomes and potentially causing users to miss their intended execution prices and trading opportunities.

The ghost order issue is not a simple frontend display error or an occasional on-chain failure—it directly impacts users' trust in the outcome of their trades.

The most critical change in V2 is the removal of the original global nonce design. This means the previous method of affecting multiple old orders at once via incrementNonce has been closed off. Additionally, V2 simplifies the order structure, and cancellations now operate at a finer granularity using individual order hashes. Compared to the previous version, the impact scope of cancellations is significantly reduced, making it much harder for attackers to disrupt a large number of open orders with a single low-cost operation.

This is a substantial fix for the ghost order issue. Previously, the attack cost was low, the impact was broad, and the barrier to reproduction was minimal. After V2, the most easily exploitable path has been removed. Attackers wishing to recreate similar issues must now incur higher costs and rely more heavily on specific system responses. Additionally, mechanisms such as pauseUser introduce delays, reducing the likelihood of certain state changes being immediately abused within the matching and settlement window.

Overall, the direction of V2 is clear: first address the most vulnerable points that attackers are likely to exploit, then reduce the potential rewards of similar attacks.

But this still does not equate to the complete resolution of ghost orders. The reason is that Polymarket has not changed its fundamental model of off-chain matching and on-chain settlement. As long as orders are not matched and settled within the same environment, there will always be a state discrepancy between off-chain and on-chain systems. Changes in balances, authorization issues, order status updates, cancellation actions, or contract execution failures could prevent an off-chain matched order from ultimately being settled on-chain.

In other words, V2 addresses the most obvious and easily exploitable attack vectors in the previous version, not the underlying conditions that give rise to ghost orders.

In addition to ghost orders, V2 brings updates such as PUSD, SDK, and signature 1271:

• PUSD is a new collateralized stablecoin; Polymarket has migrated from USDC.e to Polymarket USD, backed 1:1 by USDC, with minimal impact on regular users but more unified underlying asset management;
• The new CLOB-Client SDK is primarily designed for market makers, bots, and system integrators. After V2, relevant users must upgrade their clients and re-sign orders using the new order structure;
• With signature support for 1271, smart contract wallets, multisig accounts, institutional accounts, and more complex bot wallets can integrate more smoothly with Polymarket.

Overall, Polymarket isn't just patching a single vulnerability—it's transforming itself from a prediction market app into a more exchange-like underlying system. As market makers, API users, and automated traders grow in number, the stability of order execution, settlement, and payout becomes more important than whether the market is "fun enough."

After the launch of V2, Polymarket has at least closed off the most obvious attack vector in ghost orders. The previous method of low-cost order cancellations to bulk-influence orders is now much harder to replicate in the same way. For a rapidly scaling trading platform, this was a necessary step.

However, the root causes behind ghost orders won't disappear entirely with just one version upgrade. As long as Polymarket continues to use off-chain matching with on-chain settlement, the system will need to continuously reconcile differences between off-chain states and on-chain outcomes. V2 is more like a first step—addressing the most obvious and easily exploitable issues first, then gradually enhancing matching, settlement, monitoring, and risk control capabilities through future updates.

Prediction markets trade in uncertainty itself; if even the orders themselves are uncertain, users face not just market risk, but systemic risk.

Stuck Polymarket: The real test after the traffic红利 has arrived