Page
https://developers.uniswap.org/docs/liquidity/liquidity-launchpad/deployments
What is wrong?
The ContinuousClearingAuctionFactory section says:
The CCA factory has no constructor parameters so it is deployed to the same address across all compatible chains: Ethereum, Unichain, Base, Arbitrum, Robinhood Chain, and Sepolia.
The same factory address also has code on Avalanche C-Chain (43114), X Layer (196) and Ink (57073). The page is inconsistent with itself here: further down it lists LBPStrategy v3.1.0 on all three of those chains, and LiquidityLauncher v3.0.0 on Avalanche and X Layer. So the chains are supported, but the factory that actually creates the auctions isn't listed for them.
The deployments.json feed has the same gap. It carries liquidity-launchpad-liquiditylauncher-avalanche, liquidity-launchpad-lbpstrategy-avalanche and liquidity-launchpad-tokensplitter-avalanche, but no ContinuousClearingAuctionFactory record for Avalanche, X Layer or Ink. Anything that builds a chain list from that feed will treat Avalanche as unsupported for CCA while auctions are running on it.
Separately, CCALens and TickDataLens (added in v2.0.0, Uniswap/continuous-clearing-auction#325) don't appear on this page or in deployments.json on any chain, even though they're the intended offchain read path.
What should it say instead?
Add Avalanche, X Layer and Ink to the factory's chain list, and add the corresponding records to deployments.json.
The wording could also be more precise: the factory does take a constructor parameter as of v2.0.0 (address _protocolFeeController, Uniswap/continuous-clearing-auction#340). The deployments share an address because they all pass the same value, not because the constructor is empty. I've proposed a fix for that sentence, along with the v1 API names still used in the CCA guides, in #1150.
A CCALens / TickDataLens table would also help. 0xc3C65F5453A3674aDb693cbdA3C842545cD30f53 has code on Ethereum, Avalanche and X Layer, and no code on Ink.
How did you verify this?
I called eth_getCode on 0x000000001F26a0044BaA66024e7b6599c61963F8 on each chain. All of them return the same 24214 bytes, keccak 0xa1d2a90564f4f63580b25de42efaff92505c254b00fc666f65ab38126cce5cfa:
| Chain |
chainId |
code |
| Ethereum |
1 |
yes |
| Unichain |
130 |
yes |
| Base |
8453 |
yes |
| Arbitrum |
42161 |
yes |
| Avalanche C-Chain |
43114 |
yes |
| X Layer |
196 |
yes |
| Ink |
57073 |
yes |
On Avalanche it was deployed at block 89973362 (2026-07-10) via the canonical CREATE2 deployer 0x4e59b44847b379578588920ca78fbf26c0b4956c, and it's in use: at least 15 AuctionCreated events (topic0 0x7ede475f…), the first at block 90900708 on 2026-07-21, 13 more on 2026-08-11 and one on 2026-08-14. I pulled one of them straight from the node to confirm — tx 0x3d6bd31ad9e90bc2768bdcf24ce046b466d6dd86690075d23eb46a63e86b50f3, called through LiquidityLauncher, status 1, one AuctionCreated log from the factory.
For the constructor point: protocolFeeController() (0xf02de3b2) is present in the deployed bytecode and returns the zero address on both Ethereum and Avalanche.
To reproduce the first part:
for rpc in https://ethereum-rpc.publicnode.com https://api.avax.network/ext/bc/C/rpc https://rpc.xlayer.tech https://rpc-gel.inkonchain.com; do
curl -s -X POST "$rpc" -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x000000001F26a0044BaA66024e7b6599c61963F8","latest"]}' \
| head -c 80; echo " <- $rpc"
done
Page
https://developers.uniswap.org/docs/liquidity/liquidity-launchpad/deployments
What is wrong?
The ContinuousClearingAuctionFactory section says:
The CCA factory has no constructor parameters so it is deployed to the same address across all compatible chains: Ethereum, Unichain, Base, Arbitrum, Robinhood Chain, and Sepolia.
The same factory address also has code on Avalanche C-Chain (43114), X Layer (196) and Ink (57073). The page is inconsistent with itself here: further down it lists LBPStrategy v3.1.0 on all three of those chains, and LiquidityLauncher v3.0.0 on Avalanche and X Layer. So the chains are supported, but the factory that actually creates the auctions isn't listed for them.
The deployments.json feed has the same gap. It carries liquidity-launchpad-liquiditylauncher-avalanche, liquidity-launchpad-lbpstrategy-avalanche and liquidity-launchpad-tokensplitter-avalanche, but no ContinuousClearingAuctionFactory record for Avalanche, X Layer or Ink. Anything that builds a chain list from that feed will treat Avalanche as unsupported for CCA while auctions are running on it.
Separately, CCALens and TickDataLens (added in v2.0.0, Uniswap/continuous-clearing-auction#325) don't appear on this page or in deployments.json on any chain, even though they're the intended offchain read path.
What should it say instead?
Add Avalanche, X Layer and Ink to the factory's chain list, and add the corresponding records to deployments.json.
The wording could also be more precise: the factory does take a constructor parameter as of v2.0.0 (address _protocolFeeController, Uniswap/continuous-clearing-auction#340). The deployments share an address because they all pass the same value, not because the constructor is empty. I've proposed a fix for that sentence, along with the v1 API names still used in the CCA guides, in #1150.
A CCALens / TickDataLens table would also help. 0xc3C65F5453A3674aDb693cbdA3C842545cD30f53 has code on Ethereum, Avalanche and X Layer, and no code on Ink.
How did you verify this?
I called
eth_getCodeon0x000000001F26a0044BaA66024e7b6599c61963F8on each chain. All of them return the same 24214 bytes, keccak0xa1d2a90564f4f63580b25de42efaff92505c254b00fc666f65ab38126cce5cfa:On Avalanche it was deployed at block 89973362 (2026-07-10) via the canonical CREATE2 deployer
0x4e59b44847b379578588920ca78fbf26c0b4956c, and it's in use: at least 15 AuctionCreated events (topic00x7ede475f…), the first at block 90900708 on 2026-07-21, 13 more on 2026-08-11 and one on 2026-08-14. I pulled one of them straight from the node to confirm — tx0x3d6bd31ad9e90bc2768bdcf24ce046b466d6dd86690075d23eb46a63e86b50f3, called through LiquidityLauncher, status 1, one AuctionCreated log from the factory.For the constructor point:
protocolFeeController()(0xf02de3b2) is present in the deployed bytecode and returns the zero address on both Ethereum and Avalanche.To reproduce the first part: