Continuous Clearing Auctions (CCA): Technical Overview

Continuous Clearing Auctions (CCA) are an on-chain auction protocol designed by Uniswap (Universal Navigation Inc.) to conduct multi-period token sales with automated liquidity bootstrapping into a Uniswap v4 pool. Projects configure a sale that runs over many discrete auction blocks; bidders submit size–price instructions that are split across blocks, and each block clears at a uniform “market” price based on the submitted demand.

The protocol is implemented as a separate smart-contract system (“Continuous Clearing Auction” + factory) and is intended to be used together with the Uniswap Liquidity Launcher. The Aztec Network public token sale is the first large production use of this mechanism.

1. Mechanism Outline

1.1 Setup

A project defines at minimum:

• Total tokens to sell Q_total
• Auction duration (number of blocks or time range)
• Initial guidance parameters (e.g., starting price, optional price floor or reserve curve)
• Graduation conditions / completion checks (for example: minimum capital raised, minimum average price, or other criteria)
• Liquidity seeding rules (e.g., what fraction of raised assets and remaining tokens are deposited into a Uniswap v4 pool at the end)

The auction smart contract then acts as the sole seller of the token during the sale window.

1.2 Bid Model

A bidder submits a single order specifying:

• Maximum spend or desired quantity
• Maximum acceptable price P_max
• (Optionally) additional preferences such as minimum fill size

The protocol conceptually “spreads” this bid across all remaining auction blocks. In each block, a portion of the bid participates in price discovery.

For a given block t:

• Let S_t be the token supply allocated to block t
• Let B_t be the multiset of active bid slices for block t, each with (P_max_i, Q_i^t)

The block’s clearing price P_clear_t is the lowest price such that cumulative demand at or above that price weakly exceeds S_t.

Formally, if we sort all P_max_i in descending order and accumulate the corresponding Q_i^t until:

[ \sum_{i: P_{\text{max},i} \ge P_{\text{clear},t}} Q_i^t \ge S_t ]

then P_clear_t is the threshold price for that block.

All filled slices in block t transact at P_clear_t, subject to pro-rata scaling when demand at or above the clearing price strictly exceeds S_t.

1.3 Pro-Rata Allocation at the Margin

If the last price level that allows filling the block is oversubscribed, the protocol scales allocations of bidders at that exact threshold price:

• Let D_strict be total demand from bids with P_max > P_clear_t
• Let D_equal be total demand from bids with P_max = P_clear_t
• If D_strict ≥ S_t, then all volume is filled strictly above the threshold and a slightly higher clearing price is chosen.
• Otherwise, the remaining capacity is S_t - D_strict. Bids at P_clear_t are scaled:

[ \text{allocation}i = Q_i^t \times \frac{S_t - D{\text{strict}}}{D_{\text{equal}}} ]

All allocations pay exactly P_clear_t.

1.4 Max-Price Safety

For every bidder i and every block t, if:

[ P_{\text{clear},t} > P_{\text{max},i} ]

then their slice for that block is not executed. Unused slices remain available for future blocks (as long as the auction is ongoing) or can be withdrawn according to the sale’s rules.

2. Simple Numerical Example

Assume:

• Single-block auction (for simplicity)
• Supply in this block: S = 1,000 tokens
• 10 participants, each with (P_max, Q) as below

2.1 Raw Bids

2.2 Order Book by Descending P_max

Sort bidders by decreasing P_max and compute cumulative demand:

We first cross the supply S = 1,000 when including B. This implies clearing price:

[ P_{\text{clear}} = 2.20 ]

Eligible bidders are those with P_max ≥ 2.20:

• G: 500
• D: 400
• B: 200

Total eligible demand:

[ D_{\text{eligible}} = 500 + 400 + 200 = 1{,}100 ]

Pro-rata factor on the margin:

[ \alpha = \frac{S}{D_{\text{eligible}}} = \frac{1{,}000}{1{,}100} \approx 0.909 ]

2.3 Final Allocations

• All other participants receive zero in this block.
• No one pays above their specified P_max.
• Every filled unit transacts at the same uniform price 2.20.

A multi-block auction generalizes this logic by re-running the clearing process for each block with its share of tokens and the active bid slices.

3. Integration With Uniswap v4 and Liquidity Bootstrapping

In Uniswap’s implementation:

• CCA is exposed as a distinct protocol, but is designed to feed directly into a Uniswap v4 pool via hooks at the end of the sale.
• The final auction state (total capital raised, terminal clearing price, remaining tokens) is used to parameterize an initial liquidity position.
• The auction thus serves both as a price-discovery phase and as a way to pre-fund the pool, avoiding a separate “figure out liquidity later” step.

