chore: add CCA sections to liquidity launchpad docs

docs/contracts/liquidity-launchpad/01-introduction.md

@@ -86,13 +86,3 @@ The following actions must be performed atomically within one transaction.
 
 - Learn about the [Continous Clearing Auction](./05-auction-mechanism.md) mechanism
 - Read the <a href='/whitepaper_cca.pdf' target='_blank' rel='noopener noreferrer'>whitepaper</a> to learn more about the mechanism
-
-## Smart Contracts
-
-| Contract | Description | Source | Mainnet Address | Unichain |
-|----------|-------------|--------|-----------------|----------|
-| **LiquidityLauncher** | Central orchestration contract | [liquidity-launcher](https://github.com/Uniswap/liquidity-launcher) | [0x00000008412db3394C91A5CbD01635c6d140637C](https://etherscan.io/address/0x00000008412db3394C91A5CbD01635c6d140637C) | Coming soon |
-| **UERC20Factory** | Standard ERC-20 token factory | [uerc20-factory](https://github.com/Uniswap/uerc20-factory) | [0x0cde87c11b959e5eb0924c1abf5250ee3f9bd1b5](https://etherscan.io/address/0x0cde87c11b959e5eb0924c1abf5250ee3f9bd1b5) | Coming soon |
-| **LBPStrategyBasicFactory** | LBP strategy factory | [liquidity-launcher](https://github.com/Uniswap/liquidity-launcher) | [0x00000010F37b6524617b17e66796058412bbC487](https://etherscan.io/address/0x00000010F37b6524617b17e66796058412bbC487) | Coming soon |
-| **ContinuousClearingAuction** | Continuous clearing auction factory | [continuous-clearing-auction](https://github.com/Uniswap/continuous-clearing-auction) |[0x0000ccaDF55C911a2FbC0BB9d2942Aa77c6FAa1D](https://etherscan.io/address/0x0000ccaDF55C911a2FbC0BB9d2942Aa77c6FAa1D) | Coming soon |
-| **Permit2** | Token approval manager | [Uniswap](https://github.com/Uniswap/permit2) | [0x000000000022D473030F116dDEE9F6B43aC78BA3](https://etherscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) | [0x000000000022D473030F116dDEE9F6B43aC78BA3](https://etherscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |

docs/contracts/liquidity-launchpad/02-deployments.md

@@ -0,0 +1,81 @@
+---
+id: Deployments
+title: Deployments
+sidebar_position: 2
+---
+
+# Deployments
+View the changelogs for more details on differences between contract deployments: [continuous-clearing-auction](https://github.com/Uniswap/continuous-clearing-auction/blob/main/CHANGELOG.md) and [liquidity-launcher](https://github.com/Uniswap/liquidity-launcher/blob/main/CHANGELOG.md).
+
+## ContinuousClearingAuctionFactory
+The CCA factory has no constructor parameters so it can be deployed to the same address across all compatible chains.
+
+| Network  | Address                                    | Commit Hash                              | Version          |
+| -------- | ------------------------------------------ | ---------------------------------------- | ---------------- |
+| v1.1.0   | 0xcca1101C61cF5cb44C968947985300DF945C3565 | 95d7da7a2d25cf60f14eaccd6ab5fb24d393a452 | v1.1.0           |
+| v1.0.0\* | 0x0000ccaDF55C911a2FbC0BB9d2942Aa77c6FAa1D | 154fd189022858707837112943c09346869c964f | v1.0.0-candidate |
+> \*v1.0.0-candidate is the initial version of CCA and is NOT recommended for production use. See the [Changelog](https://github.com/Uniswap/continuous-clearing-auction/blob/main/CHANGELOG.md) for more details.
+
+## LiquidityLauncher
+The LiquidityLauncher is a singleton contract which is delployed to the same address across all compatible chains.
+
+| Version  | Address | Commit Hash |
+| -------- | ------------------------------------------ | ---------------------------------------- |
+| v1.0.0  | 0x00000008412db3394C91A5CbD01635c6d140637C | fd5be9b7a918ca3d925d985dff9bcde82b3b8a9d |
+
+## LBP Strategies
+LBP strategies are deployed via factory contracts which are deployed to different addresses on different chains. Make sure to use the correct factory contract for the chain in question.
+
+### FullRangeLBPStrategyFactory
+The FullRangeLBPStrategyFactory is a factory contract for the [FullRangeLBPStrategy]().
+
+| Version | Chain | Address | Commit Hash |
+|---------|-------|---------|------------|
+| v2.0.0 | Mainnet | 0x65aF3B62EE79763c704f04238080fBADD005B332 |  |
+| v2.0.0 | Unichain | 0xAa56d4d68646B4858A5A3a99058169D0100b38e2 | |
+| v2.0.0 | Base | 0x39E5eB34dD2c8082Ee1e556351ae660F33B04252 |  |
+| v2.0.0 | Sepolia | 0x89Dd5691e53Ea95d19ED2AbdEdCf4cBbE50da1ff |  |
+
+### AdvancedLBPStrategyFactory
+The AdvancedLBPStrategyFactory is a factory contract for the [AdvancedLBPStrategy]().
+
+| Version | Chain | Address | Commit Hash |
+|---------|-------|---------|------------|
+| v2.0.0 | Mainnet | 0x982DC187cbeB4E21431C735B01Ecbd8A606129C5 |  |
+| v2.0.0 | Unichain | 0xeB44195e1847F23D4ff411B7d501b726C7620529 | |
+| v2.0.0 | Base | 0x9C5A6fb9B0D9A60e665d93a3e6923bDe428c389a |  |
+| v2.0.0 | Sepolia | 0xdC3553B7Cea1ad3DAB35cBE9d40728C4198BCBb6 |  |
+
+## Previous Deployments
+The following contracts are deprecated and are not recommended for production use. See the [Changelog](https://github.com/Uniswap/liquidity-launcher/blob/main/CHANGELOG.md) for more details.
+
+### LBPStrategyBasicFactory
+The LBPStrategyBasicFactory is a factory contract for the [LBPStrategyBasic]().
+
+| Network | Address | Commit Hash | Version |
+|---------|---------|------------|---------|
+| Mainnet | 0xbbbb6FFaBCCb1EaFD4F0baeD6764d8aA973316B6 | fd5be9b7a918ca3d925d985dff9bcde82b3b8a9d | v1.0.0-candidate |
+| Base | 0xC46143aE2801b21B8C08A753f9F6b52bEaD9C134 | fd5be9b7a918ca3d925d985dff9bcde82b3b8a9d | v1.0.0-candidate |
+| Unichain | 0x435DDCFBb7a6741A5Cc962A95d6915EbBf60AE24 | fd5be9b7a918ca3d925d985dff9bcde82b3b8a9d | v1.0.0-candidate |
+
+### VirtualLBPStrategyFactory
+
+| Network | Address | Commit Hash | Version |
+|---------|---------|------------|---------|
+| Mainnet | 0x00000010F37b6524617b17e66796058412bbC487 | fd5be9b7a918ca3d925d985dff9bcde82b3b8a9d | v1.0.0-candidate |
+| Sepolia | 0xC695ee292c39Be6a10119C70Ed783d067fcecfA4 | fd5be9b7a918ca3d925d985dff9bcde82b3b8a9d | v1.0.0-candidate |
+
+
+## UERC20Factory
+The UERC20Factory is a factory contract for new UERC20 tokens.
+
+| Version                                     | Address                                    | Commit Hash                              |
+| -------- | ------------------------------------------ | ---------------------------------------- |
+| v1.0.0  | 0x0cde87c11b959e5eb0924c1abf5250ee3f9bd1b5 | 9705debfea9e6a641bc04352398f9e549055ac44 |
+
+## USUPERC20Factory
+The USUPERC20Factory is a factory contract for new Superchain compatible UERC20 tokens. It is deployed to the same address across all Superchain compatible L2s.
+
+| Version                                     | Address                                    | Commit Hash                              |
+| -------- | ------------------------------------------ | ---------------------------------------- |
+| v1.0.0  |  | 9705debfea9e6a641bc04352398f9e549055ac44 |

docs/contracts/liquidity-launchpad/04-auction-mechanism.md

@@ -0,0 +1,92 @@
+---
+id: CCA
+title: Continuous Clearing Auction
+sidebar_position: 3
+---
+
+# Continuous Clearing Auction (CCA)
+
+**Repository:** [github.com/Uniswap/continuous-clearing-auction](https://github.com/Uniswap/continuous-clearing-auction)
+
+The Continuous Clearing Auction (CCA) is a novel auction mechanism that generalizes the uniform-price auction into continuous time. It provides fair price discovery for bootstrapping initial liquidity while eliminating timing games and encouraging early participation (see [whitepaper](/whitepaper_cca.pdf)).
+
+## Overview
+
+Bootstrapping initial liquidity for new tokens is challenging. Traditional approaches suffer from various weaknesses:
+- **Fixed-price sales** lead to mispricing and priority races, creating thin or unstable liquidity
+- **Dutch auctions** create timing games and favor professionals over genuine participants
+- **One-shot auctions** enable demand reduction and last-minute sniping
+- **Bonding curves** are path-dependent and vulnerable to manipulation
+- **Centralized market makers** require trust and extract significant value
+
+CCA addresses these issues through a unique approach: **automatic bid spreading over time** combined with **continuous price discovery**.
+
+### Mechanism overview
+
+For a detailed overview, please read the [whitepaper](/whitepaper_cca.pdf).
+
+The most important element to understand about a Continuous Clearing Auction (CCA) is that tokens are sold over time to the current set of active participants. Participants are comprised of two things, a budget and a max price. 
+
+The clearing price of the auction in a block is the price which all bidders in that block pay. This is the same concept as in uniform price auctions. But in CCA this price is gradually discovered over time. Every block, some number of tokens (as defined by the configured release schedule) are allocated to bids with higher max prices, then those with lower max prices. 
+
+Because we require users to specify a maximum price, there exists a clearing price for which there are not enough "active" participants in the auction to purchase all of the tokens that are being sold, since a bid is removed from the auction once it falls below the clearingPrice. The current price of the auction will always be just below this price, ensuring that all of the supply can be sold to the current set of bids.
+
+At a high level it has these benefits:
+- No participant can concentrate demand at a single moment
+- Timing of bid submission matters less than valuation
+- Early bidders naturally gain more exposure to lower prices
+- Sniping and last-minute gaming become ineffective
+
+## Technical overview
+Check out the full [technical reference](TODO)
+
+## Integration guidelines
+
+### Incorrect configuration of the auction parameters
+
+CCA auctions are highly configurable. As such, it is important to ensure that the configurations of each auction instance are not only correct but protect against known risks.
+
+Ensure that the following parameters are correctly set:
+
+- `token` and `currency`
+- `totalSupply` is not too large (see [note on total supply and maximum bid price](#note-on-total-supply-and-maximum-bid-price) below)
+- `startBlock`, `endBlock`, and `claimBlock`
+- `tickSpacing` is not too small (see [note on ticks](#note-on-ticks) below)
+- `floorPrice` is correctly set
+- `requiredCurrencyRaised` is not set too high where the auction will never graduate
+- `auctionStepsData` avoids common pitfalls (see [note on auction steps](#note-on-auction-steps) below)
+
+### Extra funds sent to the auction are not recoverable
+Do NOT send more tokens than intended in `totalSupply` to the auction. They will not be recoverable.
+
+Likewise, any `currency` sent directly to the auction and not through `submitBid` will not be lost.
+
+### Note on total supply and maximum bid price
+
+The following limitations regarding total supply and maximum bid prices should be considered:
+
+- The maximum total supply that can be sold in the auction is 1e30 wei of `token`. For a token with 18 decimals, this is 1 trillion tokens.
+- The auction also ensures that the total currency raised does not exceed the maximum allowable liquidity for a Uniswap v4 liquidity position. The lowest bound for this is 2^107 wei (given the smallest possible tick spacing of 1).
+
+Given a total supply of:
+
+- 1 trillion 18 decimal tokens (1e30), the maximum bid price is 2^110. The max ratio of currency to token is 2^(110-96) = 2^14 = 16384.
+- 1 billion 6 decimal tokens (1e15), the maximum bid price is 2^160. The max ratio of currency to token is 2^(160-96) = 2^64 = 18446744073709551616.
+
+We strongly recommend that the `currency` is chosen to be more valuable than `token`, and that the total supply is not excessively large.
+
+### Note on ticks
+
+Ticks in the auction govern where bids can be placed. They have no impact on the potential clearingPrices of the auction and merely serve to prevent users from being outbid by others by infinitesimally small amounts and for gas efficiency in finding new clearing prices.
+
+Generally integrators should choose a tick spacing of AT LEAST 1 basis point of the floor price. 1% or 10% is also reasonable.
+
+Setting too small of a tick spacing will make the auction extremely gas inefficient, and in specific cases, can result in a DoS attack where the auction cannot finish.
+
+### Note on auction steps
+
+Steps in the auction create the supply issuance schedule. Generally each step should be monotonically increasing in the amount of tokens sold, and the last block of the auction MUST sell a significant amount of tokens.
+
+This is because the final clearing price of the auction is used to initialize a Uniswap v4 liquidity pool, and if only a small number of tokens are sold at the end, the final price will be easy to manipulate.
+
+See the [whitepaper](./docs/assets/whitepaper.pdf) for more details.