Polymarket V2上线，幽灵订单修好了吗？

Original by Odaily 星球日报 (@OdailyChina)

Author: Asher (@Asher_ 0210)

Last night, Polymarket entered a maintenance window, paused trading and cleared the order book, before officially launching CLOB V2.

According to what the team previously disclosed, 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, the SDK, and order structure may not be immediately noticeable. The thing truly worth paying attention to right away is the "Ghost Fills" issue that has long plagued Polymarket.

V2 does address this problem. The previously exploitable nonce mechanism has been removed, and the order structure and cancellation method have also changed. However, this does not mean ghost fills have been completely eliminated, because Polymarket's core trading model remains off-chain matching with on-chain settlement. As long as there is a time lag between these two steps, similar problems are difficult to erase entirely.

An order shows as filled, why does it ultimately fail?

Ghost fills, simply put, refer to an order that appears to have been successfully matched off-chain but never completes settlement on-chain.

Polymarket uses a model where matching occurs on an off-chain order book, followed by settlement back on-chain. The advantage of this design is clear: faster transaction speed, lower costs, and suitability for short-cycle, high-frequency prediction markets like the 5-minute markets.

The problem lies precisely in this time lag. An off-chain order book showing a fill does not guarantee on-chain settlement will succeed. In some short-cycle markets, a user might see an order marked as filled, believing they have successfully bought the relevant position; but when the transaction is actually submitted on-chain, settlement fails. A trade that appeared complete a second ago is then revoked by the system.

For users, the most frustrating part of this experience is not merely the failure itself, but the uncertainty. Believing a buy or sell has been completed, only to find it never settled; by the time they re-enter an order, the price may have moved, and the trading opportunity may have been missed.

The old version's problem: cancellation cost was too low

In V1, one of the most exploitable pathways for ghost fills came from incrementNonce. Nonce can be understood as a status identifier for an order. It was originally intended to help the system manage orders, but in the old version, an attacker could call incrementNonce, causing orders under a specific address bearing an old nonce to fail during on-chain settlement.

This gave attackers a window for time-lag manipulation. An attacker could first let an order be matched off-chain, making the system show that "a trade has occurred"; then, before that settlement is actually submitted on-chain, update the nonce, causing these orders to ultimately fail execution. The result is that a seemingly completed trade never truly materializes on-chain.

The crux of the issue is that this operation is extremely cheap but can affect a batch of orders. An attacker only needs to pay a very low gas cost to cause orders that should have been filled to fail at the settlement stage. The frontend shows an order first filled, then failed; the actual consequence is unstable trading results, potentially causing users to miss the original execution price and trading opportunity.

The ghost fill problem is not merely a frontend display error or an occasional on-chain failure; it directly impacts user trust in trade outcomes.

V2 has patched it, but not completely eradicated it

The most critical change in this V2 is the removal of the original global nonce design. This means the previous method of using incrementNonce to affect a batch of old orders at once has been blocked. At the same time, V2 simplifies the order structure, and cancellation now targets more granular individual order hashes. Compared to the old version, the impact range of cancellation has been significantly compressed, making it much harder for an attacker to disrupt numerous pending orders with a single low-cost operation.

This is a substantive fix for the ghost fill problem. The previous issue was the combination of low attack cost, wide impact range, and low barrier to reproduction. After V2, the most easily exploitable pathway has been removed. If an attacker wants to continue creating similar problems, they will face higher costs and become more dependent on specific system responses. Additionally, the introduction of delays in mechanisms like pauseUser also reduces the potential for certain state changes to be immediately exploited within the matching and settlement window.

Overall, V2's direction is clear: first address the link most vulnerable to attackers, then reduce the profit potential of such attacks.

But this cannot yet be equated to the complete resolution of ghost fills. The reason is that Polymarket has not changed its fundamental model of off-chain matching and on-chain settlement. As long as orders are not matched and settled within the same environment, a state difference between off-chain and on-chain will always exist. Changes in balance, authorization issues, order status changes, cancellation actions, or contract execution failures can all prevent an order matched off-chain from ultimately settling on-chain.

In other words, V2 solves the most obvious and exploitable attack pathway of the old version, not the fundamental conditions that give rise to ghost fills.

Other updates are more about reinforcing the trading system's foundation

Beyond ghost fills, V2 also brings updates like PUSD, the SDK, and 1271 signatures:

• PUSD is the new collateral stablecoin. Polymarket is migrating from USDC.e to Polymarket USD, which is 1:1 backed by USDC. For regular users, this is largely imperceptible, but it unifies underlying asset handling;
• The new CLOB-Client SDK mainly targets market makers, bots, and system integrators. After V2, these users need to upgrade their client and re-sign orders using the new order structure;
• 1271 signature support means smart contract wallets, multi-sig accounts, institutional accounts, and more complex bot wallets can connect to Polymarket more smoothly.

In summary, Polymarket is not just fixing a single vulnerability; it is transforming itself from a prediction market application into an underlying system that more closely resembles an exchange. As market makers, API users, and automated traders increase, the stability of order execution, settlement, and payout becomes more critical than "whether the market is fun enough."

V2 is not the end, but the beginning of continuous patching

With the launch of V2, Polymarket has at least blocked the most obvious attack pathway for ghost fills. The previous method of low-cost cancellations affecting batches of orders will be difficult to replicate in the same way. For a trading platform that is rapidly scaling, this is a necessary step.

However, the root cause of ghost fills will not disappear entirely because of a single version upgrade. As long as Polymarket continues to use the off-chain matching, on-chain settlement model, the system must constantly manage the discrepancy between off-chain status and on-chain results. V2 is more like a first step – first solving the most obvious and exploitable issues, then continuing to fortify matching, settlement, monitoring, and risk control capabilities through subsequent updates.

Prediction markets inherently trade on uncertainty. If the orders themselves are also full of uncertainty, users are no longer facing just market risk, but systemic risk.

Related Content

Polymarket Stuck: The Real Test Beyond the Traffic Boom Arrives