Polymarket V2 lanzado, ¿se han arreglado las órdenes fantasma?

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 the new version of CLOB-Client SDK. For users, changes such as 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 “ghost orders.”

V2 indeed addressed this issue. The previously most exploitable nonce mechanism was removed, and the order structure and order cancellation methods also changed. But this does not mean ghost 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.

Orders show as filled, why do they ultimately fail?

The so-called ghost orders, simply put, are an order that appears 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 afterward. The advantage of this design is clear: faster trading, lower costs, and it’s more suitable for short-cycle, high-frequency prediction markets like 5-minute markets.

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

For users, this experience is most uncomfortable not because of simple failures, but because of uncertainty. Believing they have bought or sold, only to find out at the end that no transaction was finalized; when re-placing an order, the price may have changed, and the opportunity to trade might have been missed.

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

In V1, one of the easiest ways to exploit ghost 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 at the time of on-chain settlement.

This gave attackers a window of opportunity for timing attacks. Attackers could first have their orders matched off-chain, making the system display “a trade has occurred”; then, before the actual on-chain settlement, they could update the nonce, causing these orders to ultimately fail. The result is that a transaction that seemed completed is never actually finalized on-chain.

The key issue is that this operation is very low-cost but can affect a batch of orders. Attackers only need to pay a very low gas fee to cause orders that should have settled to fail during the settlement phase. The front end sees the order as first filled, then failed, but the actual effect is unstable transaction results, even causing users to miss out on the original price and trading opportunity.

Ghost orders are not just simple front-end display errors or occasional on-chain failures; they directly impact users’ trust in the transaction results.

V2 has fixed this, but not completely eradicated

The most critical change in V2 is the removal of the previous global nonce design. That is, the method of affecting a batch of old orders via a single incrementNonce has been blocked. At the same time, V2 simplified the order structure, shifting to a more granular order hash for cancellations. Compared to the old version, the scope of cancellation impact has been significantly reduced, making it much harder for attackers to disrupt many orders with a single low-cost operation.

This is a substantial fix for the ghost order problem. Previously, the issue was that the low cost of attack and broad impact made it easy to reproduce. After V2, the most exploitable path has been removed. If attackers want to continue creating similar issues, they will need to pay higher costs and rely more on specific system responses. Additionally, 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 ghost orders are completely 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. Changes in balances, 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 does not fundamentally eliminate the conditions that produce ghost orders.

Other updates, mainly to support the trading system infrastructure

Besides ghost orders, V2 also introduces updates such as 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. Ordinary 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 itself from a prediction market application 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

After V2’s launch, Polymarket has at least blocked the most obvious attack path related to ghost orders. The previous low-cost order cancellations and batch impact methods are now much harder to reproduce as before. For a rapidly growing trading platform, this is a necessary step.

But the root causes behind ghost 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 will need to constantly handle discrepancies between off-chain states and on-chain results. V2 is more like a first step—addressing the most obvious and easily exploitable 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 order book itself is full of uncertainty, users face not only market risk but also system risk.

Related content

Stuck Polymarket: The real test after the traffic dividend has passed