The Aztec sale uses this infrastructure, with the CCA contract handling price discovery and a dedicated “Aztec: Continuous Clearing Auction” contract address on Ethereum tracking bids and fills.

4. Comparison With Other Token Sale Mechanisms

4.1 Fixed-Price Sales

• Project sets a single sale price ex-ante.
• First-come-first-served fills the allocation until exhausted.
• Latency and gas-bidding advantages dominate early access.
• Mispricing is common: either the issuer leaves capital on the table or buyers immediately see slippage once secondary trading starts.

CCA contrast:

• Clearing price is endogenously determined from the order book per block.
• Allocation is based on price tolerance, not transaction speed.
• Final price is by construction consistent with the aggregate demand profile.

4.2 Dutch Auctions (Descending Price)

• Price starts high and ticks downward over time.
• Rational bidders attempt to wait for lower prices but not so long that supply runs out.
• Strategic timing and block-level sniping play a large role.
• The observed clearing price may reflect game-theoretic timing rather than a best estimate of long-run value.

CCA contrast:

• Bidders state their P_max once; their bids are sliced across blocks.
• No requirement to monitor and re-submit as price changes.
• Clearing is continuous in blocks, not a single descending path; the mechanism is closer to repeated uniform-price auctions than a single Dutch clock.

4.3 One-Shot Uniform-Price (Sealed-Bid) Auctions

• All bids submitted once.
• A single clearing price is computed, with pro-rata scaling at the margin.
• Does not naturally bootstrap AMM liquidity; often followed by a separate pool-creation transaction.
• No intra-auction adaptation: bidders cannot react to emerging information between blocks.

CCA contrast:

• Keeps the uniform-price property but repeats clearing over many intervals.
• Facilitates automated connection to a Uniswap v4 pool at completion.
• Allows longer sale windows with evolving participation while still computing a clear per-block price.

4.4 AMM Instant Listings (e.g., Direct Uniswap v3/v4 Pool Launch)

• Tokens are deposited into a pool and trading goes live immediately.
• Early trades suffer from thin liquidity and high slippage.
• MEV and mempool competition strongly influence the realized “launch price.”
• No explicit notion of a clearing price or ordered demand curves.

CCA contrast:

• Trading is replaced by explicit bidding during the sale.
• Price discovery happens via order-book style aggregation rather than a constant-product curve.
• The terminal clearing state is then used to parameterize the pool, separating “sale” from “secondary trading” phases.

5. Relation to the Aztec Token Sale

• The Aztec Network public auction terms describe the use of a “novel Uniswap Continuous Clearing Auction (CCA) format,” designed to reduce price manipulation and foster open, on-chain price discovery.
• Bids for the Aztec sale are placed via the CCA contract, which periodically computes clearing prices and token allocations.
• After the sale, remaining tokens plus a portion of funds raised are expected to seed a Uniswap v4 pool, as per the CCA + Liquidity Launcher design.

Sources

1. Uniswap – Continuous Clearing Auctions: Bootstrapping Liquidity on Uniswap v4 (official blog) https://blog.uniswap.org/continuous-clearing-auctions

2. Uniswap – Continuous Clearing Auctions Product Page https://cca.uniswap.org/en/

3. Uniswap – Continuous Clearing Auction Smart-Contract Repository (GitHub) https://github.com/Uniswap/continuous-clearing-auction

4. Aztec Network – Auction Terms and Conditions https://aztec.network/auction-terms-conditions

5. Markets.com – Continuous Clearing Auction: New Asset Price Discovery With Uniswap and Aztec https://www.markets.com/news/continuous-clearing-auction-uniswap-aztec-2195-en

6. The Defiant – Aztec Network Launches First Token Sale Using Uniswap’s Continuous Clearing Auction https://thedefiant.io/news/defi/aztec-network-launches-first-token-sale-using-uniswaps-continuous-clearing-auction

7. Algebra (Medium) – Continuous Clearing Auctions: A New Standard for Fair Token Launches by Uniswap & Aztec https://medium.com/@crypto_algebra/continuous-clearing-auctions-a-new-standard-for-fair-token-launches-by-uniswap-aztec-739ba1767fd7

8. Uniswap CCA Aztec Contract Instance (Etherscan) https://etherscan.io/address/0x608c4e792C65f5527B3f70715deA44d3b302F4Ee

9. Panews – A Detailed Look at the Unique Features of Uniswap’s New CCA https://www.panewslab.com/en/articles/50611532-a7d8-4f14-ad67-b460319bc720

10. Dennison Bertram – X Thread Explaining the Aztec CCA Sale https://x.com/dennisonbertram/status/1995911827171991948?s=46

Post created via email from emin@nuri.com