Uniform Clearing Price

What it is

A uniform clearing price mechanism collects a batch of buy and sell orders over a fixed window, then computes one single price that clears (matches) as much volume as possible, and settles every order at that same price. This is different from a standard order book or AMM, where each trade can execute at a slightly different price depending on when it arrived and how much liquidity was available.

How it works

1. Orders (bids to buy, asks to sell, sometimes with limit prices) accumulate during a collection window instead of executing immediately.
2. Once the window closes, the mechanism looks across all submitted orders and finds the single price at which total demand and total supply are as close to balanced as possible — the "clearing price."
3. Every order that would still transact profitably at that price is filled at exactly that price, regardless of whether the trader was willing to accept a worse one.
4. Orders that wouldn't clear at that price (e.g., a buy limit below the clearing price) are left unfilled or partially filled.
5. Unfilled portions either roll into the next batch, get cancelled, or (in an ICO/Dutch-auction context) simply don't receive an allocation.
6. Settlement happens atomically on-chain in one transaction (or one round), so no participant can react to others' fills within the same batch.

Why designers use it

• Removes the incentive to race for a better price than the next trader in the same round, since price is uniform.
• Blunts front-running and sandwich attacks: because orders are batched and priced together, seeing an order before settlement doesn't let an attacker insert a trade ahead of it at a better price.
• Produces a fair, auditable settlement price that all participants can verify came from the actual submitted order flow.
• Useful for price discovery in illiquid or one-shot markets (token sales, liquidations) where a continuous order book would be too thin.

Failure modes

• If the batch window is long, information leaks (e.g., off-chain chatter about pending orders) and sophisticated participants adjust bids to game the clearing price before it's set.
• If order flow is thin, the clearing price can be manipulated by a single large order that shifts where supply and demand cross.
• Participants who wanted quick execution are forced to wait for the batch to close, which can be a poor user experience during volatile markets.
• Partial fills at the clearing price can create UX confusion if traders expected all-or-nothing settlement.
• If the matching algorithm isn't specified precisely (e.g., tie-breaking rules for orders at the boundary), disputes arise over who got filled and why.

What to check before using it

• Is the batch window length appropriate for the asset's volatility — long enough to gather real demand, short enough to avoid stale prices?
• How are ties and partial fills at the clearing price resolved (pro-rata, time priority, random)?
• Can a single actor submit an order large enough to move the clearing price meaningfully, and is that acceptable?
• Is the clearing computation verifiable on-chain, or does it rely on a trusted off-chain solver whose output must be checked?
• What happens to unfilled orders — do they roll forward, expire, or refund automatically?