Skip to content

fix(liquidity-launchpad): update CCA factory API to v2.x - #1150

Open
bertankofon wants to merge 1 commit into
Uniswap:mainfrom
bertankofon:fix/cca-factory-api-drift
Open

fix(liquidity-launchpad): update CCA factory API to v2.x#1150
bertankofon wants to merge 1 commit into
Uniswap:mainfrom
bertankofon:fix/cca-factory-api-drift

Conversation

@bertankofon

Copy link
Copy Markdown

Summary

The CCA guides still document the v1 factory API, so the sample scripts don't compile against the deployed contracts. v2.0.0 renamed the entrypoints and added a fee controller argument to the constructors.

Affected pages:

What the guides say vs. what v2.x has:

  • initializeDistribution() ‚Üí create()
  • getAuctionAddress() ‚Üí getAddress()
  • IDistributionStrategy / IDistributionContract ‚Üí IDistributorFactory / IDistributor, from liquidity-launcher
  • new ContinuousClearingAuctionFactory() ‚Üí constructor takes address _protocolFeeController
  • auction constructor(address, uint128, AuctionParameters) ‚Üí takes a fourth address _protocolFeeController

Both changes are in the v2.0.0 changelog: #356 for the renames, #340 for the fee controller.

The Deployments page also says the factory "has no constructor parameters". It takes one — the canonical deployments land on the same address because they all pass the same value, not because the constructor is empty.

Type of change

  • Fix (typo, broken link, incorrect or outdated content)
  • New content (guide, page, code example)
  • Update to existing content
  • Other

How has this been verified?

I checked the deployed v2.1.0 factory at 0x000000001F26a0044BaA66024e7b6599c61963F8. Its runtime bytecode contains the selectors for create() (0x4aaa5b37), getAddress() (0x1bfb751b) and protocolFeeController() (0xf02de3b2), and does not contain 0x03770504 (initializeDistribution) or 0xbad1bd50 (getAuctionAddress) — so the documented calls would revert.

eth_getCode returns identical bytecode on Ethereum, Unichain, Base, Arbitrum and Avalanche (codehash 0xa1d2a90564f4f63580b25de42efaff92505c254b00fc666f65ab38126cce5cfa). protocolFeeController() returns the zero address on both Ethereum and Avalanche, which is why one address still works everywhere.

For the snippets: the import paths I used are already remapped in the CCA repo's foundry.toml (liquidity-launcher=lib/liquidity-launcher), and onTokensReceived(), used later in the example configuration, is declared on IDistributor.

Anything else reviewers should know?

Two related things I ran into but didn't touch here, since they don't live in this repo's content:

  1. The Deployments page lists the factory on Ethereum, Unichain, Base, Arbitrum, Robinhood Chain and Sepolia. The same address also has code on Avalanche (43114), X Layer (196) and Ink (57073), and deployments.json has no factory record for those three — although it does list LiquidityLauncher, LBPStrategy and TokenSplitter on Avalanche.
  2. CCALens and TickDataLens (added in Fixed typos #325) aren't on the Deployments page or in deployments.json on any chain.

Happy to open a separate issue for those if that's easier to track.

The factory entrypoints were renamed in continuous-clearing-auction v2.0.0
(initializeDistribution -> create, getAuctionAddress -> getAddress, PR Uniswap#356)
and the factory/auction constructors gained a protocolFeeController argument
(PR Uniswap#340). The guides still document the v1 API, so the sample scripts no
longer compile against the deployed contracts.
@github-actions

Copy link
Copy Markdown

Thanks for contributing to Uniswap Docs! 🦄

Quick heads up on how this repo works: the docs you see on developers.uniswap.org are built from a separate source repo. When we accept a change here, we port it over there, so your fix might show up on the live site before it lands in this repo.

Updates to this repo come in batches on a regular cadence. When yours is included, you'll be credited as a co-author on the commit, so the contribution counts on your GitHub profile and in Uniswap/docs.

We review every PR but can't merge everything. Either way, someone from the docs team will follow up here once we've taken a look.

One legal bit: by submitting a PR you agree your contribution is licensed under the repo's MIT license.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant