Core Contracts

Core Contracts

Clanker consists of five main contracts:

1. ClankerToken: A Superchain compatible ERC20 contract.

2. Clanker: The primary contract responsible for token deployment, Uniswap V3 Pool creation, and single-sided liquidity position placement. Users can optionally perform an initial swap and deposit a portion of the token supply into a time-locked vault.

3. ClankerDeployer: A helper library which exists to reduce the code size of the Clanker contract.

4. ClankerVault: A contract for creators to manage and collect their locked tokens.

5. LpLockerv2: A contract for creators to manage and collect their portion of the trading fees generated from their token's pool. This contract is also used by the Clanker team to collect their portion of the trading fees.

Superchain Compatibility

Clanker is SuperchainERC20 compatible such that if a token is deployed on one chain, it can be re-deployed on other compatible super-chains with the same token address. The originatingChainId parameter is used to determine if the initial supply should be minted. If the originatingChainId is not the current chain, zero supply will be minted and users are expected to utilize the super-chain's brige to migrate their tokens. Tokens can only be minted with supply on the originating chain, and cannot be minted with zero supply on the originating chain.

By using Foundry's CREATE2 deployment support, it is ensured that the factory contract (Clanker) can have the same address on different chains. This is needed to have the same resulting token addresses on the different chains.

Superchain documentation can be found here.

For a token to be able to be bridged between Superchain-compatible chains, the chains must be in the same Superchain cluster. This is subject to user error if the Clanker contract is not properly initialized on the target chain, and if the target chain is not part of the same Superchain cluster.

The function deployTokenZeroSupply() can be used to deploy a token with zero supply. This is useful for tokens that are bridged to a Superchain-compatible chain:

// Use the same tokenConfig as that was used to deploy the token on the
// originating chain with the `creatorAdmin as the `tokenAdmin`
function deployTokenZeroSupply(TokenConfig memory tokenConfig, address tokenAdmin) external returns (address tokenAddress) {...}