Polymarket Fixes Ghost Fills With Major CLOBv2 Upgrade & Matching Engine Refactor

Polymarket's CLOBv2 upgrade, launched on April 28, 2026, addresses critical trading issues like ghost fills, improves system reliability, and introduces a new collateral token, pUSD. Here's what you need to know:

• Ghost Fills Fixed: Ghost fills - failed transactions that wasted gas - are significantly reduced by replacing the nonce system with millisecond-based timestamps and a revamped matching engine.
• New Features: The system now supports EIP-1271, enabling smart contract wallets, and uses updated Solidity contracts for better performance.
• pUSD Token: A new ERC-20 token, fully backed 1:1 by USDC, simplifies settlements and eliminates risks tied to bridged USDC.
• Lower Costs: Gas efficiency improved with Solady-based contracts, cutting transaction costs for traders.
• Dynamic Fees: Taker fees are calculated at match time, offering more flexibility and transparency.

The upgrade also cleared all previous orders, requiring traders to resubmit them using pUSD. Early reports showed some settlement issues post-launch, but overall, the changes aim to deliver faster, more reliable trading.

What Are Ghost Fills and How Do They Affect Trading

A ghost fill happens when a trade seems to go through off-chain but doesn't actually settle on the blockchain. In hybrid CLOB systems like Polymarket's, the matching engine works off-chain for faster processing, while settlements are finalized on-chain. When these two systems fall out of sync - where an off-chain engine shows an order as "matched", but the blockchain's smart contract rejects it - a ghost fill is the result. This disconnect can significantly impact trader accounts.

For instance, a trader might see a filled order in the interface, but their wallet balance remains unchanged. Worse, the failed transaction still burns gas - about 1.3 million gas per reverted ghost fill - leaving traders to pay for trades that never actually happened. To make matters worse, the failure rate is skewed. Profitable orders fail 48% of the time, while losing orders fail only 15% - a stark threefold difference. One example highlights this issue: wallet 0x0975c871e591c2a890095720b08386a221b62354 saw 12 out of 34 trades fail between May 1–2, 2026. Of those failed trades, 10 (83%) would have been profitable based on price data at the time.

"Net: capital is being consumed by adverse selection on the small side while wins evaporate via settlement reverts." - murphyxs8-ch1, Technical Reporter, Polymarket GitHub

The ripple effects of ghost fills go beyond individual traders. They distort the order book itself, creating "ghost liquidity" - orders that appear available but aren't actually executable. This misleads traders and disrupts market transparency. Fixing ghost fills is critical for hybrid systems seeking to create a fair and reliable trading experience.

Key Technical Changes in the CLOBv2 Upgrade

The CLOBv2 upgrade, launched on April 28, 2026, introduced a complete overhaul of Polymarket's core backend systems. This included critical components such as the order manager, ledger, executor, balance checker, and tracker. Additionally, the on-chain exchange contract was rebuilt using Solidity 0.8.30, an upgrade from version 0.8.15. A major shift from OpenZeppelin to the Solady library brought notable gas cost reductions and introduced batched minting and merging, streamlining trade execution for users.

Refactored Matching Engine

The matching engine in CLOBv2 underwent a significant redesign. Instead of the sequential nonce system used in V1, orders are now identified using millisecond-based timestamps. This change eliminates the risk of ghost fills caused by mismatches between the off-chain engine and the on-chain contract.

Another improvement is the dynamic fee calculation at the time of matching, allowing for market-specific rates without requiring a new signature for each transaction. The structure of orders has been simplified by replacing fields like nonce, feeRateBps, taker, and expiration with more efficient alternatives: timestamp, metadata, and builder.

Beyond these structural updates, CLOBv2 enhances security by incorporating advanced signature protocols.

EIP-1271 Signature Integration

