Polymarket V2 is live, has the ghost order been fixed?

Original | Odaily Planet Daily (@OdailyChina)

Author | Asher (@Asher_0210)

Last night, Polymarket entered maintenance mode, paused trading, and cleared the order book, then officially launched CLOB V2.

According to previous disclosures from the official, this upgrade includes new contracts, a new order book, a new collateral token Polymarket USD, and a new version of the CLOB-Client SDK. For users, changes like PUSD, SDK, and order structure may not be immediately noticeable. What truly warrants immediate attention is the long-standing issue of Ghost Fills, commonly referred to by the community as “phantom orders.”

V2 indeed addressed this issue. The previously most exploitable nonce mechanism was removed, and the order structure and cancellation methods also changed. But this does not mean phantom orders have been completely eradicated, 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 problems will be difficult to fully eliminate.

Why do orders show as filled but ultimately fail?

The so-called phantom orders are simply orders that appear to have been matched successfully off-chain but ultimately did not settle on-chain.

Polymarket uses an off-chain order book matching system, with settlement completed on-chain. This design has clear advantages: faster trading, lower costs, and better suited for short-cycle, high-frequency prediction markets like 5-minute markets.

The problem lies precisely in this time gap. An off-chain order book may show a trade as completed, but that does not guarantee on-chain settlement will succeed. In some short-cycle markets, users might see their orders marked as filled, believing they have bought in the desired direction; but when the transaction is actually submitted on-chain, settlement fails. A trade that looked completed a second ago can be revoked by the system a second later.

For users, the most frustrating aspect of this experience is not just failure, but uncertainty. They think they have bought or sold, only to find out the trade didn’t go through; when placing a new order, the price may have changed, and the opportunity might be missed.

The old version’s problem was that canceling orders was too cheap

In V1, one of the easiest ways to exploit phantom orders was through incrementNonce. Nonce can be understood as a status indicator within an order. Originally, it was meant to help the system manage orders, but in the old version, attackers could call incrementNonce to invalidate orders with old nonces when settling on-chain.

This gave attackers room to manipulate timing. They could first let the order be matched off-chain, making the system show “trade has occurred”; then, before the actual on-chain settlement, they could update the nonce to cause the order to ultimately fail. The result: a trade that seemed to have been completed but never actually settled on-chain.

The key issue is that this operation was very low-cost, yet could affect a batch of orders. Attackers only needed to pay a small amount of gas to cause the intended-to-be successful orders to fail during settlement. Frontends would see the order as initially successful, then failed, leading to unstable transaction results and potentially causing users to miss out on the original price and trading opportunity.

The phantom order problem is not just a simple front-end display error or occasional on-chain failure; it directly impacts users’ trust in the trading outcome.

V2 made fixes but didn’t eliminate the root cause

The most critical change in V2 was removing the original global nonce design. That is, the previous method of affecting a batch of old orders via incrementNonce has been blocked. Additionally, V2 simplified the order structure and shifted to more granular order hashes for cancellations. Compared to the old version, the scope of cancellation impact has been significantly reduced, making it harder for attackers to disrupt many orders with a single low-cost operation.

This is a substantial fix for the phantom order issue. Previously, the problem was that low-cost attacks could impact many orders simultaneously, with a relatively low barrier to reproduction. After V2, the most exploitable path was removed. If attackers want to continue creating similar issues, they will need to pay higher costs and rely more on specific system responses. Moreover, mechanisms like pauseUser, which introduce delays, further reduce the risk of immediate abuse of certain state changes within matching and settlement windows.

Overall, V2’s direction is clear: first address the most vulnerable points that attackers can exploit, then reduce the potential gains from such attacks.

But this does not mean phantom orders are fully solved. The reason is that Polymarket still relies on the 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. Balance changes, authorization issues, order status updates, cancellations, or contract execution failures can all cause an off-chain matched order to ultimately fail to be realized on-chain.

In other words, V2 addresses the most obvious and easily exploitable attack paths of the old version, but not the underlying conditions that produce phantom orders.

Other updates mainly serve to strengthen the trading system’s foundation

Besides phantom orders, V2 also introduces updates like PUSD, SDK, and 1271 signatures:

• PUSD is a new collateralized stablecoin. Polymarket has migrated from USDC.e to Polymarket USD, which is supported 1:1 by USDC. Users may not notice much, but the underlying asset handling will be more unified;
• The new CLOB-Client SDK is mainly aimed at market makers, bots, and system integrators. Post-V2, relevant users need to upgrade their clients and re-sign orders with the new order structure;
• Support for 1271 signatures means smart contract wallets, multi-signature accounts, institutional accounts, and more complex bot wallets can integrate with Polymarket more smoothly.

In summary, Polymarket is not just fixing a bug but transforming from a prediction market app into a more exchange-like underlying system. As market makers, API users, and automated traders increase, the stability of order execution, settlement, and fulfillment will become more important than just “how fun the market is.”

V2 is not the end but the beginning of ongoing improvements

Since launching V2, Polymarket has at least blocked the most obvious attack path related to phantom orders. The low-cost cancellation and batch impact methods that previously existed are now much harder to reproduce. For a rapidly growing trading platform, this is a necessary step.

But the root causes behind phantom orders will not disappear with a single version upgrade. As long as Polymarket continues to use off-chain matching and on-chain settlement, the system must constantly handle discrepancies between off-chain states and on-chain results. V2 is more like a first step—addressing the most obvious and vulnerable issues first, then continuing to improve matching, settlement, monitoring, and risk control capabilities through subsequent updates.

Prediction markets inherently deal with uncertainty. If even the orders themselves are filled with uncertainty, users face not only market risk but also system risk.

Related content

Stuck Polymarket: The real test of traffic dividends has arrived