Uniswap's Continuous Clearing Auction

Overview of the Continuous Clearing Auction

Uniswap released the Continuous Clearing Auction (CCA) in late 2025 as part of its Uniswap Liquidity Launchpad framework. CCA excels at price discovery for new token releases and projects can orchestrate it to seamlessly transition into a Uniswap V4 liquidity bootstrap pool (mostly) on their terms. The very design of the auction forces a ceiling on the number of tokens available for purchase each block, achieving two things:

• A smooth price discovery process
• Bot protection from bulk purchase

Additionally, V4 boasts a versatile secret weapon - hooks. Thanks to hooks, projects can add a great variety of their own customizations to the clearing auction and its exit, such as approved user lists and vesting/release schedules. CCA itself offers projects great variability through its parameters, which can be used in complex and clever ways to achieve sophisticated goals. We'll review a few examples of highly customized token launches at the end of this article.

Bidding

Before we dive into even the fundamental settings, we need to understand bidding and how floor price transitions between blocks. Firstly, you can only purchase the limited number of tokens in the current block with your bid and secondly, whatever total sum you place is spread across all remaining blocks of the CCA. These crucial mechanics provide security against sniping and bulk purchases at the lowest price, as well as ensuring price discovery happens incrementally and with adequate competition. Let's give an example:

We have a CCA for utility tokens with an announced floor price of $0.01 and the current block is the first block. There are a total of 1,000 blocks remaining. When User A places $1,500 with a price of $0.015 per token, the auction contract splits those $1,500 amongst all 1,000 blocks, so the actual funds allocated to purchase tokens from the first block is $1.50. This will allow User A to purchase a maximum of 100 tokens (if available).

Ok, now that we understand how bids are spread out, we have to also consider floor price forwarding across blocks. The starting floor price is set by the project, but hopefully once all bids are collated, a new floor price will be determined by the contract. The new floor price going forward is set by the lowest bid that managed to purchase any quantity of tokens from the last block. Let's give another example:

We have 500 tokens available in a block with a floor price of $0.01. Users A, B and C have all placed bids with prices of $0.0105, $0.0108 and $1.011. Due to the splitting of bid funds, User C, who placed the highest bid, can only purchase 250 tokens from the lot. User B, the next highest bidder, can purchase 200 and the lowest bid, User A's $0.0105, snatches the remaining 50 tokens. User A's bid of $0.0105 is now the new floor price and will be transferred as the floor for Block 2. Crucially, all bids are filled at the price set by User A of $0.0105.

The upside of this approach is the project receives a gradually optimized price of their token, but the total raise they would achieve from the auction is highly unpredictable. Additionally, users have to actively participate and adjust their bids, as the floor price can move above the bid they've placed.

General Setup

Let's start with the basics - what do you need to consider and input to achieve the basic vanilla setup for a continuous clearing auction?

I) Total Blocks

CCAs don't continue for a directly set time limit. Depending on the network you choose, blocks can be medium-fast (Ethereum) to ultrafast (Base Flashblocks) and can turn your auction into a marathon or a sprint. If you want an auction to continue for roughly 3 days, you should see how many blocks your choice network adds for 3 days and set that number as your Total Blocks limit. It's important to strike a balance between the number of tokens per block and the total blocks, so you don't lose out on your price discovery and bot protection by prioritizing the auction duration.

II) Tokens per block

Another fundamental parameter is the tokens per block, which influences your price discovery curve. Too many tokens per block and your price discovery curve can turn more into a step function, too few tokens and you may have a single bid easily filling a full block, which defeats the purpose of CCA.

III) Floor price

The initial floor price depends on the project. Ideally, the floor price should be active only for the first block (or first few blocks) and as bids flow in, the lowest bid filling the block will set the floor price going forward into next blocks. This does not mean the project-set floor price is not influential. It should appear fair and attractive and if bids never surge, it should provide the project with enough liquidity to meet its next key parameter - the Graduation Threshold.

IV) Graduation Threshold

The tie-in between CCA and V4 liquidity pool creation requires a Graduation Threshold for every CCA. It determines the portion of raised funds that will be dedicated to the V4 liquidity pool at the end of the auction. If the Graduation Threshold is not met by the end of the auction, the auction is considered "failed" and participants can claim back their spent funds. No V4 liquidity pool will be automatically created when the auction fails. So why don't projects set a Graduation threshold on the ground? We discuss this at the end of the article.

Two Sale Modes of CCA

I) Launch Week

This is a standard pro-retail sale mode where the sale is done over several days. This allows for easy participation from all timezones and allows users to adjust their bids if the floor price moves against them and deactivates their bid. It's no coincidence Aztec Network took this path and ultimately managed to raise a considerable amount of funds. What makes the balance here difficult is block speeds versus token amount per block - Ethereum might be too slow to allocate a considerable amount of tokens and achieve a big raise. As an alternative, Base offers two possible speeds - the standard 2s speed and Flashblocks 200ms, with Flashblocks gaining more and more popularity as an option.

II) Flash Sale

The idea behind a flash auction is to create urgency as it will be open for a very limited time (e.g. less than 24hrs) and this can incentivize more aggressive bidding. Intuitively, people may think this is a great fit for meme coins, but a flash sale via CCA can be part of a legitimate project's comprehensive marketing strategy. Technology-wise, Flashblocks is an excellent fit for such launches.

Is there a third option? Sure, in simplest terms, you can always stretch an auction on Ethereum easily over weeks, but the use case for such setups is still unclear and untested.

Tips and Tricks

It may at first be daunting to have all these parameters and possible hooks in the CCA, and venturing into a CCA launch may require a project to have both strong tokenomics experts to set up the auction and strong developers to implement the best technical approach. However, the versatility, price discovery and fairer playing field for small investors might be worth it. Here are a few potential tips and tricks:

• The "0" Graduation - to ensure your project doesn't fail and will always exit into a V4 liquidity bootstrap pool, you can set the graduation threshold near $0. However, that will severely limit its initial token contribution and will require quick action on the side of the project or additional engineering to enact stabilizing policies alongside the pool's creation.
• Tokens-per-block augmentation - Your CCA can have multiple stages, or chunks, each with its own token availability. In the initial phase, where price discovery is expected to be most intense, projects may allocate lower rates of tokens *. Conversely, the tail-end of the auction can release more tokens when the price is more established and priced out users have had time to resubmit adjusted bids.
• Empty blocks - You don't have to adjust your block rate upwards only, it may be beneficial to also insert steps with no tokens in them. This will act as a pause in the auction process and will allow users to readjust their bids.
• Vesting - Purchased tokens are by default liquid, but engineering around the CCA is possible that will enable complex structured lock-ups (cliff and vesting) to mitigate excessive early sell pressure. Aztec represents a great example of how to cleverly apply hooks and additional contracts to implement nuanced vesting based on the verification Soulbound Token of the user and their balance (e.g. balances over X tokens vest for Y time).

* Here it's good to clarify CCA in fact uses MPS (Milli-basis-points) - similar to basis points from traditional finance, it splits tokens into more refined smaller units, specifically one thousandth of a basis point or 1e7.

CCA is still new and it makes a versatile and exciting proposal for token launches. As more and more projects leverage it, the full scope of its capabilities will shine through and perhaps new use cases and setups will be discovered. For more on the structure of token sales, check out this article.

Diana Ilieva

Tokenomics Consultant

As a tokenomics consultant, Diana has worked on various projects from utility tokens to stablecoins and tokenization of RWA. Diana excels at custom and business-oriented solutions, adopting best practices from both crypto and tradfi.

Diana comes from an IT background, reaching senior management and heading a team of 23 people.

She has a MSc in Finance and Banking from the University of York and teaches a course in "Financial Markets and Cryptocurrency" at UNWE's Masters programme for "Cryptoeconomics".