CLOBv2 now natively supports EIP-1271, enabling smart contract wallets (e.g., Gnosis Safe or Polymarket's proxy wallets) to verify orders directly on-chain. Previously, order signing was restricted to externally owned accounts, which posed challenges for institutional users and market makers. To address this, a new signatureType field was added to the V2 order structure, allowing for seamless handling of different authentication methods.

The upgrade also includes an update to the EIP-712 domain version, moving from "1" to "2". This provides a more secure framework for verifying off-chain signatures on-chain.

On-Chain Order Ownership

With the integration of EIP-1271, the Exchange contract can now confirm programmatically that a specific contract account authorized a trade. This resolves a transparency issue in V1 by cryptographically tying orders to their originating accounts.

Additionally, the introduction of the builder field replaces the older HMAC-header process. This allows integrators to attach a builderCode directly to orders, making fee attribution and revenue sharing more straightforward and transparent.

pUSD Token Migration: What Users Need to Know

With the CLOBv2 upgrade, Polymarket introduced pUSD, an ERC-20 token on Polygon. This token is fully backed 1:1 by Circle's USDC and enforced through an on-chain mechanism.

According to the Polymarket Help Center:

"pUSD is the new collateral token for Polymarket. It's a regular ERC-20 on Polygon, backed 1:1 by USDC. The smart contract enforces the 1:1 backing, so one pUSD always converts back to one USDC, no fees." - Polymarket Help Center

Previously, using bridged USDC.e introduced additional risks and settlement complexities. With pUSD, Polymarket simplifies settlements by using native USDC, cutting down on liquidity fragmentation. This shift is especially impactful for a platform managing over $900 million in weekly trading volume. The result? Smoother transactions and a more efficient trading experience.

Migration Details

The migration process depends on how users access the platform:

• Web Users: Simply convert USDC to pUSD through a one-time approval prompt.
• API Traders and Developers: Call the wrap() function on the Collateral Onramp contract (0x93070a847efef7f70739046a929d47a521f5b8ee) and input the amount in raw 6-decimal units (e.g., 1,000,000 equals $1.00).

Developers must also update to the latest SDKs - @polymarket/clob-client-v2 for TypeScript or py-clob-client-v2 for Python. Keep in mind, the older V1 packages are not compatible with the new system.

Key Notes

All open orders from CLOBv1 were cleared during the maintenance period. Users need to re-submit their limit orders using pUSD. Additionally, the V2 fee model now applies only to takers, with fees dynamically calculated and accessible via the getClobMarketInfo() function.

Performance Gains for Traders After the CLOBv2 Upgrade

The CLOBv2 upgrade brings noticeable performance improvements for traders, enhancing speed, efficiency, and liquidity.

Lower Latency and Reduced Gas Costs

One of the standout benefits is faster performance. Polymarket achieved this by completely overhauling its matching engine, including components like the order manager, ledger, executor, and balance checker. They also introduced a streamlined order structure, cutting down processing time for matching and settling orders significantly.

Gas costs have seen a notable reduction as well. The on-chain exchange was rewritten using Solidity 0.8.30, moving from OpenZeppelin to the Solady library to boost gas efficiency. The system now supports batched mint and merge operations, which is a game-changer for high-frequency traders aiming to lower per-transaction costs. Another highlight is the updated fee model: makers incur zero fees, while taker fees are dynamically calculated at the time of matching.

Beyond these technical upgrades, Polymarket introduced measures to encourage deeper liquidity right after the upgrade.

Liquidity Rewards Program

To restore order book depth following the April 28, 2026 migration, Polymarket launched a $1,000,000 liquidity rewards program. This program included a two-hour launch window followed by a full-day rewards phase, designed to quickly rebuild liquidity.

"Polymarket has launched its CLOB v2 exchange and introduced pUSD, requiring users to migrate balances as part of a broader infrastructure overhaul." - AMBCrypto

This incentive holds weight, especially on a platform that processed around $9.55 billion in 30-day trading volume leading up to the upgrade. Deeper liquidity results in tighter spreads and better pricing, directly benefiting traders.

Recommended Infrastructure for CLOBv2 Trading

With latency improvements in place, high-performance infrastructure becomes crucial for traders seeking optimal execution. Those using automated strategies or API-based trading on Polygon's CLOBv2 system should consider QuantVPS Pro+ or Ultra+ plans. These plans offer 1Gbps+ network speeds and high-performance CPUs, ensuring minimal delays. For traders, achieving millisecond-level connectivity can make a significant difference.

CLOBv1 vs. CLOBv2: What Changed

This section breaks down the key differences between CLOBv1 and CLOBv2, showcasing improvements in order identification, security, and fee flexibility. CLOBv2 doesn't just tweak the old system - it rebuilds the trading infrastructure to tackle the root causes of issues like ghost fills, rather than merely addressing their symptoms.

One of the most impactful updates is in how orders are identified. In CLOBv1, the nonce-based system was prone to exploitation, leading to ghost fills, as discussed earlier. CLOBv2 replaces nonces with millisecond-precision timestamps and introduces native EIP-1271 support. This allows for compatibility with smart contract wallets like Gnosis Safe and institutional-grade multi-signature setups, a significant leap from CLOBv1's reliance on standard EOA signatures.

The fee structure has also undergone a major overhaul. Previously, in CLOBv1, fees were hardcoded into the signed order, making them inflexible. CLOBv2 shifts to a dynamic fee model where fees are determined at match time based on market-specific parameters. This change not only increases flexibility but also eliminates a common friction point that could lead to settlement failures. Here's a detailed comparison of the two versions:

Comparison Table

Feature	CLOBv1 (Legacy)	CLOBv2 (Upgrade)
Order Uniqueness	Nonce-based	Timestamp-based (milliseconds)
Signature Support	Standard EIP-712	EIP-712 + EIP-1271 (Smart Contract Wallets)
Collateral Token	USDC.e (bridged)	pUSD (1:1 USDC-backed, on-chain enforced)
Fee Handling	Embedded in signed order	Set by protocol at match time
Order Cancellation	On-chain manual cancel	Operator-controlled pause/unpause
Ghost Fill Status	Persistent - nonce exploits	Significantly reduced via engine refactor
Gas Efficiency	Standard OpenZeppelin contracts	Solady-optimized with batched operations

CLOBv2 also introduces a Solidity upgrade with Solady integration, which improves gas efficiency - a crucial enhancement for high-frequency traders. Additionally, the transition from bridged USDC.e to pUSD eliminates the settlement risks tied to cross-chain bridges, further strengthening the system's reliability.

What Ghost Order Removal, Liquidity Rewards, and Contract Migration Mean for Prop Traders

The Polymarket CLOB V2 upgrade changes the trading environment through three main features: ghost order removal cleans up the signal, liquidity rewards temporarily help market makers, and contract migration creates significant operational challenges. Each one carries different risks and rewards depending on how your operation is set up.

"The CLOB V2 upgrade introduces three structural shifts — ghost order removal, liquidity rewards, and contract migration — each demanding a distinct strategic response from prop traders."

💡 Tip: Understand which of the three V2 features affects your setup most directly before adjusting your strategy — ghost order removal, liquidity rewards, and contract migration each require a different operational response.

⚠️ Warning: Contract migration is the highest-risk element of the V2 upgrade — traders who fail to account for migration timing and position continuity face avoidable execution gaps.

V2 Feature	Primary Effect	Who It Impacts Most
Ghost Order Removal	Cleans up the order book signal	Signal-based and systematic traders
Liquidity Rewards	Temporary incentive for market makers	Market makers and liquidity providers
Contract Migration	Operational transition challenges	All active prop traders

1. “Ghost orders” removal = cleaner order book signal

Ghost orders were UI / sync artifacts where displayed liquidity didn't truly exist in the matching engine.

For prop traders, that caused three real problems:

• False liquidity reads → you think there’s size to lean on, but it disappears on execution
• Bad quoting decisions → market-making bots tighten spreads based on fake depth
• Broken signal strategies → order book imbalance indicators get distorted

What changes now

With elimination at the engine level:

• Order book depth becomes more trustworthy as a signal
• Book-based strategies (imbalance, spoof detection, liquidity pressure) get cleaner inputs
• Fill probability models become more stable

Translation: less “phantom liquidity risk,” better predictability of execution quality

But important nuance: this doesn't create an edge by itself. It removes noise. Everyone gets the same cleaner tape.

2. CLOBv2 overhaul = microstructure shift (not just a bug fix)

They also mention:

• Refactored matching engine
• Migration to a new underlying blockchain layer
• Improved scalability and security

For prop trading, that typically implies:

a) Latency profile changes

