Polymarket V2 lançado, as ordens fantasmas foram corrigidas?

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 token Polymarket USD, and the new CLOB-Client SDK. For users, changes such as PUSD, SDK, and order structure may not be immediately perceptible. What truly warrants immediate attention is the long-standing issue that has troubled Polymarket: Ghost Fills, commonly known as the “phantom 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 that 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, with settlement completed on-chain. The advantage of this design is clear: faster trading, lower costs, and it is more suitable 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 transaction as completed, but that does not guarantee successful on-chain settlement. In some short-cycle markets, users might see their order as filled, believing 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, this experience is most uncomfortable not because of simple failure, 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 cancelling an order 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 let the order be matched off-chain, making the system display “transaction 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 appeared to be 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 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 at once via incrementNonce has been blocked. At the same time, V2 simplified the order structure, shifting to a more granular single 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 wide impact, and the barrier to reproduction was low. After V2, the most exploitable pathway 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 added delays further reduce the possibility of immediate abuse of certain state changes within matching and settlement windows.

Overall, V2’s direction is quite 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 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 not the underlying conditions that produce ghost orders.

Other updates mainly serve to reinforce the trading system’s 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 that 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

Since V2’s launch, Polymarket has at least blocked the most obvious attack pathway related to ghost orders. The low-cost cancellation and batch impact methods previously used are now much harder to reproduce as before. For a rapidly expanding 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 the first step—addressing the most obvious and 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 orders themselves are filled with uncertainty, users face not just market risk but system risk.

Related content

Stuck Polymarket: The real test of traffic dividends has arrived