v4.0.0

Overview of Clanker's v4.0.0 contracts

Clanker v4.0.0 introduces a modular framework, allowing for individual components that can be swapped out and upgraded as needed. The code can be found here.

Core Contracts

Clanker v4.0.0 consists of three main contracts that are non-upgradeable and can be expected to remain unchanged throughout the lifetime of v4.0.0:

  • Clanker: The factory contract responsible for token deployment, triggering pool creation, triggering liquidity placement via the LpLocker, and triggering extensions.

  • ClankerFeeLocker: A contract that allows users to view and claim their accumulated token fees. This single contract accrues fees for all tokens deployed on Clanker v4.0.0.

  • ClankerToken: A super-chain compatible ERC20 contract. A new contract is deployed for every call to deployToken().

Clanker v4.0.0 additionally defines four interfaces with which the Clanker factory interfaces:

  • IClankerLpLocker: An interface for liquidity lockers to implement to be compatible with Clanker's v4.0.0 factory. The implementation is expected to manage placement of LP positions as well as collection and distribution of fees to the ClankerFeeLocker.

  • IClankerExtensions: An interface for extensions to implement to be compatible with Clanker's v4.0.0 factory. These modules are used to add additional functionality to the token deployment process outside of LP and pool management.

  • IClankerMevModule: An interface for MEV modules to implement to be compatible with Clanker's v4.0.0 factory. These modules are developed by the Clanker team per chain to help with MEV scenarios.

  • IClankerHook: An interface for Uniswap v4 Hooks to implement to be compatible with the Clanker factory. These hooks are expected to contain custom logic for Clanker such as implementing our protocol fee and aiding with automatic fee collection.

All of the implementations must be allowlisted on the Clanker factory by the team to be used in deployments.

Modular Contracts

Clanker v4.0.0 includes the following contracts which implement the interfaces and are ready for use on v4.0.0 launch. These contracts are designed to be upgraded and can change.

IClankerHooks:

  • ClankerHook: An abstract implementation of IClankerHook which contains the implementation for Clanker's protocol fee, automatic fee claiming abilities, MEV module abilities, and fee customization abilities which the static and dynamic hooks build on top of.

  • ClankerHookStaticFee: An extension of the ClankerHook which enables users to set a static fee for both the deployed token and the paired token.

  • ClankerHookDynamicFee: An extension of the ClankerHook which enables users to configure a dynamic fee that adjusts based on the amount of volatility in the pool.

IClankerLPLockers:

  • ClankerLpLockerMultiple: A locker implementation which enables 7 different reward recipients to be specified and 7 different initial LP positions to be placed. This locker works with the ClankerHook implementation to automatically collect LP fees on every swap and distribute the fees to reward recipients via the ClankerFeeLocker.

IClankerExtensions:

  • ClankerVault: An extension that allows deployers to vault a portion of the token supply with an optional linear vest option post-unlock. The minimum lockup time is 7 days.

  • ClankerAirdrop: An extension which allows for a portion of the token supply to be allocated to airdrop recipients. Users of the extension must supply a merkle root whose leaves contain the airdrop recipient and the amount of tokens each recipient is entitled to. Lockup and linear vesting options are also available. The minimum lockup time is 1 day.

  • ClankerUniv4EthDevBuy: An extension which allows the deployer to perform an initial swap of the token using passed-in ETH. If the paired token for the pool is not WETH, only paired tokens which have a WETH<>PairedToken UniswapV4 pool will be able to use this extension.

IClankerMevModule:

  • ClankerMevModule2BlockDelay: A MEV module which makes the pool non-swappable for the first 2 blocks after deployment. This prevents people from front-running deployments in the same block of creation.

Last updated