Even small backend changes can shift:

• order confirmation times
• cancel/replace speed
• queue priority behavior

If you run bots, you should assume:

Your previous latency assumptions are no longer valid until re-benchmarked

b) Matching behavior drift risk

When matching engines are refactored, subtle things can change:

• price-time priority edge cases
• partial fill behavior
• queue reordering after migration

This is where sophisticated traders quietly lose edge after “non-breaking” upgrades.

3. Liquidity rewards/rebate recalibration = PnL reshaping

Short-term effects

• Temporary yield opportunities (market making becomes subsidized)
• Spread compression (more aggressive quoting)
• Increased competition among liquidity providers

Medium-term effects

• Lower structural spreads
• Reduced “free edge” from rebates
• More efficient but harder-to-trade book

In plain terms

If you were earning easy maker rebate alpha before, that alpha is likely shrinking or being redistributed.

4. Contract address migration = operational risk event

This is the most “prop-trader dangerous” part of the announcement.

They changed:

• collateral adapter smart contract address
• old one will be deprecated

For traders running bots, this creates execution + capital risk:

What can break

• collateral checks failing → orders rejected
• market creation scripts breaking
• funding/settlement flows halting
• API-integrated strategies silently degrade

Real prop trading implication

If your infrastructure isn't updated fast enough, you go temporarily offline, losing alpha and facing classic "protocol migration risk" similar to exchange symbol changes or perpetual contract migrations in crypto.

