Polymarket V2 đã ra mắt, đơn hàng ma đã sửa chưa?

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 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 previously most exploitable nonce mechanism was removed, and the order structure and 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 does not settle on-chain.

Polymarket uses an off-chain order book matching system, then completes settlement on-chain. 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 also lies 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 have bought in the desired direction; but when the transaction is actually submitted on-chain, the settlement fails. A transaction that seemed completed a second ago can be revoked by the system a second later.

For users, the most uncomfortable part of this experience is not just failure, but uncertainty. Believing they have already 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 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 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 settled to fail during the settlement phase. Frontends see 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 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 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 low-cost attacks could have a large impact, with a low barrier to reproduction. 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 with delays are added to reduce the possibility of 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 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. 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 not the underlying 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, 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 previously could be easily reproduced are now much harder to do 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 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