Polymarket V2 telah diluncurkan, apakah pesanan hantu sudah diperbaiki?

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, new collateral tokens Polymarket USD, and the new 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 that has troubled Polymarket: Ghost Fills, commonly known as the “ghost order” problem in the community.

V2 indeed addressed this issue. The nonce mechanism, which was the most vulnerable to exploitation, has been removed, and the order structure and order cancellation methods have 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.

Order shows as filled, why does it ultimately fail?

The so-called ghost order, simply put, is an order that appears to have been matched successfully off-chain but ultimately does not settle on-chain.

Polymarket uses an off-chain order book matching system, with settlement completed on-chain. The advantage of this design is clear: faster trading speed, lower costs, and it is more suitable for short-cycle, high-frequency prediction markets like 5-minute markets.

The problem also stems from this time difference. An off-chain order book may show a transaction as completed, but that does not guarantee on-chain settlement success. In some short-cycle markets, users might see their order as filled, thinking they have bought in the correct direction; but when the transaction is actually submitted on-chain, the settlement fails. A transaction that seemed completed one second ago can be revoked by the system the next second.

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 trading opportunity might have been missed.

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

In V1, one of the easiest ways for ghost orders to be exploited 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 time advantage. They could first let the order be matched off-chain, making the system display “transaction has occurred”; then, before actual on-chain settlement, they could update the nonce, causing these orders to ultimately fail. The result is that a transaction that seemed to have been completed is never actually settled 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 been settled to fail during the settlement phase. The front end sees the order as first successful, then failed, but the actual effect is transaction instability, even causing users to miss 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 through 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 order 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 ghost order problem. Previously, the issue was that the low cost and wide 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, are also aimed at reducing the immediate abuse of certain state changes within matching and settlement windows.

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

But this does not mean ghost orders are completely solved. The reason is that Polymarket still maintains the fundamental mode 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, cancellation actions, 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 collateral stablecoin, migrating Polymarket 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 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 launched, Polymarket at least blocked the most obvious attack path related to ghost orders. The low-cost order cancellations and batch impacts that could previously be easily reproduced are now much harder to do in the same way. 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 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 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