5. Strategic impact for prop traders

A) Market making becomes more competitive

• Cleaner book + improved incentives = more HFT-style competition
• Edge shifts from “information advantage” → “execution + latency”

B) Signal strategies improve (slightly)

• Order book signals become more reliable
• Less need for heavy filtering of fake liquidity

C) Arbitrage gets tighter

• If CLOB efficiency improved, cross-market inefficiencies would shrink faster
• Arb windows become shorter-lived

D) Infrastructure quality becomes more important than alpha ideas

• robust infra
• fast contract updates
• monitoring systems
• failover handling

Not necessarily better strategy ideas.

6. The real takeaway (for prop traders)

This upgrade shifts from a messy, partially unreliable microstructure to a cleaner but more competitive market structure.

So:

• Beginners may feel the platform is “more stable”
• Market makers will feel margins compress
• Infrastructure-heavy traders will temporarily suffer during migration, but benefit in the long term
• Strategy edges based on UI/latency quirks get partially erased

Bottom line

For prop traders on Polymarket:

• ✔ Better signal quality (no ghost liquidity)
• ✔ More stable execution model (post-migration)
• ✔ Temporary rebate-driven opportunities
• ⚠ Higher infra fragility risk during contract migration
• ⚠ Likely long-term spread compression and tighter competition

If your infrastructure is not updated before the old collateral adapter address is deprecated, your bots will not just underperform. They go silent. That is the kind of quiet failure that costs more than a bad trade. A trading VPS from QuantVPS keeps your systems online and responsive through protocol transitions like this one, so your execution pipeline stays connected when the underlying infrastructure shifts beneath you.

FAQs

How can I tell if a trade was a ghost fill?

A trade might be considered a ghost fill when it seems to have executed off-chain but fails to settle on-chain. Typical signs include mismatches, such as trades missing from on-chain settlements or being reverted because of logic errors. Recent V2 upgrades have specifically tackled these ghost order issues to improve reliability.

Do I need to migrate my USDC to pUSD before trading?

To trade on Polymarket, you'll need to migrate your USDC to pUSD. The platform has switched to using pUSD as its collateral token, meaning all users must convert their balances to align with the updated system. This conversion is necessary to ensure smooth access to trading features and compatibility with the platform's new setup.

What do API traders need to change to work with CLOBv2?

API traders need to make a few updates to stay current. First, ensure your order signing aligns with the new order type. Double-check your verifyingContract addresses to confirm they are correct. Next, transition to using the V2 SDK or the SDK v2 package for compatibility. Lastly, replace the chainId parameter with the chain parameter when working with an options object. These changes are essential for smooth operations.