# Introduction to Clanker Clanker is a set of audited smart contracts that create token markets which reward token creators. Currently, Clanker deploys ERC-20 tokens on [EVM chains](https://clanker.gitbook.io/clanker-documentation/references/deployed-contracts) in a few ways: 1. Farcaster users may request [@clanker](https://warpcast.com/clanker) on Farcaster to deploy a token or on X by tagging [@clanker\_world](https://x.com/clanker_world) with token details. 2. Users may use the [clanker.world](https://www.clanker.world/) frontend interface and Farcaster Mini App to deploy a token. 3. Developers may create their own token creation experiences using the Clanker SDK or CLI, get started here: [Quick Start](/documentation/sdk/quick-start). 4. Users / interfaces may directly interact with Clanker's [Core Contracts](/documentation/references/core-contracts) to deploy tokens. 5. AI bots can use the [Clanker Agent Skill](https://clanker.world/skill/skill.md) to deploy and manage their token by simply prompting your agent with **"add clanker skill "** Token creators earn rewards based on trading volume on their created tokens. See [Creator Rewards & Fees](/documentation/general/creator-rewards-and-fees) for more detail. # Changelog ## August 7, 2025 @clanker on Farcaster now deploys tokens with Clanker's Recommended configuration for fees and initial pool liquidity. UI deployments via clanker.world/deploy now also default to the Recommended configuration. Read more about the fee and pool setups in [Clanker.world Deployments](/documentation/general/token-deployments/clanker.world-deployments). ## August 6, 2025 Clanker v4.0.0 is now live on Unichain. Deployments are supported through [SDK](/documentation/sdk/quick-start) and [Clanker.world Deployments](/documentation/general/token-deployments/clanker.world-deployments). Contract addresses: [Deployed Contracts](/documentation/references/deployed-contracts#unichain-130). ## July 14, 2025 ### gArbitrum Clanker v4.0.0 is now live on Arbitrum One. Deployments are supported through [SDK](/documentation/sdk/quick-start), [Farcaster Bot Deployments](/documentation/general/token-deployments/farcaster-bot-deployments), and [Clanker.world Deployments](/documentation/general/token-deployments/clanker.world-deployments). Contract addresses: [Deployed Contracts](/documentation/references/deployed-contracts#arbitrum-one-42161). ## July 8, 2025 ### Auctions Clanker v4.0.0 introduces MEV modules, opt-in contracts that affect the behavior of the early lifecycle of a Clanker token's pool. The first MEV module we are trying auctions off the first few swaps of freshly deployed pools, giving the auction proceeds to creators. This auction will only ever be deployed on Priority ordered L2s. The auction MEV module will be enabled for tokens created through clanker.world, @clanker on Farcaster, API deployments, and SDK deployments. SDK users may opt out of using MEV modules. How it works: * When a new token is created, there's a brief "auction period" before normal trading opens to everyone. This auction is designed to capture value from MEV bots (sophisticated trading bots that try to profit from new token launches) and redirect some of the value back to the token's creator. * Normal trading starts after 5 rounds of the auction have completed (roughly 22 seconds post token deployment) or immediately after a round of the auction that has no bidders. The maximum delay before normal trading can start is at block *n+11*. * For additional detail, please refer to the [ClankerSniperAuctionV0](/documentation/references/core-contracts/v4/mev-modules/clankersniperauctionv0) documentation. ### Clanker.world As you might have noticed, clanker.world has gotten a visual update over the past couple of weeks. The token creation page at [clanker.world/deploy](https://www.clanker.world/deploy) will be updated to deploy v4.0.0 tokens on July 9. ### @clanker on Farcaster @clanker on Farcaster will be updated to deploy v4.0.0 tokens on July 9. ### SDK The Clanker SDK is available to deploying tokens on v4.0.0 contracts. Please see the [v4.0.0](/documentation/sdk/v4.0.0) SDK documentation for more detail. ### API #### New Endpoints * [Deploy Token (v4.0.0)](/documentation/authenticated/deploy-token-v4.0.0) - Deploy tokens on Clanker's v4.0.0 contracts starting on July 9. #### Planned EOL * [Get Tokens by Creator](/documentation/public/get-tokens-by-creator) - EOL July 31, 2025. Migrate to [Get Paginated List of Tokens](/documentation/public/get-paginated-list-of-tokens). * [Broken mention](broken://pages/wa4V8VXKnSgE4hKSq1bz) - EOL July 31, 2025. Migrate to [Deploy Token (v4.0.0)](/documentation/authenticated/deploy-token-v4.0.0). * [Broken mention](broken://pages/4kyR1eUlG9QCANa4wyjv) - EOL July 31, 2025 Migrate to [Deploy Token (v4.0.0)](/documentation/authenticated/deploy-token-v4.0.0). ## May 9, 2025 ### gmonad @clanker on Farcaster can now deploy tokens on Monad Testnet. Tag @clanker on Farcaster and include the phrase "gmonad" or "monad" to create your own Clanker on Monad Testnet. > *gmonad @clanker, deploy BROOKLYNCRYPTO* {% hint style="danger" %} Only casts containing `gmonad` or `monad` will deploy tokens on Monad Testnet. All other requests to @clanker will deploy tokens on Base Mainnet. {% endhint %} ## April 21, 2025 ### Configurable Starting Market Caps Deployments are now more flexible with configurable starting market caps for WETH-paired tokens. #### API Deployments API users using the [Broken mention](broken://pages/wa4V8VXKnSgE4hKSq1bz) endpoint may optionally pass in the `initialMarketCap` parameter when creating WETH-paired tokens. This defaults to 10, which creates a \~10 ETH starting market cap token. The minimum value accepted is 1, which creates a \~1 ETH starting market cap token. There is no maximum value / limit on this parameter. #### clanker.world Users deploying tokens via [clanker.world](https://www.clanker.world/deploy) can now choose between 1, 5, and 10 ETH for their the starting market cap of their token. ### April 17, 2025 ### Indexing All Clanker Tokens Today, clanker.world and the Clanker API will surface and return info for *almost* all tokens deployed through the Clanker contracts ([Deployed Contracts](/documentation/references/deployed-contracts)). This means that tokens deployed directly to the Clanker contracts with a variety of starting market caps and quote tokens will be included. To help users interpret this data, we're surfacing additional info on clanker.world and adding net new response fields to the API endpoints. Currently, clanker.world and API endpoints will return all tokens deployed on Clanker contracts EXCEPT those with `warnings` flags (see [#frontend-updates-clanker.world](#frontend-updates-clanker.world "mention") for more info). Tokens with `warnings` flags are rare at the moment, but developers using the API should implement their own filtering logic depending on what they would like to surface to their users. {% hint style="warning" %} These guardrails on clanker.world and API are set to be removed on **Friday, April 25**, at which point all tokens deployed on Clanker contracts will be available through clanker.world and the API - regardless of the launch setup of the token. Tokens pages on clanker.world will display a banner with the relevant `warnings` flag, while the API will return the flag in the response. {% endhint %} ### Frontend updates (clanker.world) Token pages will now show the starting market cap, referenced in the quote token that new token was deployed against. For now, all WETH-paired tokens with a starting mcap of at least 1 ETH will be shown, in addition to tokens paired against the [Supported Quote Tokens](/documentation/references/supported-quote-tokens) at the ticks specified in the table. Soon, (once the aforementioned guardrails are removed), clanker.world will show all tokens, irrespective of the quote token or starting market cap. Token pages will then surface warning tags for tokens deployed with atypical pool configurations. See below for a list of the current tags: * Unusual Tick * WETH-denominated tokens with a starting market cap of < 1 ETH (WETH) * Non-WETH tokens listed in [Supported Quote Tokens](/documentation/references/supported-quote-tokens) with pools that do not match the initial tick listed in that table * Unusual Pair Address * Tokens paired with a quote token not listed in [Supported Quote Tokens](/documentation/references/supported-quote-tokens) * Missing Pool Config * Tokens with incomplete or missing pool configuration info. These are primary legacy tokens that were deployed with a standard configuration ### API updates {% hint style="warning" %} API endpoints will return all tokens deployed on Clanker contracts **EXCEPT** those with `warnings` flags. The exception is to provide API users with a period of time to implement their own filtering logic based on the `warnings` and `pool_config` data. These guardrails are set to be removed on **Friday, April 25**, at which point all tokens deployed on Clanker contracts will be available through the API - regardless of the launch setup of the token. Please thoroughly review the new response fields below (most importantly the `warnings`, `pool_config`, and `starting_market_cap` fields) {% endhint %} New response fields will be added for the following endpoints: `/tokens`, `/tokens/search`, `/tokens/fetch-deployed-by-address`, and `/get-clanker-by-address` **New response fields:** * warnings: Any warning flags associated with the token * `UNUSUAL_TICK` * WETH-denominated tokens with a starting market cap of < 1 ETH (WETH) * Non-WETH tokens listed in [Supported Quote Tokens](/documentation/references/supported-quote-tokens) with pools that do not match the initial tick listed in that table * `UNUSUAL_PAIR_ADDRESS` * Tokens paired with a quote token not listed in [Supported Quote Tokens](/documentation/references/supported-quote-tokens) * `MISSING_POOL_CONFIG` * Tokens with incomplete or missing pool configuration info. These are primary legacy tokens that were deployed with a standard configuration * pool\_config: Configuration for the token's liquidity pool * starting\_market\_cap: Initial market capitalization, denominated in the quote token * The quote token is returned as `pairedToken` within `pool_config` * chain\_id: Parsed as integer from database value * metadata: Token metadata from database * deploy\_config: JSON stringified deployment configuration * social\_context: JSON stringified social context (when creator info is available) * deployed\_at: Deployment timestamp * msg\_sender: Address that sent the transaction to deploy the token * factory\_address: Address of the factory contract * locker\_address: Address of the locker contract ## March 18, 2025 ### New v0.3.1 Contracts #### ***Permissionless deployments*** Anyone can interact with the v0.3.1 Clanker factory contract to create clankers. Creators may deploy directly from the contract, while new interfaces can be built on top of the contracts permissionlessly. #### ***Social context & mutable metadata*** Creators and interfaces may pass in social context (e.g. references to Farcaster casts or X posts) during their deployments, which is immutable and can serve as a link to the origin of the deployment. Metadata such as references to the websites or social media profiles for tokens may be added as well. The metadata for tokens is mutable and can be updated by the token's admin (typically the creator). #### ***Creator vaults*** Creators may optionally allocate up to 30% of the token supply to the creator vault at time of deployment. Creators can set the unlock time on the vault, but there is a hard minimum of 30 days. After such time has passed, creators can claim the vaulted tokens from the vault. Deployments with creator vaults are supported through the Clanker API. #### ***Creator buys*** Creators may optionally send ETH during the token deployment transaction to purchase the token they are creating. This occurs after the the optional creator vault allocation is sent to the vault. Deployments with creator buys are not yet supported through the Clanker API. ### Deprecations This upgrade marks the change from v0.3.0 to v0.3.1 contracts. Please refer to [Deployed Contracts](/documentation/references/deployed-contracts) for the list of contracts. At this transition period, deployments through the v0.3.0 token factory will be deprecated. Presales will be deprecated and are not supported in v0.3.1. The following endpoints will be deprecated: * [Broken mention](broken://pages/4kyR1eUlG9QCANa4wyjv) * If you are currently using this endpoint, please contact our team for alternative deployment solutions using the [Broken mention](broken://pages/wa4V8VXKnSgE4hKSq1bz) endpoint. * [Broken mention](broken://pages/RWNeXVzN5ZL3QmXmVXoB) * [Broken mention](broken://pages/72B405vnZLtb885LM7Cl) # Educational Resources Clanker U: resources to help guide you with deploying a token {% hint style="info" %} As a general rule of thumb: whenever you launch a token, it's important to set clear expectations with your community, traders, and teammates. Underpromise and overdeliver. Steer clear of promising future profits and consult professional legal advice. {% endhint %} ## Token Pairings Clanker tokens can be paired with any ERC-20, although we suggest using a token with deep liquidity for optimal trading. Here's an example of deploying a clanker paired with another clanker token: #### Pairing with USDC PROS: * token price won't fluctuate in dollar value based on the price of the underlying asset * cleaner in dashboards, analytics, marketing, and usually people refer to coin market caps in dollar amounts * taxes CONS: * swaps can require multiple pool hops (eth=>USDC=>TOKEN) which can increase txn fees per swap * on some chains, a stablecoin may have shallower liquidity compared to the wrapped native token * isolates the non-USDC familiar users and countries whose primary currency isn't USD #### Pairing with WETH (or wrapped native gas token) PROS: * dexes pick up WETH pools easier in general * best composability with DEX aggregators, lending protocols, trading bots WETH CONS: * double volatility (token/eth x eth/usd) * market cap is seldomly referred to in WETH terms * price charts can be misleading as the default y-axis is usually dollar based (see attached images) ### When to use USDC or WETH? Use USDC for consumer app tokens, stable yield / RWAs, treasury protocols, and maybe governance tokens use WETH for defi-native projects / infra tokens, memes, speculative tokens that are built to bounce up and down ## Episode 1: Clanker 101 Full episode [HERE](https://x.com/lindaxie/status/1983625447608086843) which covers: 1. what is Clanker? 2. how to launch a token 3. fees + token management + adding liquidity 4. deployment configurations (static vs dynamic fee, reward recipients, creator vault, dev buy, airdrops) 5. best practices + more! ## Episode 2: LP Management Full episode [HERE](https://x.com/lindaxie/status/2000997037802971363) which covers: * LP fundamentals, strategies & tradeoffs * common LP mistakes * starting market cap * sniper tax mechanics * Clanker LP position simulator * walkthrough of adding & removing liquidity ## LP position simulator: * Simulate LP positions, market cap changes based on buys and sells, and simulate supply purchased through dev buys at various starting market caps: # FAQ ### Token Deployments
What networks / chains does Clanker support? Please see [Deployed Contracts](/documentation/references/deployed-contracts) for a full list of contract deployments.
How can I find the Token Info page for a Clanker token that I deployed? There are a handful of ways that you can find the Token Info page of Clanker tokens that you've deployed. **Via desktop** On the [Clanker token homepage](https://www.clanker.world/clanker), you can: 1. Search for tokens by token name, ticker, or Farcaster username of the creator. 2. Use the `Connect` button on the bottom left of the page to connect the wallet of your verified address, then press `my deployed clankers`. 3. Visit the [deployed by FID](https://www.clanker.world/clanker/deployed-by-fid) page and type in your FID. See [#how-do-i-find-my-farcaster-verified-address-custody-address-fid](#how-do-i-find-my-farcaster-verified-address-custody-address-fid "mention") for guidance on finding your FID. **Via Warpcast mobile** You can click on any frame that Clanker responds with (go to `Casts + Replies` of @clanker) and select your profile on the bottom left. Press `my deployed clankers` to view a list of all Clanker tokens you have created.
### Creator Rewards
How do I claim creator rewards? Visit the token admin page `https://www.clanker.world/clanker/[TOKEN CONTRACT ADDRESS]/admin` , connect a wallet, and select `Claim Rewards`. This will prompt you to execute a transaction that will distribute creator rewards. {% hint style="info" %} Anyone can initiate the claim process for any token. Creator rewards will then be distributed to the token creator - not the wallet initiating the claim process. {% endhint %}
What does Creator Earnings on the clanker.world Token Info page mean? The Creator Earnings figure is an estimate of the total rewards that a token creator has accrued in the past 30 days. Please note that this is only an **estimate** and might not accurately reflect the current market value of the tokens included in creator rewards. Unclaimed rewards represent the current balance of unclaimed rewards, not a 30 day estimate.
How can I check the balance of unclaimed rewards for a token? Visit the bottom of the token info page to see an estimate of unclaimed rewards.
Why is my unclaimed rewards balance lower than expected? Anyone can initiate the payout of creator rewards, so you might have already received creator rewards for tokens you deployed even without claiming the rewards yourself.
How can I determine the wallet address that creator rewards will be sent to? For tokens created directly through interaction with the @clanker bot on Farcaster, the address set as the initial recipient for creator rewards is either: 1. Your latest Farcaster verified address 2. Your Farcaster custody address (if you do not have any Farcaster verified addresses) See [#how-do-i-find-my-farcaster-verified-address-custody-address](#how-do-i-find-my-farcaster-verified-address-custody-address "mention") for guidance on finding your creator rewards address.
How do I find my Farcaster verified address / custody address / FID? 1. Using Warpcast on desktop, go to your `Profile` and on the top right, press the vertical ellipsis button and select `About`. On the Warpcast mobile app, select the `Information` icon on the top right of your `Profile`.
2. If you have connected an Ethereum wallet, your verified address is the bottom of the list of `Connected Ethereum Wallets`. In the below example, there is only one wallet connected, so that is the verified address.
Claim X token deployment fees & transfer smart wallet balances to another account Watch this video here:
# Token Deployments Guidelines and specifications for tokens deployed on Clanker v4.0.0 {% hint style="success" %} **Live**: The below outlines instructions for deployments on Clanker v4.0.0 that are now available across all Clanker platforms. {% endhint %} ### General Token Deployment Info (Clanker v4.0.0)
* ERC-20 tokens with a total supply of 100 billion tokens. * Tokens are not mintable post-deployment, so the max supply will always be 100 billion. * Tokens are burnable using the `burn()` function on the token contract. * Up to 90% of the total supply may be allocated to Clanker extensions. Extensions allow for token creators to allocate tokens for uses other than supplying liquidity in the new token's Uniswap v4 pool. The current list of extensions: * Vault: lock up / vest tokens for a configurable period of time (7 day minimum lockup). * Creator Buy / Dev Buy: spend ETH to execute a token swap within the deployment transaction, allowing for token creators to guarantee that they are able to make the first purchase of tokens from the initial pool. * Airdrop: airdrop tokens to a list of recipients to then claim with configurable lockup / vesting periods (1 day minimum lockup). * The remaining tokens (up to 100% of the total supply if no extensions are used) are then allocated to up to 7 liquidity positions and placed into a Uniswap v4 pool for trading. * When a new token is created, there's a brief "auction period" before normal trading opens to everyone. This auction is designed to capture value from MEV bots (sophisticated trading bots that try to profit from new token launches) and redirect some of the value back to the token's creator. * Normal trading starts after 5 rounds of the auction have completed (roughly 22 seconds post token deployment) or immediately after a round of the auction that has no bidders. The maximum delay before normal trading can start is at block *n+11*. * For additional detail, please refer to the [ClankerSniperAuctionV0](/documentation/references/core-contracts/v4/mev-modules/clankersniperauctionv0) documentation. {% hint style="info" %} The Airdrop extension contract is live and will soon be supported on the clanker.world UI. {% endhint %} # Farcaster Bot Deployments Create a token using the @clanker bot on Farcaster {% hint style="info" %} @clanker on Farcaster deploys tokens on Base by default. To deploy a token on other supported chains, please read below for the chain's trigger phrases. {% endhint %} ### Create a Token on Base (Default) New Clanker tokens created via the @clanker bot on Farcaster go through the following deployment process. 1. User asks @clanker on Farcaster to deploy a token. The user has the option to: 1. Specify to reserve a portion of the supply in a vault. The maximum amount to vault is 30% and the default is 30% if not specified. 2. Specify how long, in days, to lock the tokens in the vault for. The minimum vault time is 31 days and the default is 31 days if not specified. 2. A new ERC-20 token (the base token) is created with a total supply of 100 billion (100,000,000,000). The token isn't mintable after this step, so the max supply will always be 100 billion tokens. 3. If the user requests to allocate a portion of the supply to the creator vault, that percentage of the supply is then sent to the creator vault. 4. A new Uniswap V4 pool is initiated with the base token and quote token (WETH, by default). The entire total supply of the token, less the portion of the supply allocated to the vault, is deposited into the pool as single-sided liquidity. The starting market cap is set to 10 WETH. 5. The LP NFTs that are created during step 4 are sent to a Clanker LP Locker. The LP Locker has no withdraw function, so LP NFTs that are deposited into it can never be withdrawn and are effectively locked forever. See [Deployed Contracts](/documentation/references/deployed-contracts) and [Audits](/documentation/references/audits) for more info. {% hint style="info" %} * Farcaster bot deployments create tokens in pools with Clanker's recommended fee and liquidity configurations. * Users will receive 80% of LP fees as creator rewards for Farcaster bot deployments. {% endhint %} ### Create a Token on Arbitrum Mention any of the following phrases (not case sensitive) in your cast in addition to following the default deployment instructions to deploy a token on Arbitrum: * arbitrum * garbitrum * arbitrugm ### Create a Token on Monad Testnet Mention any of the following phrases (not case sensitive) in your cast in addition to following the default deployment instructions to deploy a token on Monad Testnet: * monad * gmonad # Clanker.world Deployments Create a token on clanker.world/deploy {% hint style="success" %} **Live**: The below outlines instructions for deployments on Clanker v4.0.0 that are now live at [clanker.world/deploy](https://www.clanker.world/deploy). {% endhint %} Users may create Clanker tokens using the clanker.world [token creation page](https://www.clanker.world/deploy) and connecting a wallet. The section below outlines the parameters are able to be configured by users. {% stepper %} {% step %} #### Basic Token Info {% hint style="info" %} Required, minimum metadata for token creation. {% endhint %} * Network (chain) * Name * Symbol / ticker * Image {% endstep %} {% step %} #### Token Metadata {% hint style="info" %} Optional, additional metadata fields that are both onchain and mutable. {% endhint %} * Description * Telegram link * Website link * X (Twitter) link * Farcaster link {% endstep %} {% step %} #### Fee Configuration {% hint style="info" %} Optional, preset fee configurations for the initial token pool. Defaults to a dynamic fee. {% endhint %} * `Recommended`, fixed % base fee + variable fee based on the pool's volatility * `Legacy`, fixed % fees on trades {% endstep %} {% step %} #### Reward Recipients {% hint style="info" %} Optional, set additional reward recipients for trading fees from the pool. Defaults to 100% of rewards going to the User's connected wallet, accrued in the paired token. {% endhint %} For each Reward Recipient, the following must be set: * **Admin Address**, address that has the ability to override the current Reward Recipient to a new address. * **Reward Percentage**, percentage of total rewards allocated to the Reward Recipient. * **Reward Type**, type of tokens that the user will receive as rewards. The token creator may configure this in the token creation process, but the Token Admin may change this at any time post-deployment. * `Both`, accrue rewards in both the newly created Clanker token and the token it is paired against * `Clanker`, accrue rewards entirely in the newly created Clanker token * `Paired`, accrue rewards entirely in the paired token (typically $WETH) {% endstep %} {% step %} #### Pool Configuration {% hint style="info" %} Optional, choose from a preset liquidity configuration. Defaults to the `Standard` pool type. {% endhint %} * **Pool Type**, preset liquidity configurations (via LP position placements) * `Recommended`, optimized liquidity layout utilizing multiple LP positions. The current starting market cap for this configuration is fixed at `10 ETH`. * `Legacy`, all liquidity is placed in one LP position with a configurable starting market cap. * **Starting Market Cap in ETH**, configure the starting market cap for `Standard` pools {% endstep %} {% step %} #### Creator Vault {% hint style="info" %} Optional, set aside tokens into a vault with configurable lockup and vesting periods. Defaults to a 30 day lockup with instant vesting. {% endhint %} * **Vault Percentage**, percent of total token supply to allocate to the vault. * The token creator wallet is the default beneficiary of the tokens; however, the token creator may set a new beneficiary post-deployment. * **Lockup Period**, day when the lockup ends and vesting begins. There is a 7 day minimum that is enforced at the contract level. * **Vesting Period**, day when vesting ends. Vesting occurs linearly between the Lockup Period and Vesting Period. * Once vesting begins, anyone can call the function on the vault to distribute the tokens. Irrespective of who calls the distribution function, the tokens will be sent to the current beneficiary (the token creator by default, unless changed post-deployment). {% endstep %} {% step %} #### Creator Buy (Dev Buy) {% hint style="info" %} Optional, spend ETH to guarantee the first swap on the newly created token. {% endhint %} There are no upper / lower limits to the amount of ETH that may be used for a Creator Buy. {% endstep %} {% endstepper %} # Preclank Deployments Configure a token on clanker.world/deploy then trigger its creation directly in the Farcaster feed {% hint style="success" %} **Live**: The below outlines instructions for deployments on Clanker v4.0.0 that are now live at [clanker.world/deploy](https://www.clanker.world/deploy). {% endhint %} Users may create Clanker tokens using the clanker.world [token creation page](https://www.clanker.world/deploy) and connecting a wallet. The section below outlines the parameters are able to be configured by users. {% stepper %} {% step %} #### Sign in to clanker.world with a Farcaster account Press Connect on the top right hand side of the page. If you are already signed in with another method, select the dropdown and disconnect. Then, on the Privy sign in modal, select Farcaster to sign in with Farcaster. {% hint style="warning" %} You will not be able to save / use your preclank if you do not sign in using Farcaster. {% endhint %} {% endstep %} {% step %} #### Configure the token creation parameters Visit the clanker.world [token creation page](https://www.clanker.world/deploy), connect a wallet, and configure the token deployment. The default rewards recipient and creator vault beneficiary will be set to the wallet that is connected to the token creation page, not the primary Farcaster wallet of the account that triggers the preclank. For more info on token creation parameters, please refer to [Clanker.world Deployments](/documentation/general/token-deployments/clanker.world-deployments). {% hint style="info" %} Creator Buy (Dev Buy) features are not yet supported for preclank deployments but are on the short-term roadmap. {% endhint %} {% endstep %} {% step %} #### Enable the `Preclank` toggle at the bottom of the form Toggle on `Preclank` at the bottom of the token creation page after populating desired token configuration. Then, add a trigger phrase to the input field. Press the `Preclank` button to save the token configuration + trigger phrase. To view your saved preclanks, select `Manage Preclanks` at the top of the token creation page. {% endstep %} {% step %} #### Deploy the token with the preclank configuration To deploy a token with the preclank configuration, create a cast on Farcaster with your trigger phrase somewhere in the cast **and** tag @clanker. {% hint style="info" %} Trigger phrases are case sensitive and must be entered exactly as they are saved. {% endhint %} @clanker will deploy a token with the preclank configuration and respond with a link to the token info page for the newly created token. {% endstep %} {% endstepper %} # Alternative Interface Deployments Create a token on another interface that utilizes the Clanker contracts Alternative interfaces that deploy tokens through the Clanker SDK have additional customizability and may set a variety of different parameters. Please refer to the documentation of each interface to better understand their deployment parameters. This includes but is not limited to custom: * Creator rewards splits * Starting market cap * Quote token pairs * Liquidity curves via placing multiple LP positions * Vaulting * Airdrops * Creator Buy / Dev Buy # Deploying a Token Guide for deploying a token with Clanker There are various methods to deploy a token with Clanker. The primary method is through the @clanker bot on Farcaster. Please refer to [Token Deployments](/documentation/general/token-deployments) for detail on alternative deployment methods. To deploy a token, tag @clanker in a cast on Farcaster[^1] and provide a token name, token ticker, and optional image / gif in the body of the cast. By default, new tokens will be paired with WETH as the quote token of the initial pool. Optionally, you can instruct Clanker to deploy a token quoted with tokens other than WETH by stating the desired quote token in the same cast. See [Supported Quote Tokens](/documentation/references/supported-quote-tokens) for a full list of quote tokens available. > *i.e. @clanker deploy a token named myNewToken with the ticker MINE paired with CLANKER* Clanker will reply to the cast with one of three responses: 1. Upon successful deployment, Clanker will respond with a link / [frame](https://docs.farcaster.xyz/developers/frames/v2/) to the token page of the deployed token. 2. If the request is not clear to Clanker, Clanker will respond with clarifying questions in order to determine the token name, ticker, and whether the creator wants to deploy the token. 3. If the creator is unable to deploy a token for various reasons, Clanker will respond with the cast with the reason. [^1]: Don't have a Farcaster account? You can sign up using [Warpcast](https://warpcast.com/)!\ \ Alternatively, uou can also visit our friends at [Super](https://www.supercast.xyz/) and [NewCaster](https://newcaster.org/) to create a Farcaster account. # Legacy Deployments ## v3.1.0 - Legacy ### Farcaster Bot Deployments (Standard) New Clanker tokens created via the @clanker bot on Farcaster go through the following deployment process: 1. User deploys a Clanker token via @clanker on Farcaster. The user has the option to reserve up to 30% of the supply in a creator vault, which locks the token for a minimum of 30 days. 2. A new ERC-20 token (the base token) is created with a total supply of 100 billion (100,000,000,000). The token isn't mintable after this step, so the max supply will always be 100 billion tokens. 3. If the user requests to allocate a portion of the supply to the creator vault, that percentage of the supply is then sent to the creator vault. 4. A new Uniswap V3 pool is initiated with the base token and quote token (WETH, by default). The entire total supply of the base token, less the portion of the supply allocated to the creator vault, is deposited into the pool as single-sided liquidity. The starting market cap is set to 10 WETH by default. 5. The LP NFT that is created during step 3 is sent to a Clanker LP Locker. The LP Locker has no withdraw function, so LP NFTs that are deposited into it can never be withdrawn and are effectively locked forever. See [Deployed Contracts](/documentation/references/deployed-contracts) for more info. ### Farcaster Bot Deployments (Creator Buy) 1. User requests to deploy a token via @clanker on Farcaster **and** specifies to do a creator buy. 2. @clanker will respond to the user with a link to a [Frame](https://docs.farcaster.xyz/developers/frames/v2/) of the clanker.world token creation page. 3. The user can select the same options as the through the Farcaster Bot Deployments, with the addition of a creator buy. A creator buy, a.k.a. "dev buy", enables token creators to spend ETH in order to purchase tokens during the token creation transaction. There is an upper limit of 1 ETH on creator buys through the Frame and clanker.world frontend, but there is no restriction on the contract level. {% hint style="warning" %} Creator buys are processed **after** creator vaulting. For example, if a creator designates 10% of the token supply to be set aside into the creator vault, the creator buy will be executed as the first buy against the remaining 90% of the token supply. {% endhint %} ### Clanker.world Deployments 1. User visits the create page on [clanker.world](https://www.clanker.world/). 2. The user can select the same options as the through the Farcaster Bot Deployments, with the addition of a creator buy. A creator buy, a.k.a. "dev buy", enables token creators to spend ETH in order to purchase tokens during the token creation transaction. There is an upper limit of 1 ETH on creator buys through the Frame and clanker.world frontend, but there is no restriction on the contract level. {% hint style="warning" %} Creator buys are processed **after** creator vaulting. For example, if a creator designates 10% of the token supply to be set aside into the creator vault, the creator buy will be executed as the first buy against the remaining 90% of the token supply. {% endhint %} ### Alternative Interface Deployments Alternative interfaces that deploy tokens either through the Clanker API or directly on top of Clanker contracts may set a variety of different parameters. This version of the Clanker contracts greatly expands the customizability of deployments - please refer to the documentation of each interface to better understand their deployment parameters. This includes but is not limited to: * Creator rewards splits * Market cap * Custom quote token pairs ## v3.0.0 - Deprecated New Clanker tokens go through the following deployment process: 1. User deploys a Clanker token via @clanker on Farcaster or through a Clanker partner interface. 2. A new ERC-20 token (the base token) is created with a total supply of 100 billion (100,000,000,000). The token isn't mintable after this step, so the max supply will always be 100 billion tokens. 3. A new Uniswap V3 pool is initiated with the base token and quote token (WETH, by default). The entire total supply of the base token is deposited into the pool as single-sided liquidity. The starting market cap is set to 10 WETH by default. 4. The LP NFT that is created during step 3 is sent to a Clanker LP Locker. The LP Locker has no withdraw function, so LP NFTs that are deposited into it can never be withdrawn and are effectively locked forever. See [Deployed Contracts](https://clanker.gitbook.io/clanker-documentation/references/deployed-contracts) for more info. # Presale Token Deployments {% hint style="danger" %} Presale token deployments were deprecated on March 18, 2025. {% endhint %} Clanker is also able to deploy presale tokens, where a fixed percentage of the total token supply is sold at a flat price to all participants in the presale. Presales on Clanker currently sell 55% of the total token supply with a goal of 5.5 ETH. Once a presale reaches it's goal of 5.5 ETH, tokens are distributed to presale participants based on their presale contributions. The remaining 45% of the total token supply is paired with the 5.5 ETH (automatically converted to WETH) as a quote token and deposited into a newly created Uniswap v3 pool. Presales must reach their goal before any tokens are created - there are not partial presales. If a presale falls short of the goal, tokens are never created and {% hint style="info" %} ETH is the only supported coin for participating in Clanker presales. Presales currently only support WETH as quote tokens in presale deployed pairs. {% endhint %} See below for an example Clanker's presale flow: 1. User mentions "presale" when tagging @clanker on Farcaster with their token deployment request. 2. Clanker creates a presale for the token and responds to the user's deployment request with a link to the presale. 3. Users can participate in the presale through the clanker.world frontend for up to two hours or until the presale goal is met. 4. Once the presale goal is met, the final presale participant's transaction deploys the token. 5. Presale tokens are distributed to presale participants and the remaining token supply is paired with the presale ETH to initiate a Uniswap v3 pool and deposit token/WETH liquidity. # Creator Rewards & Fees #### Creator Rewards Token creators earn rewards based on trading volume of their created tokens. Upon deployment of a standard Clanker token, the full supply of the token is deposited into a single-sided Uniswap v4 LP (the "initial LP"). When traders buy and sell tokens in this pool, the initial LP accrues fee on each swap. If token holders deposit their own LPs from tokens they hold or initiate new trading pools, token creators will not earn any rewards on these positions / pools. Creator rewards can be claimed on the Admin page of the token on [clanker.world](https://www.clanker.world/). The admin page can be found at `https://www.clanker.world/clanker/TOKEN_CONTRACT_ADDRESS_HERE/admin` . Please see the [FAQ](/documentation/general/faq) for detail on finding Token Info pages and collecting creator rewards. #### Clanker Fees The Clanker fee is fixed at 20% of LP fees that are collected at the pool level in addition to creator LP fees. $$ CreatorFee \* 0.2 = SwapFees $$ | Creator | Protocol | Total Swap Fee | | ------- | -------- | -------------- | | 1% | 0.2% | 1.2% | | 2% | 0.4% | 2.4% | | 3% | 0.6% | 3.6% | # Pool Configurations # Clanker.world Warning Tags ### Token Warning Tags When browsing tokens on clanker.world, you may see warning tags that indicate potential issues or unusual configurations. These warnings don't prevent tokens from being displayed, but they help users make informed decisions. The same warning tags are also provided when fetching info about specific tokens via the API. ### Warning Types #### **UNUSUAL\_TICK** **What it means** The token's initial price doesn't match expected market cap thresholds or pricing standards. **Why you see this** * For ETH-paired tokens: The calculated market cap is below \~1 ETH at deployment. * For [Supported Quote Tokens](/documentation/references/supported-quote-tokens): The starting tick of the pool deviates from the initial tick supported via API deployments. **Should I be concerned?** This may indicate an incorrectly configured deployment or unusual starting market caps. Proceed with caution and verify the token's intended pricing. *** #### **UNUSUAL\_PAIR\_ADDRESS** **What it means** The token is paired with a quote token that is not on the list of [Supported Quote Tokens](/documentation/references/supported-quote-tokens). **Why you see this** The token isn't paired with one of the [Supported Quote Tokens](/documentation/references/supported-quote-tokens). **Should I be concerned?** Unusual pairings might indicate experimental of non-standard liquidity setups. If the paired token itself doesn't have deep onchain liquidity, the new token might not be able to be traded without directly having the paired token. Proceed with caution and verify the safety of the paired token. *** #### **MISSING\_POOL\_CONFIG** **What it means** Legacy pool configuration data is missing. **Why you see this** The token's liquidity pool data couldn't be properly retrieved. **Should I be concerned?** These are primarily for legacy (v3.1.0 and previous) tokens. If v4.0.0+ tokens show this warning, proceed with caution as the starting market cap and liquidity configuration might not be known. *** #### **UNUSUAL\_POSITIONS** **What it means** The token's liquidity positions don't match standard configurations. **Why you see this** The token's liquidity positions do not conform to either the preconfigured `Standard` or `Project` liquidity setups. **Should I be concerned?** While not necessarily dangerous, unusual positions might indicate experimental liquidity distributions or ranges that are not as straightforward. Proceed with caution - users may also validate event logs for where the initial liquidity was placed during the token creation process. *** Warning tags serve as automated assessments and to not perfectly capture tokens that are "safe". Always conduct your own research before making trading decisions. # Legacy Fee Claims For clanker versions v0-v3.1, clanker protocol has given back the new token portion of fees back to creators Legacy fee claims from the protocol side can be claimed using this example [here](https://github.com/clanker-devco/clanker-sdk/tree/main/examples/legacy) OR on the token admin pages: **clanker(.)world/\[TOKEN\_ADDRESS]/admin** # Unclaimed Rewards Balance Guide for checking the balance of accrued, unclaimed rewards on Clanker tokens If you've deployed a token with Clanker that has been traded at least once, you have earned rewards. You can check the balance of unclaimed rewards that you've accrued by looking up the balance of `Unclaimed Fees` on the initial LP of your token. 1. Go to your token's page on and select `BaseScan`
2. Click on the contract address for the token's contract
3. Click on the contract creation transaction
4. Obtain the `Token ID` for the LP
5. Visit [`https://app.uniswap.org/positions/v3/base/[YOUR TOKEN ID HERE]`](https://app.uniswap.org/positions/v3/base/1119330) and replace the bracketed section with your `Token ID` from the previous step. 6. 40% of the `Uncollected fees` is the current unclaimed rewards balance that token creators can claim. Please note that the dollar values of the rewards is an estimate and will fluctuate along with the prices of the underlying tokens in the pool, $CLANKER and $WETH in this case.\ \ Using $CLANKER as an example, the creator could claim:\ \ 148.28 $CLANKER \* 40% = **\~59.312 $CLANKER** in creator rewards\ 3.73 $WETH \* 40% = **\~1.492 $WETH** in creator rewards\
7. Please see [Broken mention](broken://pages/KUAepRPNzNJip3WmCGNQ) for detail on claiming creator rewards. # Verifying the Social Context of Token Deploys Anyone can deploy a Clanker and attach an arbitrary `social_context` (Farcaster FID, Twitter handle, etc.) to it. The on-chain payload is **not authenticated** — it's just metadata the deployer chose to embed. To verify a token's claimed creator, check the social context against trusted signals. This document outlines the trust model used by `clanker.world` and how to replicate these checks using the public [`GET /api/search-creator`](https://clanker.gitbook.io/clanker-documentation/public/get-tokens-by-creator) endpoint. ### Why This Matters A token row from `/api/search-creator` looks like: ```json { "contract_address": "0xabc...", "msg_sender": "0xdeadbeef...", "social_context": { "platform": "farcaster", "id": "12345" }, "trustStatus": { "isTrustedDeployer": false, "isTrustedClanker": false, "fidMatchesDeployer": true, "verifiedAddresses": ["0xdeadbeef..."] } } ``` There are two distinct identities: * **`msg_sender`** — the EOA or contract that initiated the on-chain call. This is provable through transaction records. * **`social_context`** — a free-form `{ platform, id }` field that the deployment embeds. The deployer might not control the referenced account. A malicious deployer can claim any FID in `social_context`. The trust check aims to answer: **"Is the signatory wallet truly owned by the claimed social account?"** ### Trust Signals (in Priority Order) `clanker.world` resolves trust using four signals. The first matching one determines trust. #### 1. Allowlisted Clanker (`isTrustedClanker`) The token's contract address is allowlisted, verified out-of-band (e.g., tokens deployed through Clanker and v3 presale clanker addresses). This signal overrides all others. #### 2. Trusted Deployer (`isTrustedDeployer`) `msg_sender` is in the vetted deployers list maintained by Clanker or partners. Here is a list of historical `TRUSTED_DEPLOYERS` but is subject to be modified/added. ``` // TRUSTED_DEPLOYERS '0x2112b8456AC07c15fA31ddf3Bf713E77716fF3F9', '0xB2C90e2bB032349e7bEc82B37Cdcc93b6B91036a', '0x8da62A828b0D9f1B33F75652605e12ee4E5e4F06', '0x002F07B0D63e8ac14F8ef6B73Ccd8caF1FeF074c', '0xC204af95b0307162118f7Bc36a91c9717490AB69', '0xd9aCd656A5f1B519C9E76a2A6092265A74186e58', '0xdd6494902709C8D7DfFf3daca21cF067271f22F8', '0xdc7D0Ea3B64E0c74488faF6B2BDc927B875Cd3f2', '0x21c78a0350fa50e7c79c761003e33c0c7f440185', '0x5e2b5027742ae08c1a018144e31f101f24dc9824', '0x72469D86A92f5A9E975fE371a66015E667ab288f', '0x8865910d6ca985782Dc9CC521d23a10100fC800B', '0xe0c959eedcfd004952441ea4fb4b8f5af424e74b', '0x24D514Bc8eF5649A367d9c209b3AF16b0f177026', '0x9844050f249604F4485aeD2fC51BAAb3DBe78411', '0x26D0A510553C209a584E01Bd4551bDbe38151Fd4', // bracky deployer '0xBD01E8106a169687C8572672c8900760E5BA170f', // AutoBoy deployer ``` #### 3. FID Verified (`fidMatchesDeployer`) — Farcaster For Farcaster tokens, `clanker.world` retrieves the FID's `verified_addresses.eth_addresses` through Neynar to check: > `msg_sender ∈ verifiedAddresses` > > A match indicates the same person controls both the Farcaster account and the wallet. > > #### 4. Twitter Context Match — Twitter > > For Twitter tokens, confirm that `social_context.id` matches the queried Twitter user ID. This is weaker than Farcaster verification. > > ### Verification Flow > > ```mermaid > flowchart TD > A[Token row] --> B{contract on ALLOWLISTED_CLANKERS?} > B -- yes --> T[Trusted: allowlisted] > B -- no --> C{msg_sender in TRUSTED_DEPLOYERS?} > C -- yes --> T2[Trusted: vetted deployer] > C -- no --> D{social_context.platform} > D -- farcaster --> E[Fetch FID via Neynar] > E --> F{msg_sender ∈ verified_addresses?} > F -- yes --> T3[Trusted: FID-verified] > F -- no --> U[Unverified] > D -- twitter --> G{social_context.id == queried twitterId?} > G -- yes --> T4[Trusted: handle match only] > G -- no --> U > D -- none --> U > ``` > > ### Using the API > > ```bash > curl "https://clanker.world/api/search-creator?q=dish" > ``` > > Each `tokens` entry includes `trustStatus`: | Field | Type | Meaning | | -------------------- | ---------- | ------------------------------------------------------------------- | | `isTrustedClanker` | `boolean` | Contract is manually allowlisted. | | `isTrustedDeployer` | `boolean` | `msg_sender` is a vetted deployer. | | `fidMatchesDeployer` | `boolean` | `msg_sender` is in the FID's verified addresses (or Twitter match). | | `verifiedAddresses` | `string[]` | Farcaster verified addresses considered during the check. | To filter for verified results, use `trustedOnly=true`: ```bash curl "https://clanker.world/api/search-creator?q=alice&trustedOnly=true" ``` This returns tokens where at least one of `isTrustedClanker`, `isTrustedDeployer`, or `fidMatchesDeployer` is `true`. ### Checking a Single Token To independently verify a token's creator: 1. Retrieve `msg_sender`, `contract_address`, and `social_context`. 2. Accept if `contract_address` is allowlisted. 3. Accept if `msg_sender` is trusted. 4. For Farcaster context: * Get user with FID from Neynar. * Compare `msg_sender` with `verified_addresses`. * A match proves ownership. 5. For Twitter context: * Confirm user ID matches `social_context.id`. * ```ts async function isFarcasterVerifiedDeploy({ msgSender, socialContext, }: { msgSender: string; socialContext: { platform: 'farcaster'; id: string }; }) { const fid = Number(socialContext.id); if (!fid) return false; const res = await fetch( `https://api.neynar.com/v2/farcaster/user/bulk?fids=${fid}`, { headers: { 'x-api-key': process.env.NEYNAR_API_KEY! } }, ); const { users } = await res.json(); const verified: string[] = users?.[0]?.verified_addresses?.eth_addresses ?? []; return verified.some((addr) => addr.toLowerCase() === msgSender.toLowerCase()); } ``` ### What the Trust Check Does NOT Prove * It does **not** guarantee the token's economic intent or value. * A `false` signal does **not** imply fraudulence. * Twitter does not offer on-chain proof like Farcaster; handle Twitter verifications cautiously. Always check the deployment context of X deploys to view the tweet that triggered the deployment. Check the X account for impersonation as well. Always accompany the trust status with standard disclaimers: tokens are speculative, conduct your own research, this is not financial advice. ### How to have your Farcaster account show as Creator You can either clank through the bot in-feed, preclank through the deploy page, or send the `deployToken` method from the deploy page or SDK with an account that is verified to your Farcaster account. To verify an ETH account on your Farcaster profile, go to **Settings ⇒ Verified Addresses** # Quick Start Clanker SDK Developer Guide ### Quick Start ```bash npm install clanker-sdk ``` ### Overview The Clanker SDK enables developers to easily create and deploy tokens with built-in liquidity pools, vesting vaults, and customizable reward distributions. ### Examples A full list of SDK examples can be found [HERE](https://github.com/clanker-devco/clanker-sdk/tree/main/examples/v4). ### Core Features * 🚀 One-click token deployment * 💧 Automatic liquidity pool creation * 🔒 Optional vesting vaults * 💰 Configurable reward distributions * 🎨 Built-in metadata and social links ### User Guides * [v4.0.0](/documentation/sdk/v4.0.0) * [v3.1.0](/documentation/sdk/v3.1.0) * [Clanker CLI](/documentation/sdk/clanker-cli) ### Resources * [Clanker World](https://clanker.world) * [GitHub Repository](https://github.com/clanker-devco/clanker-sdk) ### Mini App Example!! * [Deploy a Clanker in a Mini App](https://clanker-sdk-minikit.vercel.app) * [Repository](https://github.com/mugrebot/minikitclankerapp/tree/master/testing-stuff) The SDK and quickstart guide are available on the npm registry: {% embed url="" %} # v4.0.0 Clanker v4.0.0 SDK User Guide ### Examples Deployment Examples: ### Quick Start {% tabs %} {% tab title="npm" %} ```bash npm install clanker-sdk viem ``` {% endtab %} {% tab title="bun" %} ```bash bun add clanker-sdk viem ``` {% endtab %} {% tab title="yarn" %} ```bash yarn add clanker-sdk viem ``` {% endtab %} {% endtabs %} ### Basic Usage ```typescript import { Clanker } from 'clanker-sdk/v4'; import { createWalletClient, createPublicClient, privateKeyToAccount, http } from 'viem'; // Viem setup const account = privateKeyToAccount(process.env.PRIVATE_KEY); const client = createPublicClient({ chain: base, transport: http() }); const wallet = createWalletClient({ account, chain: base, transport: http() }); // Initialize the SDK const clanker = new Clanker({ publicClient: client, wallet: walletClient, }); // Deploy a token const { txHash, waitForTransaction, error } = await clanker.deploy({ name: "My Token", symbol: "MTK", tokenAdmin: account.address, // Optional parameter. This will make a call to Clanker's vanity-address // service to generate a salt so the token deploys with the "b07" suffix. vanity: true, }); // The `deploy` function attempts to not throw and instead return an error // for you to decide how to handle if (error) throw error; // It also returns a function `waitForTransaction` that you may use to wait // for the full token deployment. This also may return an error, or the address // of the token on success. const { address } = await waitForTransaction(); console.log(`Deployed token to ${address}`); ``` ### Advanced Configuration #### Token Configuration Adding an image, metadata, and context to your token. {% hint style="info" %} Context is social provenance and will be validated by interfaces displaying tokens. If the context (user id) cannot confidently be matched to the token, it will not be displayed on clanker.world. {% endhint %} ```typescript const token: ClankerTokenV4 = { name: "My Token", symbol: "MTK", tokenAdmin: account.address, image: 'ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi', metadata: { description: 'My new token.', socialMediaUrls: [], auditUrls: [], }, context: { interface: 'Clanker SDK', // Platform related to the deployment. For example "farcaster". platform: '', // Id of the message on the platform. For example, a "cast id" for farcaster. messageId: '', // Id of the user for the platform. For example, a "fid" for farcaster. id: '', } }; ``` #### Pool Configuration To customize the paired token and starting market cap, use the `pool` field. The pool is configured to use `WETH` as the paired token by default with a 10 eth starting market cap. If a custom starting market cap is used, custom positions must be used as well. {% hint style="info" %} The SDK will throw if there is not a position that has its `tickLower` touching the starting price. Well formed liquidity placements should span the starting price to max price. {% endhint %} ```typescript // To switch between preset position options, PoolPositions.Standard (meme) // and PoolPositions.Project: const token: ClankerTokenV4 = { // ... other configuration ... positions: POOL_POSITIONS.Standard, } // To use a custom paired token, market cap, and liquidity positions const token: ClankerTokenV4 = { // ... other configuration ... pool: { pairedToken: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913', tickIfToken0IsClanker: -423_800, positions: [ { tickLower: -423_800, tickUpper: -318_400, positionBps: 9500 }, { tickLower: -318_400, tickUpper: -100_000, positionBps: 500 } ], } } ``` #### Fee Configuration To customize the fees on the deployed Uniswap v4 pool, define a new `fees` field on the token. If no fee configuration is provided, the SDK configures a static pool with 1% fees for both token inputs. ```typescript // To use Static Fee with custom fee settings: const tokenConfig: ClankerTokenV4 = { // ... other configuration ... fees: { type: "static", // Both fees are in bps clankerFee: 100, pairedFee: 100, }, }; // Using a Dynamic Fee basic preset const token: ClankerTokenV4 = { // ... other configuration ... fees: FEE_CONFIGS.DynamicBasic, }; ``` #### Rewards Configuration To customize the reward recipients, use the `rewards` field. The `admin` receives no rewards but may change the `recipient` which does get the rewards. They may be set to the same address. The sum of all `bps` must be 100%. If no reward configuration is provided, the `tokenAdmin` receives all of the LP rewards. ```typescript // To input custom reward recipients, with up to 7 recipients: const token: ClankerTokenV4 = { // ... other configuration ... rewards: { recipients: [ { recipient: CREATOR_REWARD_ADDRESS, admin: CREATOR_ADMIN_ADDRESS, // In bps. 80% of reward bps: 8_000, // Take fees in the Paired token (usually WETH) // Options are Both, Paired, and Clanker token: "Paired", }, { recipient: INTERFACE_REWARD_ADDRESS, admin: INTERFACE_ADMIN_ADDRESS, // In bps. 20% of reward bps: 2_000, // Take fees in both tokens - Clanker and Paired (usually WETH) token: "Both", }, ] }, }; ``` #### Vesting Vault To vault and optionally vest a portion of the token supply, use the `vault` field. ```typescript // To vault a portion of the token supply at launch const token: ClankerTokenV4 = { // ... other configuration ... vault: { // 10% of token supply, up to 90% percentage: 10, // 30 days in seconds, min of 7 days lockupDuration: 2592000, // 30 days in seconds, can be 0 vestingDuration: 2592000, }, }; ``` #### Initial Dev Buy To include a initial purchase on the pool, use the `devBuy` field.\ \ For dev buys with non-weth pairs, you must provide a **Uniswap v4** PoolKey for a WETH/ETH<>Paired swap. ```typescript // To perform a dev buy when WETH is the paired token const token: ClankerTokenV4 = { // ... other configuration ... devBuy: { // Decimal amount of eth to spend ethAmount: 0.0001, }, }; // To perform a dev buy when the paired token is not WETH const token: ClankerTokenV4 = { // ... other configuration ... devBuy: { // Decimal amount of eth to spend (on PairedToken) ethAmount: 0.0001, // pool key to swap from WETH -> PairedToken poolKey: { currency0: '0x0000000000000000000000000000000000000000', currency1: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913', fee: 500, tickSpacing: 10, hooks: '0x0000000000000000000000000000000000000000', }, // minimum amount out from WETH -> PairedToken swap amountOutMin: 0.0000001, }, }; ``` ### Complete Example ```typescript import { Clanker } from 'clanker-sdk/v4'; import { createWalletClient, createPublicClient, http } from 'viem'; // Prepare viem: account, publicClient, and wallet. // Initialize the SDK const clanker = new Clanker({ publicClient, wallet }); // Deploy the token const { waitForTransaction } = await clanker.deploy({ name: "My Cool Project Coin", symbol: "MCPC", tokenAdmin: account.address, image: 'ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi', metadata: { description: 'Token with custom configuration including vesting and rewards', }, context: { interface: 'Clanker SDK', }, pool: { positions: POOL_POSITIONS.Project, }, fees: FEE_CONFIGS.DynamicBasic, rewards: { recipients: [ { recipient: MY_EOA, admin: MY_MULTISIG, // In bps. 80% of reward bps: 8_000, token: "Paired", }, { recipient: FRIEND_EOA, admin: FRIEND_MULTISIG, // In bps. 20% of reward bps: 2_000, token: "Both", }, ] }, vault: { percentage: 10, // 10% of token supply, up to 90% lockupDuration: 2592000, // 30 days in seconds, min of 7 days vestingDuration: 2592000, // 30 days in seconds, can be 0 recipient: VAULT_ALLOCATION_RECIPIENT_ADDRESS // optional, defaults to tokenAdmin }, devBuy: { ethAmount: 0.1, }, }); const { address } = await waitForTransaction(); console.log(`Token deployed at: ${address}`); console.log(`View on Clanker World: https://clanker.world/clanker/${address}`); ``` # v3.1.0 Clanker v3.1.0 SDK User Guide ### Quick Start ```bash npm install clanker-sdk ``` ### Basic Usage ```typescript import { Clanker } from 'clanker-sdk'; import { createWalletClient, createPublicClient, http } from 'viem'; // Initialize SDK const clanker = new Clanker({ wallet: walletClient, publicClient, factoryAddress: FACTORY_ADDRESS }); // Deploy a token const tokenAddress = await clanker.deployToken({ name: "MyToken", symbol: "TOKEN", image: "ipfs://...", metadata: { description: "My awesome token", socialMediaUrls: ["https://twitter.com/mytoken"], auditUrls: [] }, pool: { quoteToken: "0x4200000000000000000000000000000000000006", // WETH initialMarketCap: "1" // 1 WETH } }); ``` ### Advanced Configuration #### Vesting Vault Add a vesting schedule for token distribution: ```typescript const config = { // ... basic config ... vault: { percentage: 20, // 20% of tokens durationInDays: 90 // 90-day vesting } }; ``` #### Reward Distribution Configure creator and interface rewards (Clanker retains 20%): ```typescript const config = { // ... basic config ... rewardsConfig: { creatorReward: 80, // 80% max to creator, 0% to interface creatorAdmin: "0x...", // Optional: Custom admin address creatorRewardRecipient: "0x..." // Optional: Custom reward recipient } }; ``` #### Initial Dev Buy Configure an initial buy to provide liquidity: ```typescript const config = { // ... basic config ... devBuy: { ethAmount: "0.1", // Buy 0.1 ETH worth maxSlippage: 5 // 5% max slippage } }; ``` ### Complete Example ```typescript const tokenAddress = await clanker.deployToken({ name: "Awesome Token", symbol: "AWESOME", image: "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi", metadata: { description: "The most awesome token on Base", socialMediaUrls: [ "https://twitter.com/awesome", "https://t.me/awesome" ], auditUrls: [] }, context: { interface: "My dApp", platform: "Awesome Platform", messageId: "deployment-1", id: "awesome-token-1" }, vault: { percentage: 20, durationInDays: 90 }, pool: { quoteToken: "0x4200000000000000000000000000000000000006", initialMarketCap: "1" }, devBuy: { ethAmount: "0.1", maxSlippage: 5 }, rewardsConfig: { creatorReward: 80, creatorAdmin: "0x...", creatorRewardRecipient: "0x..." } }); console.log(`Token deployed at: ${tokenAddress}`); console.log(`View on Clanker World: https://clanker.world/clanker/${tokenAddress}`); ``` # Clanker CLI The Clanker SDK ships a command-line interface for deploying and managing ERC-20 tokens with Uniswap V4 liquidity directly from your terminal. {% hint style="info" %} [Clanker's CLI only supports v4 deployments](#user-content-fn-1)[^1] {% endhint %} ### Installation #### Global install (recommended) ```bash npm install -g clanker-sdk ``` Then run commands with: ```bash clanker-sdk [options] ``` #### npx (no install) ```bash npx clanker-sdk [options] ``` ### Quick Start ```bash # 1. Run interactive setup to configure your wallet and RPC clanker-sdk setup # 2. Deploy a token (interactive mode) clanker-sdk deploy # 3. Deploy a token (non-interactive) clanker-sdk deploy --name "MyToken" --symbol "MTK" --chain base # 4. Check available rewards clanker-sdk rewards available --token 0x4200000000000000000000000000000000000006 ``` ### Configuration #### `setup` command Run `clanker-sdk setup` to interactively configure: * **Wallet** — create a new wallet, import an existing private key, or skip * **Default chain** — choose from supported chains * **RPC URL** — use a public RPC or enter a custom one Configuration is saved to `~/.clanker/config.json` with `0600` permissions (owner-only read/write). #### Config file Located at `~/.clanker/config.json`: ```json { "privateKey": "0x...", "defaultChain": "base", "rpc": { "base": "https://mainnet.base.org", "arbitrum": "https://arb1.arbitrum.io/rpc" } } ``` #### Private key resolution order The CLI resolves your wallet private key in this order: 1. `--private-key` flag 2. `PRIVATE_KEY` environment variable 3. `~/.clanker/config.json` → `privateKey` #### Chain resolution order 1. `--chain` flag 2. `~/.clanker/config.json` → `defaultChain` 3. Falls back to `base` #### RPC resolution order 1. `--rpc` flag 2. `~/.clanker/config.json` → `rpc[chainName]` 3. Default public RPC for the chain ### Global Options These options apply to all commands: | Flag | Description | Default | | --------------------- | ------------------------------------- | ---------------- | | `--chain ` | Target chain | `base` | | `--rpc ` | Custom RPC URL | per config/chain | | `--private-key ` | Wallet private key | env/config | | `--json` | Machine-readable JSON output | `false` | | `--dry-run` | Simulate transactions without sending | `false` | | `--help` | Show help for a command | — | | `--version` | Show CLI version | — | #### Supported Chains | Chain | Chain ID | | -------------- | -------- | | `base` | 8453 | | `base-sepolia` | 84532 | | `arbitrum` | 42161 | | `ethereum` | 1 | | `bsc` | 56 | | `unichain` | 130 | | `monad` | 143 | ### Commands #### `setup` Interactive wizard to configure wallet, default chain, and RPC settings. ```bash clanker-sdk setup ``` No additional flags. Prompts you to: 1. **Wallet** — create new, import existing, keep current, or skip 2. **Default chain** — select from supported chains 3. **RPC** — use public RPC, enter a custom URL, or keep current *** #### `deploy` Deploy a new ERC-20 token with Uniswap V4 (default) or V3 liquidity. When `--name` and `--symbol` are provided, the CLI runs non-interactively. Otherwise, it launches an interactive wizard. ```bash # Interactive mode clanker-sdk deploy # Non-interactive mode clanker-sdk deploy --name "MyToken" --symbol "MTK" # V3 legacy deployment clanker-sdk deploy --v3 --name "MyToken" --symbol "MTK" # Full configuration example clanker-sdk deploy \ --name "MyToken" \ --symbol "MTK" \ --chain base \ --paired-token WETH \ --starting-market-cap 10 \ --fee-config Static \ --static-fee-percent 1 \ --vault-percentage 10 \ --vault-lockup-days 30 \ --dev-buy-eth 0.1 \ --description "My awesome token" \ --website "https://mytoken.com" \ --twitter "https://twitter.com/mytoken" ``` **Deploy Options** | Flag | Description | Default | | -------------------------------- | ------------------------------------------------------------ | ----------- | | `--v3` | Use Clanker V3 (legacy) | V4 | | `--name ` | Token name (required for non-interactive) | — | | `--symbol ` | Token symbol (required for non-interactive) | — | | `--image ` | Token image URL | — | | `--token-admin
` | Token admin address | your wallet | | `--paired-token
` | Paired token address or `WETH` | `WETH` | | `--starting-market-cap ` | Starting market cap in paired token units | — | | `--fee-config ` | Fee config: `Static`, `Dynamic3` | `Static` | | `--static-fee-percent ` | Static fee percentage (0–10) | `1` | | `--pool-positions ` | `Standard`, `Project`, `TwentyETH` (when starting mcap is 0) | `Standard` | | `--vault-percentage ` | Vault percentage (1–90) | — | | `--vault-lockup-days ` | Vault lockup duration in days (min 7) | `7` | | `--dev-buy-eth ` | Dev buy amount in ETH | — | | `--fee-preference ` | `Both`, `Paired`, `Clanker` | `Both` | | `--description ` | Token description | — | | `--website ` | Website URL | — | | `--twitter ` | Twitter/X URL | — | | `--telegram ` | Telegram URL | — | | `--farcaster ` | Farcaster URL | — | | `--salt ` | Custom CREATE2 salt (`0x`-prefixed); skips vanity address | — | | `--airdrop-csv ` | CSV file for airdrop (`address,amount`) | — | | `--airdrop-lockup-days ` | Airdrop lockup in days | `1` | | `--airdrop-vesting-days ` | Airdrop vesting in days | `0` | | `--reward-recipients ` | JSON array: `[{admin, recipient, bps, token}]` | — | | `--sniper-starting-fee ` | Sniper starting fee (unibps) | `666777` | | `--sniper-ending-fee ` | Sniper ending fee (unibps) | `41673` | | `--sniper-decay-seconds ` | Sniper fee decay duration in seconds | `15` | **Paired Token Defaults by Chain** | Chain | Available Paired Tokens | | ---------- | ----------------------- | | `base` | WETH, USDC | | `bsc` | USDT | | `monad` | WMON | | All others | WETH | **Fee Configurations** | Type | Description | | ---------- | --------------------------------------------------------- | | `Static` | Flat fee; configurable via `--static-fee-percent` (0–10%) | | `Dynamic3` | Dynamic fee up to 3% | > Legacy names `StaticBasic` and `DynamicBasic` are also accepted. > Monad only supports `Static` fees. *** #### `rewards` Manage creator rewards (LP fees) for deployed tokens. **`rewards claim`** Claim accumulated fees for a specific reward token. ```bash # Claim WETH rewards on Base clanker-sdk rewards claim --token 0x4200000000000000000000000000000000000006 # Claim for a specific recipient clanker-sdk rewards claim --token 0x4200000000000000000000000000000000000006 --recipient 0xYourAddr # Dry run clanker-sdk rewards claim --token 0x4200000000000000000000000000000000000006 --dry-run ``` | Flag | Required | Description | | ----------------------- | -------- | ---------------------------------------------------------------------- | | `--token
` | Yes | The **fee token** address to claim (e.g. WETH) — not the clanker token | | `--recipient
` | No | Reward recipient address (defaults to your wallet) | **`rewards available`** Check claimable fee balance for a specific reward token. ```bash clanker-sdk rewards available --token 0x4200000000000000000000000000000000000006 clanker-sdk rewards available --token 0x4200000000000000000000000000000000000006 --recipient 0xSomeAddr ``` | Flag | Required | Description | | ----------------------- | -------- | ---------------------------------------------------------------------- | | `--token
` | Yes | The **fee token** address to check (e.g. WETH) — not the clanker token | | `--recipient
` | No | Reward recipient address (defaults to your wallet) | **`rewards info`** Show reward admins and recipients for a clanker token. ```bash clanker-sdk rewards info --token 0xe75785C92cc93938160e0BE449073A1C35521010 ``` | Flag | Required | Description | | ------------------- | -------- | ----------------------------- | | `--token
` | Yes | The **clanker token** address | **`rewards update-recipient`** Update who receives rewards for a clanker token. ```bash clanker-sdk rewards update-recipient --token 0xClankerToken --index 0 --new-recipient 0xNewAddr ``` | Flag | Required | Description | | --------------------------- | -------- | ------------------------------- | | `--token
` | Yes | Clanker token address | | `--index ` | Yes | Reward position index (0-based) | | `--new-recipient
` | Yes | New recipient address | **`rewards update-admin`** Update who can manage rewards for a clanker token. ```bash clanker-sdk rewards update-admin --token 0xClankerToken --index 0 --new-admin 0xNewAdmin ``` | Flag | Required | Description | | ----------------------- | -------- | ------------------------------- | | `--token
` | Yes | Clanker token address | | `--index ` | Yes | Reward position index (0-based) | | `--new-admin
` | Yes | New admin address | *** #### `vault` Manage vaulted (time-locked) tokens. **`vault claim`** Claim vaulted tokens after the lockup period has elapsed. ```bash clanker-sdk vault claim --token 0xTokenAddress clanker-sdk vault claim --token 0xTokenAddress --dry-run ``` | Flag | Required | Description | | ------------------- | -------- | ------------- | | `--token
` | Yes | Token address | **`vault balance`** Check the claimable vault balance for a token. ```bash clanker-sdk vault balance --token 0xTokenAddress ``` | Flag | Required | Description | | ------------------- | -------- | ------------- | | `--token
` | Yes | Token address | *** #### `airdrop` Merkle tree–based airdrop utilities. Airdrops are configured either at deploy time (via `--airdrop-csv`) or managed separately with these subcommands. **`airdrop generate-tree`** Generate a Merkle tree from a CSV file. ```bash clanker-sdk airdrop generate-tree --csv airdrop.csv clanker-sdk airdrop generate-tree --csv airdrop.csv --output tree.json ``` | Flag | Required | Description | | ----------------- | -------- | ----------------------------------------------- | | `--csv ` | Yes | Path to CSV file (columns: `address`, `amount`) | | `--output ` | No | Path to write the tree JSON output | **CSV format:** ```csv address,amount 0x1234567890abcdef1234567890abcdef12345678,1000 0xabcdefabcdefabcdefabcdefabcdefabcdefabcd,500 ``` **`airdrop get-proof`** Get a Merkle proof for a specific address. ```bash clanker-sdk airdrop get-proof --csv airdrop.csv --address 0x1234... --amount 1000 ``` | Flag | Required | Description | | --------------------- | -------- | ------------------------------------------------ | | `--csv ` | Yes | Path to CSV file used to generate the tree | | `--address
` | Yes | Address to get proof for | | `--amount ` | Yes | Airdrop amount for this address (must match CSV) | **`airdrop register`** Register a Merkle tree with the Clanker service. The token must already be deployed with a matching Merkle root. ```bash clanker-sdk airdrop register --token 0xTokenAddress --csv airdrop.csv ``` | Flag | Required | Description | | ------------------- | -------- | ------------------------------------------ | | `--token
` | Yes | Deployed token address | | `--csv ` | Yes | Path to CSV file used to generate the tree | **`airdrop claim`** Claim airdrop tokens. Proofs are fetched automatically from the Clanker service. ```bash clanker-sdk airdrop claim --token 0xTokenAddress clanker-sdk airdrop claim --token 0xTokenAddress --recipient 0xRecipient ``` | Flag | Required | Description | | ----------------------- | -------- | ------------------------------------------- | | `--token
` | Yes | Token address | | `--recipient
` | No | Recipient address (defaults to your wallet) | *** #### `token` Manage token metadata on-chain. **`token update-image`** Update a token's image URL. ```bash clanker-sdk token update-image --token 0xTokenAddress --image "https://example.com/image.png" ``` | Flag | Required | Description | | ------------------- | -------- | ------------- | | `--token
` | Yes | Token address | | `--image ` | Yes | New image URL | **`token update-metadata`** Update token metadata (description, social links). ```bash clanker-sdk token update-metadata \ --token 0xTokenAddress \ --description "Updated description" \ --website "https://mytoken.com" \ --twitter "https://twitter.com/mytoken" ``` | Flag | Required | Description | | ---------------------- | -------- | ----------------- | | `--token
` | Yes | Token address | | `--description ` | No | Token description | | `--website ` | No | Website URL | | `--twitter ` | No | Twitter/X URL | | `--telegram ` | No | Telegram URL | | `--farcaster ` | No | Farcaster URL | *** ### JSON Output Pass `--json` to any command to get machine-readable JSON output, suitable for scripting and automation: ```bash clanker-sdk rewards available --token 0x... --json ``` ```json { "token": "0x4200000000000000000000000000000000000006", "recipient": "0xYourAddress", "availableRewards": "1000000000000000" } ``` ### Dry Runs Pass `--dry-run` to simulate transactions without sending them on-chain. Supported by `deploy`, `rewards claim`, `rewards update-recipient`, `rewards update-admin`, `vault claim`, `token update-image`, `token update-metadata`, and `airdrop claim`: ```bash clanker-sdk deploy --name "TestToken" --symbol "TST" --dry-run ``` ### Environment Variables | Variable | Description | | ------------- | ----------------------------------------------------------------------- | | `PRIVATE_KEY` | Wallet private key (alternative to `--private-key` flag or config file) | | `NO_COLOR` | Disable colored output | | `FORCE_COLOR` | Force colored output | ### Examples #### Deploy a token with a vault and dev buy ```bash clanker-sdk deploy \ --name "VaultToken" \ --symbol "VTK" \ --vault-percentage 10 \ --vault-lockup-days 30 \ --dev-buy-eth 0.05 ``` #### Deploy with custom reward recipients ```bash clanker-sdk deploy \ --name "RewardToken" \ --symbol "RTK" \ --reward-recipients '[{"admin":"0xAdminAddr","recipient":"0xRecipAddr","bps":5000,"token":"Paired"}]' ``` #### Deploy with airdrop ```bash clanker-sdk deploy \ --name "AirdropToken" \ --symbol "ADT" \ --airdrop-csv ./recipients.csv \ --airdrop-lockup-days 7 \ --airdrop-vesting-days 30 ``` #### Deploy on BSC ```bash clanker-sdk deploy \ --name "BSCToken" \ --symbol "BSC" \ --chain bsc \ --paired-token 0x55d398326f99059fF775485246999027B3197955 \ --starting-market-cap 10000 ``` #### Full rewards workflow ```bash # Check reward configuration for a token clanker-sdk rewards info --token 0xClankerToken # Check available rewards (pass the fee token, e.g. WETH) clanker-sdk rewards available --token 0x4200000000000000000000000000000000000006 # Claim rewards clanker-sdk rewards claim --token 0x4200000000000000000000000000000000000006 ``` #### Full airdrop workflow ```bash # 1. Generate Merkle tree from CSV clanker-sdk airdrop generate-tree --csv recipients.csv --output tree.json # 2. Deploy token with airdrop clanker-sdk deploy --name "AirdropToken" --symbol "ADT" --airdrop-csv recipients.csv # 3. Register the tree with Clanker clanker-sdk airdrop register --token 0xDeployedToken --csv recipients.csv # 4. Recipients claim their tokens clanker-sdk airdrop claim --token 0xDeployedToken ``` [^1]: # Quick Start #### Fetching Clanker Data Get started by checking out the [Public](/documentation/public) endpoints. #### Deploying Clanker Tokens We highly encourage users to use our [v4.0.0](/documentation/sdk/v4.0.0) SDK for deploying tokens. Currently, full API access is granted on a case-by-case basis to interested platforms. To request access, please contact us [here](https://www.clanker.world/contact-us). We'll evaluate each request individually as we carefully scale our platform access. # Public Public API endpoints # Get Paginated List of Tokens Retrieves a paginated list of deployed tokens with optional filtering and sorting capabilities. **Endpoint:** `GET https://www.clanker.world/api/tokens` *** ### Query Parameters | Parameter | Type | Default | Description | | ----------------- | -------------------------------- | --------- | --------------------------------------------------------------------------------------------- | | `q` | string | undefined | Search query for token name or symbol | | `fid` | number | undefined | Filter by a single Farcaster user ID (e.g., `fid=12345`) | | `fids` | string (comma-separated numbers) | undefined | Filter by multiple Farcaster user IDs (e.g., `fids=123,456,789`) | | `pairAddress` | string | undefined | Filter by paired token contract address | | `sort` | string | `'desc'` | Sort order: `asc` (oldest first) or `desc` (newest first) | | `sortBy` | string | undefined | Sort field: `market-cap`, `tx-h24`, `price-percent-h24`, `price-percent-h1`, or `deployed-at` | | `socialInterface` | string | undefined | Filter by social interface (e.g., `clanker.world`, `Bankr`) | | `limit` | number | 10 | Number of results to return (max 20) | | `cursor` | string | undefined | Cursor for efficient pagination | | `includeUser` | boolean | false | Include creator profile data (avatar, name, bio, etc.) | | `includeMarket` | boolean | false | Include real-time market data (market cap, price change, volume) | | `startDate` | number | undefined | Filter tokens created after this Unix timestamp | | `chainId` | number | undefined | Filter by chain ID (e.g., `8453` for Base) | | `champagne` | boolean | false | Filter to show only champagne tokens | *** ### Example Requests #### Search by token name/symbol ```bash curl "https://www.clanker.world/api/tokens?q=EXAMPLE" ``` #### Search by single FID (creator) ```bash curl "https://www.clanker.world/api/tokens?fid=12345" ``` #### Search by FID with market data ```bash curl "https://www.clanker.world/api/tokens?fid=12345&includeMarket=true&sortBy=market-cap&sort=desc" ``` #### Search by contract address ```bash curl "https://www.clanker.world/api/tokens?q=0x525358b364b9bb38227054affdc37cecdd516b81" ``` *** ### Example Response ```json { "data": [ { "id": 12345, "created_at": "2024-12-15T14:30:00", "last_indexed": "2024-12-15T14:32:17.303", "tx_hash": "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef", "contract_address": "0xAbCdEf1234567890AbCdEf1234567890AbCdEf12", "name": "Example Token", "symbol": "EXAMPLE", "description": "This is an example token for demonstration purposes", "supply": "100000000000000000000000000000", "img_url": "https://example.com/images/token-logo.png", "pool_address": "0x9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba", "type": "clanker_v4", "pair": "WETH", "chain_id": 8453, "metadata": { "auditUrls": [], "description": "This is an example token for demonstration purposes", "socialMediaUrls": [ { "platform": "twitter", "url": "https://twitter.com/example_token" } ] }, "deployed_at": "2024-12-15T14:30:00", "msg_sender": "0x1111111111111111111111111111111111111111", "factory_address": "0x2222222222222222222222222222222222222222", "locker_address": "0x3333333333333333333333333333333333333333", "position_id": "0", "warnings": [], "pool_config": { "pairedToken": "0x4444444444444444444444444444444444444444", "tickIfToken0IsNewToken": -230400 } } ], "total": 1, "cursor": "eyJpZCI6IjIwMjQtMTItMTVUMTQ6MzA6MDAifQ==", "tokensDeployed": 1 } ``` *** ### Response Fields | Field | Description | | ---------------- | ---------------------------------------------------------------------- | | `data` | Array of token objects | | `total` | Total number of tokens matching the query | | `cursor` | Pagination cursor for next page (use in subsequent requests) | | `tokensDeployed` | Total number of tokens deployed (useful when filtering by creator FID) | *** ### Token Object Fields | Field | Description | | ------------------ | ------------------------------------------------------ | | `contract_address` | Token contract address | | `name` | Token name | | `symbol` | Token symbol | | `description` | Token description | | `img_url` | Token image URL | | `type` | Token type (e.g., `clanker_v4`, `clanker_v3_1`) | | `pair` | Trading pair (e.g., `WETH`, `DEGEN`) | | `chain_id` | Chain ID (e.g., `8453` for Base) | | `deployed_at` | Deployment timestamp | | `tx_hash` | Deployment transaction hash | | `pool_address` | Uniswap pool address | | `msg_sender` | Address that deployed the token | | `factory_address` | Clanker factory contract address | | `locker_address` | LP locker contract address | | `social_context` | Social media context (platform, messageId, etc.) | | `extensions` | Additional token features (fees, vault, airdrop, etc.) | | `warnings` | Array of warnings about the token configuration | | `related.user` | Creator profile data (only if `includeUser=true`) | | `related.market` | Market data (only if `includeMarket=true`) | *** ### Pagination Tips * Default limit is 10, maximum is 20 * Search is case-insensitive and matches both token names and symbols * Use the `cursor` from the response to fetch the next page of results * When searching by `fid`, `tokensDeployed` gives you the total count of tokens created by that user # Get Tokens by Creator Search for clanker tokens deployed by a Farcaster username or wallet address. ### Endpoint ``` GET https://clanker.world/api/search-creator ``` ### Query Parameters | Parameter | Type | Required | Default | Description | | ------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------- | | `q` | string | Yes | - | Search query: Farcaster username (e.g., `dish`) or wallet address (0x...) | | `limit` | integer | No | 20 | Number of results per page (1-50) | | `offset` | integer | No | 0 | Pagination offset for loading more results | | `sort` | string | No | `desc` | Sort order by deployment date: `asc` (oldest first) or `desc` (newest first) | | `trustedOnly` | boolean | No | false | When `true`, only returns verified/trusted tokens | ### Response #### Success Response (200 OK) ```json { "tokens": [ { "contract_address": "0x...", "name": "Token Name", "symbol": "TKN", "img_url": "https://...", "chain_id": 8453, "deployed_at": "2024-01-15T10:30:00.000Z", "created_at": "2024-01-15T10:30:00.000Z", "msg_sender": "0x...", "social_context": { "platform": "farcaster", "id": "12345" }, "related": { "market": { "marketCap": 50000, "price": 0.0001 } }, "trustStatus": { "isTrustedDeployer": false, "isTrustedClanker": false, "fidMatchesDeployer": true, "verifiedAddresses": ["0x..."] } } ], "user": { "fid": 12345, "username": "alice", "displayName": "Alice", "pfpUrl": "https://...", "verifiedAddresses": ["0x..."] }, "searchedAddress": "0x...", "total": 42, "hasMore": true } ``` #### Response Fields | Field | Type | Description | | ----------------- | ------- | ----------------------------------------------------------- | | `tokens` | array | Array of token objects with trust status | | `user` | object | Farcaster user info if found (may be `undefined`) | | `searchedAddress` | string | The wallet address used for searching (may be `undefined`) | | `total` | integer | Total number of tokens matching the query (after filtering) | | `hasMore` | boolean | Whether more results are available for pagination | #### Trust Status Each token includes a `trustStatus` object indicating verification level: | Field | Type | Description | | -------------------- | ------- | ---------------------------------------------------------------- | | `isTrustedDeployer` | boolean | Token was deployed by a known trusted deployer address | | `isTrustedClanker` | boolean | Token contract is on the allowlist | | `fidMatchesDeployer` | boolean | Creator's verified Farcaster address matches the deployer wallet | | `verifiedAddresses` | array | The token creator's verified Farcaster addresses | **Trust Levels (in order of priority):** 1. **Allowlisted** - Token is on the trusted clanker allowlist 2. **Trusted Deployer** - Deployed by an official clanker deployer contract 3. **FID Verified** - Creator's Farcaster verified address matches the deployer 4. **Unverified** - None of the above (exercise caution) #### Error Responses **400 Bad Request** ```json { "error": "Query parameter \"q\" is required" } ``` **500 Internal Server Error** ```json { "error": "Failed to search" } ``` ### Examples #### Search by Farcaster Username ```bash curl "https://clanker.world/api/search-creator?q=dish" ``` #### Search by Wallet Address ```bash curl "https://clanker.world/api/search-creator?q=0x1234567890abcdef1234567890abcdef12345678" ``` #### Paginated Request ```bash # First page curl "https://clanker.world/api/search-creator?q=alice&limit=20&offset=0" # Second page curl "https://clanker.world/api/search-creator?q=alice&limit=20&offset=20" ``` #### Filter Trusted Only, Sorted by Oldest ```bash curl "https://clanker.world/api/search-creator?q=alice&trustedOnly=true&sort=asc" ``` ### Notes * The API searches tokens by: * Farcaster FID (from username lookup) * Deployer address (`msg_sender`) * Admin address * Results are deduplicated by contract address * Invalid `limit`/`offset` values are automatically corrected to safe defaults * Maximum 50 results per request * Results are optimized for creators with up to \~1000 tokens ### Rate Limits Standard API rate limits apply. Contact support for higher limits. # Authenticated Authenticated API endpoints # Deploy Token (v4.0.0) Deploy a new token on Clanker v4.0.0 `POST` `https://www.clanker.world/api/tokens/deploy` #### **Headers** | Name | Value | | ------------ | ------------------ | | x-api-key | `your_api_key` | | Content-Type | `application/json` | #### **Body**
ParameterTypeRequiredDescription
token.namestringRequiredThe name of your token
token.symbolstringRequiredToken symbol (usually 3-5 characters)
token.imagestringOptionalURL to the token's image
token.tokenAdmin0x${string}RequiredToken admin address with control over vaulted tokens and updating token metadata
token.descriptionstringOptionalDescription of token for creators to provide
token.socialMediaUrlsarray of { platform: string, url: string }OptionalURLs for external pages related to the token
token.auditUrlsarrayOptionalLinks to any audits, reports, etc.
token.requestKeystringRequiredUnique 32 character unique request identifier
rewardsarrayRequiredArray of reward configuration objects (at least one required)
rewards.admin0x${string}RequiredAddress that can change the paired recipient
rewards.recipient0x${string}RequiredAddress that will receive the rewards once claimed
rewards.allocationnumberRequiredPercentage of rewards (total across all recipients should sum to 100)
rewards.rewardsTokenstringOptionalToken(s) in which the recipient will accrue rewards. Either "Both", "Clanker", or "Paired"
pool.typestringsOptionalEither "standard" or "project"
pool.pairedToken0x${string}OptionalToken address to pair the new token with (typically WETH). Only for standard pool.type
pool.initialMarketCapnumberOptionalStarting market cap denominated in pairedToken. Only for standard pool.type
fees.typestringOptionalFee type: either "static" or "dynamic"
fees.clankerFeenumberOptionalFee percentage on Clanker token inputs, max 5 (5%). Only for static fees.type
fees.pairedFeenumberOptionalFee percentage on pairedToken inputs, max 5 (5%). Only for static fees.type
fees.baseFeenumberOptionalBase fee charged on every swap, minimum 0.25 (0.25%). Only for dynamic fees.type
fees.maxLpFeenumberOptionalMaximum LP fee including base + variable fee, maximum 5 (5%). Only for dynamic fees.type
vault.percentagenumberOptionalPercentage of tokens to vault (max 90% total across all extensions)
vault.lockupDurationnumberConditionalLockup duration in days, minimum 7. Required if vault.percentage is provided
vault.vestingDurationnumberConditionalVesting duration in days, can be 0 for instant vesting. Required if vault.percentage is provided
airdrop.entries

array of
{ account: 0x...,

amount: number }

ConditionalAirdrop participants list of address and amount of tokens allocated
airdrop.lockupDurationnumberConditionalAmount of days until the airdrop is claimable, minimum of 1 day
airdrop.vestingDurationnumberConditionalAmount of days for the airdrop to to fully vest on a linear schedule
chainIdnumberoptionalchain to deploy the clanker token on. Options:
8453: Base (default)
130: Unichain
42161: Arbitrum One
#### **Response** {% tabs %} {% tab title="200" %} ```json { "message": "Token deployment enqueued. Expected address: [contract_address]", "expectedAddress": "[contract_address]", "success": true } ``` {% endtab %} {% tab title="400" %} ```json { "data": [ { "code": "validation_error", "path": ["field_name"], "message": "Description of the validation error" } ], "error": "Invalid input. See data for details." } ``` {% endtab %} {% endtabs %} #### **Example Request** {% tabs %} {% tab title="cURL" %} ```bash curl -X POST 'https://www.clanker.world/api/tokens/deploy/v4' \ -H 'Content-Type: application/json' \ -H 'x-api-key: your_api_key_here' \ -d '{ "token": { "name": "DemoToken", "symbol": "DEMO", "image": "https://example.com/demo-token-logo.png", "tokenAdmin": "0x742d35Cc6634C0532925a3b8D4C9db7cd4b5b31D", "description": "Clanker v4.0.0", "socialMediaUrls": [ "https://x.com/demotoken", "https://t.me/demotoken" ], "auditUrls": [ "https://example.com/audit-report-1.pdf", "https://example.com/security-review.pdf" ], "requestKey": "abcdef1234567890abcdef1234567890" }, "rewards": [ { "admin": "0x742d35Cc6634C0532925a3b8D4C9db7cd4b5b31D", "recipient": "0x742d35Cc6634C0532925a3b8D4C9db7cd4b5b31D", "allocation": 50, "rewardsToken": "Both" }, { "admin": "0x8ba1f109551bD432803012645Hac136c3c89d97c", "recipient": "0x8ba1f109551bD432803012645Hac136c3c89d97c", "allocation": 30, "rewardsToken": "Clanker" }, { "admin": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984", "recipient": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984", "allocation": 20, "rewardsToken": "Paired" } ], "pool": { "type": "standard", "pairedToken": "0x4200000000000000000000000000000000000006", "initialMarketCap": 10 }, "fees": { "type": "static", "clankerFee": 1, "pairedFee": 1 }, "vault": { "percentage": 15, "lockupDuration": 30, "vestingDuration": 0 }, "airdrop": { "entries": [ { "account": "0xD98124a9Fb88fC61E84575448C853d530a872674", "amount": 250000000 } ], "lockupDuration": 30, "vestingDuration": 30 }, "chainId": 8453 }' ``` {% endtab %} {% tab title="JavaScript" %} ```javascript const deployToken = async () => { try { const response = await fetch('https://www.clanker.world/api/tokens/deploy/v4', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your_api_key_here' }, body: JSON.stringify({ token: { name: "DemoToken", symbol: "DEMO", image: "https://example.com/demo-token-logo.png", tokenAdmin: "0x742d35Cc6634C0532925a3b8D4C9db7cd4b5b31D", description: "Clanker v4.0.0", socialMediaUrls: [ "https://x.com/demotoken", "https://t.me/demotoken" ], auditUrls: [ "https://example.com/audit-report-1.pdf", "https://example.com/security-review.pdf" ], requestKey: "abcdef1234567890abcdef1234567890" }, rewards: [ { admin: "0x742d35Cc6634C0532925a3b8D4C9db7cd4b5b31D", recipient: "0x742d35Cc6634C0532925a3b8D4C9db7cd4b5b31D", allocation: 50, rewardsToken: "Both" }, { admin: "0x8ba1f109551bD432803012645Hac136c3c89d97c", recipient: "0x8ba1f109551bD432803012645Hac136c3c89d97c", allocation: 30, rewardsToken: "Clanker" }, { admin: "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984", recipient: "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984", allocation: 20, rewardsToken: "Paired" } ], pool: { type: "standard", pairedToken: "0x4200000000000000000000000000000000000006", initialMarketCap: 10 }, fees: { type: "static", clankerFee: 1, pairedFee: 1 }, vault: { percentage: 15, lockupDuration: 30, vestingDuration: 0 } }) }); if (!response.ok) { const errorData = await response.json(); throw new Error(errorData.error || `HTTP error! status: ${response.status}`); } const data = await response.json(); console.log('Token deployment successful:', data); return data; } catch (error) { console.error('Token deployment failed:', error); throw error; } }; deployToken() .then(result => { console.log('Expected address:', result.expectedAddress); }) .catch(error => { console.error('Error:', error); }); ``` {% endtab %} {% endtabs %} #### **Notes** **Rewards Configuration** * At least one reward configuration is required. * Up to 7 total reward recipients are allowed. * Total allocation across all recipients must sum to 100 (100%). * Admin addresses can change the recipient address but allocation percentages are immutable. {% hint style="warning" %} With the v4.0.0 deployment endpoint, token creation interfaces must include their own reward configuration if they wish to receive any rewards for v4.0.0 tokens. {% endhint %} * Each reward recipient may have a designated `rewardsToken` set. This specifies the token in which the recipient will accrue rewards in, irrespective of how the fees are set to be collected via the Fee Configuration. * Defaults * `rewardsToken` defaults to `Paired` , so rewards recipients will accrue rewards in only the paired token (typically WETH) **Pool Configuration (optional)** * Choose a paired token from the list of [Supported Quote Tokens](/documentation/references/supported-quote-tokens) along with the starting market cap of the token, denominated in the paired token. * Defaults * "Standard" pool configuration with single LP position. * Quote token is set to WETH (0x4200000000000000000000000000000000000006) if no `pairedToken` is provided. * Starting market cap is set to the Approximate Starting Market Cap column in the [Supported Quote Tokens](/documentation/references/supported-quote-tokens) table if no `initialMarketCap` is provided. **Fee Configuration (optional)** * Choose either `static` or `dynamic` fee type, not both. * Static fees apply fixed percentages to specific token inputs (no min, 5% max). * Dynamic fees include a base fee plus variable fees based on volatility and are applied to equally to both token inputs (0.25% min, 5% max). * Defaults * Fee configuration defaults to a 1% static fee on both token inputs if not provided. * If `static` is selected, the static fee configuration defaults to a 1% static fee on both token inputs if not specified. * If `dynamic` is selected, the dynamic fee configuration defaults to a 0.5% base fee and 5% max LP fee if not specified. **Vault Extension (optional)** * Optional feature for locking tokens with configurable lockup and vesting periods. * Maximum 90% of total supply can be allocated across all extensions. * Minimum `lockupDuration` is 7 days, no minimum vesting duration. * There is no minimum `vestingDuration`, as setting `vestingDuration` to 0 allows all vaulted tokens to be claimed once `lockupDuration` ends. # Get Token by Address Retrieve detailed information about a Clanker token using its contract address. ```bash GET https://www.clanker.world/api/get-clanker-by-address ``` **Headers:** ``` x-api-key: your_api_key ``` **Query Parameters:** | Parameter | Type | Description | | --------- | ------ | ---------------------------------------------- | | `address` | string | Ethereum address of the Clanker token contract | **Example Request:** ```bash curl -X GET \ 'https://www.clanker.world/api/get-clanker-by-address?address=0x1bc0c42215582d5A085795f4baDbaC3ff36d1Bcb' \ -H 'x-api-key: your_api_key' ``` ### Response Format **Example Response:** ```json { "data": { "id": 241400, "created_at": "2025-04-15T00:16:39.464442+00:00", "tx_hash": "0x581b54f7b59def7483eb0306d924f82910582d3d024f2dd9a2195341eacd43b9", "contract_address": "0x6270BCB5398927335AEf599EdD1CC666FcC77797", "name": "deployer", "symbol": "$deployer", "pool_address": "0x213264B1Bc0F39f705687fdaBe97E8b3F8B3455F", "cast_hash": "bankr deployment", "type": "clanker_v3_1", "pair": "WETH", "chain_id": 8453, "metadata": { "auditUrls": [], "description": "", "socialMediaUrls": [] }, "deploy_config": { "devBuyAmount": 0, "lockupPercentage": 0, "vestingUnlockDate": 0 }, "social_context": { "interface": "Bankr", "messageId": "bankr deployment", "id": "886870" "platform": "Farcaster" }, "requestor_fid": 886870, "deployed_at": "2025-04-15T00:16:35", "msg_sender": "0x2112b8456AC07c15fA31ddf3Bf713E77716fF3F9", "factory_address": "0x2A787b2362021cC3eEa3C24C4748a6cD5B687382", "locker_address": "0x33e2Eda238edcF470309b8c6D228986A1204c8f9", "warnings": [], "pool_config": { "pairedToken": "0x4200000000000000000000000000000000000006", "tickIfToken0IsNewToken": -230400 }, "starting_market_cap": 9.870869513221747 }, } ``` #### Response Fields | Field | Type | Description | | ------ | ------ | -------------------------------------------------- | | `data` | object | Container object for the Clanker token information | #### Token Object Fields | Field | Type | Description | | --------------------- | --------------- | ---------------------------------------------------------------------------- | | id | number | Unique identifier for the token | | created\_at | string | ISO 8601 timestamp of token creation | | tx\_hash | string | Transaction hash of the deployment | | contract\_address | string | Token contract address | | requestor\_fid | integer | Farcaster ID of the token requestor | | name | string | Token name | | symbol | string | Token symbol | | img\_url | string | URL of the token's image | | pool\_address | string | Address of the token's liquidity pool | | cast\_hash | string | Associated Farcaster cast hash | | type | string \| null | Token type identifier | | pair | string \| null | Trading pair identifier | | presale\_id | integer \| null | ID of associated presale if applicable | | chain\_id | integer | Blockchain chain ID | | metadata | string | Additional token metadata | | deploy\_config | object | Deployment configuration details: creator buy, creator vault, etc. | | social\_context | object | Social context of the token creation | | deployed\_at | string | Timestamp of token deployment | | msg\_sender | string | Address that sent the deployment transaction | | factory\_address | string | Address of the Clanker token factory conract | | locker\_address | string | Address of the Clanker token locker contract | | warnings | array | Array of warning flags. See "Warning Flags" section below | | starting\_market\_cap | number | Starting market cap of the pool denominated in the quote token | | pool\_config | object | Pool configuration details: quote token address and initial tick of the pool | {% hint style="danger" %} ### Warning Flags * `UNUSUAL_TICK` * WETH-denominated tokens with a starting market cap of < 1 ETH (WETH) * Non-WETH tokens listed in [Supported Quote Tokens](/documentation/references/supported-quote-tokens) with pools that do not match the initial tick listed in that table * `UNUSUAL_PAIR_ADDRESS` * Tokens paired with a quote token not listed in [Supported Quote Tokens](/documentation/references/supported-quote-tokens) * `MISSING_POOL_CONFIG` * Tokens with incomplete or missing pool configuration info. These are primary legacy tokens that were deployed with a standard configuration {% endhint %} {% hint style="info" %} #### Notes * The `created_at` timestamp is returned in UTC timezone * The `img_url` field provides a direct link to the token's image asset * The `requestor_fid` can be used to link to the token creator's Farcaster profile {% endhint %} # Get Tokens Deployed by Address Retrieve all tokens deployed by a specific Ethereum address. ```bash GET https://www.clanker.world/api/tokens/fetch-deployed-by-address ``` **Headers:** ``` x-api-key: your_api_key ``` **Query Parameters:** | Parameter | Type | Description | | --------- | ------ | ------------------------------------ | | `address` | string | Ethereum address to fetch tokens for | | `cursor` | string | key for pagination | **Example Request:** {% code overflow="wrap" %} ```bash curl -X GET \ 'https://www.clanker.world/api/tokens/fetch-deployed-by-address?address=user_eth_address&cursor=eyJpZCI6IjIwMjUtMTEtMTlUMTM6MzA6NDcifQ==' \ -H 'x-api-key: your_api_key' ``` {% endcode %} ### Response Format **Example Response:** ```json { "data": [ { "id": 241400, "created_at": "2025-04-15T00:16:39.464442+00:00", "tx_hash": "0x581b54f7b59def7483eb0306d924f82910582d3d024f2dd9a2195341eacd43b9", "contract_address": "0x6270BCB5398927335AEf599EdD1CC666FcC77797", "name": "deployer", "symbol": "$deployer", "pool_address": "0x213264B1Bc0F39f705687fdaBe97E8b3F8B3455F", "cast_hash": "bankr deployment", "type": "clanker_v3_1", "pair": "WETH", "chain_id": 8453, "metadata": { "auditUrls": [], "description": "", "socialMediaUrls": [] }, "deploy_config": { "devBuyAmount": 0, "lockupPercentage": 0, "vestingUnlockDate": 0 }, "social_context": { "interface": "Bankr", "messageId": "bankr deployment", "id": "886870" "platform": "Farcaster" }, "requestor_fid": 886870, "deployed_at": "2025-04-15T00:16:35", "msg_sender": "0x2112b8456AC07c15fA31ddf3Bf713E77716fF3F9", "factory_address": "0x2A787b2362021cC3eEa3C24C4748a6cD5B687382", "locker_address": "0x33e2Eda238edcF470309b8c6D228986A1204c8f9", "warnings": [], "pool_config": { "pairedToken": "0x4200000000000000000000000000000000000006", "tickIfToken0IsNewToken": -230400 }, "starting_market_cap": 9.870869513221747 }, { "id": 241399, "created_at": "2025-04-15T00:15:37.032429+00:00", "tx_hash": "0x0088ae9400e6cc0de3414bd4b9ad13d68c6822b05a4895fa14a4181cb0ef4b58", "contract_address": "0x6B2B40bF4c0c6734fd738f7090e8D694C817e91D", "name": "Pokemon", "symbol": "PKMON", "img_url": "https://pbs.twimg.com/media/GogsV0mWIAA6YnY.jpg", "pool_address": "0xf8827866d4bd7a8Ef237a457d5924C87E702Da81", "cast_hash": "https://twitter.com/millionbby12/status/1911936222257197369", "type": "clanker_v3_1", "pair": "WETH", "chain_id": 8453, "metadata": { "auditUrls": [], "description": "Deployed using Bankr on X", "socialMediaUrls": [] }, "deploy_config": "{\"devBuyAmount\":0,\"lockupPercentage\":0,\"vestingUnlockDate\":0}", "social_context": "{\"interface\":\"Bankr\",\"messageId\":\"https://twitter.com/millionbby12/status/1911936222257197369\",\"id\":\"886870\"}", "requestor_fid": 886870, "deployed_at": "2025-04-15T00:15:33", "msg_sender": "0x2112b8456AC07c15fA31ddf3Bf713E77716fF3F9", "factory_address": "0x2A787b2362021cC3eEa3C24C4748a6cD5B687382", "locker_address": "0x33e2Eda238edcF470309b8c6D228986A1204c8f9", "warnings": [], "pool_config": { "pairedToken": "0x4200000000000000000000000000000000000006", "tickIfToken0IsNewToken": -230400 }, "starting_market_cap": 9.870869513221747 }, ], "hasMore": true, "total": 55 } ``` #### Response Fields **Top-Level Fields:** | Field | Type | Description | | --------- | ------- | ---------------------------------------------- | | `data` | array | Array of token objects | | `hasMore` | boolean | Indicates if there are more pages of results | | `total` | integer | Total number of tokens deployed by the address | **Data Object Fields:** | Field | Type | Description | | --------------------- | --------------- | ---------------------------------------------------------------------------- | | id | number | Unique identifier for the token | | created\_at | string | ISO 8601 timestamp of token creation | | tx\_hash | string | Transaction hash of the deployment | | contract\_address | string | Token contract address | | requestor\_fid | integer | Farcaster ID of the token requestor | | name | string | Token name | | symbol | string | Token symbol | | img\_url | string | URL of the token's image | | pool\_address | string | Address of the token's liquidity pool | | cast\_hash | string | Associated Farcaster cast hash | | type | string \| null | Token type identifier | | pair | string \| null | Trading pair identifier | | presale\_id | integer \| null | ID of associated presale if applicable | | chain\_id | integer | Blockchain chain ID | | metadata | string | Additional token metadata | | deploy\_config | object | Deployment configuration details: creator buy, creator vault, etc. | | social\_context | object | Social context of the token creation | | deployed\_at | string | Timestamp of token deployment | | msg\_sender | string | Address that sent the deployment transaction | | factory\_address | string | Address of the Clanker token factory conract | | locker\_address | string | Address of the Clanker token locker contract | | warnings | array | Array of warning flags. See "Warning Flags" section below | | starting\_market\_cap | number | Starting market cap of the pool denominated in the quote token | | pool\_config | object | Pool configuration details: quote token address and initial tick of the pool | ### Warning Flags * `UNUSUAL_TICK` * WETH-denominated tokens with a starting market cap of < 1 ETH (WETH) * Non-WETH tokens listed in [Supported Quote Tokens](/documentation/references/supported-quote-tokens) with pools that do not match the initial tick listed in that table * `UNUSUAL_PAIR_ADDRESS` * Tokens paired with a quote token not listed in [Supported Quote Tokens](/documentation/references/supported-quote-tokens) * `MISSING_POOL_CONFIG` * Tokens with incomplete or missing pool configuration info. These are primary legacy tokens that were deployed with a standard configuration ### Best Practices 1. Cache responses when appropriate to minimize calls 2. Handle null values for optional fields like `img_url` 3. Validate Ethereum addresses before making requests # \[DEPRECATED] Get Estimated Rewards Get estimated rewards for a specific token pool address. {% hint style="warning" %} This enpoint has been deprecated. Instead, use this SDK method to get token rewards: {% endhint %} ```bash GET https://www.clanker.world/api/tokens/estimate-rewards-by-pool-address ``` ~~**Headers:**~~ ``` x-api-key: your_api_key ``` ~~**Query Parameters:**~~ | Parameter | Type | Description | | ------------- | ------ | ------------------------------------- | | `poolAddress` | string | Address of the token's liquidity pool | ~~**Example Request:**~~ ```bash curl -X GET \ 'https://www.clanker.world/api/tokens/estimate-rewards-by-pool-address?poolAddress=pool_address' \ -H 'x-api-key: your_api_key' ``` ### ~~Response Format~~ ~~**Example Response:**~~ ```json { "userRewards": 4051.7574064199907 } ``` #### ~~Response Fields~~
FieldTypeDescription
userRewardsnumberEstimated rewards value in USD for the specified pool
### ~~Notes~~ * ~~The rewards value is returned as a floating-point number~~ * ~~Results are estimates and may vary from actual rewards~~ * ~~Values are calculated based on current prices of tokens in the pool~~ # \[DEPRECATED] Get Uncollected Fees Get estimated uncollected fees (in base and quote tokens) for a specific token contract. {% hint style="info" %} This enpoint has been deprecated. Instead, use this SDK method to get token rewards: {% endhint %} ~~**V3.1:**~~ ```bash GET https://www.clanker.world/api/get-estimated-uncollected-fees/[contract_address] ``` {% hint style="warning" %} ~~**For v4 clankers**: you must include the reward recipient address you are getting the uncollected fee amounts for, as multiple reward recipients may be assigned for the token.~~ {% endhint %} ~~**V4:**~~ ``` GET https://www.clanker.world/api/get-estimated-uncollected-fees/[contract_address]?rewardRecipientAddress=[reward_recipient_address] ``` ~~**Headers:**~~ ``` x-api-key: your_api_key ``` ~~**Query Parameters:**~~
ParameterTypeDescription
contract_addressstringThe token contract address to query
rewardRecipientAddress
stringThe reward recipient address (required for v4's)
~~**Example Request (v3.1):**~~ ```bash curl -X GET \ 'https://www.clanker.world/api/get-estimated-uncollected-fees/[token_address]' \ -H 'x-api-key: your_api_key' ``` ~~**Example Request (v4):**~~ ``` curl -X GET 'http://localhost:3000/api/get-estimated-uncollected-fees/[token_address]?rewardRecipientAddress=[reward_recipient_address]' \ -H 'x-api-key: your_api_key' | jq ``` ### ~~Response Format~~ ~~**Example Response:**~~ ```json { "lockerAddress": "0x618A9840691334eE8d24445a4AdA4284Bf42417D", "lpNftId": 1605020, "token1UncollectedRewards": "25549999999999", "token0UncollectedRewards": "256188371342895862809729", "token0": { "chainId": 8453, "address": "0x054E4121a946da752a5Cab371BE52B2E6A897ba8", "symbol": "MTK", "decimals": 18, "name": "My Token" }, "token1": { "chainId": 8453, "address": "0x4200000000000000000000000000000000000006", "symbol": "WETH", "decimals": 18, "name": "Wrapped Ether" } } ``` #### ~~Response Fields~~ ~~**Top-Level Fields:**~~ | Field | Type | Description | | -------------------------- | ------- | ------------------------------------------------ | | `lockerAddress` | string | Address of the fee locker contract | | `lpNftId` | integer | Unique identifier for the liquidity position NFT | | `token0UncollectedRewards` | string | Uncollected rewards for token0 (in base units) | | `token1UncollectedRewards` | string | Uncollected rewards for token1 (in base units) | | `token0` | object | Details of the first token in the pair | | `token1` | object | Details of the second token in the pair | ~~**Token Object Fields:**~~ | Field | Type | Description | | ---------- | ------- | -------------------------------------- | | `chainId` | integer | Chain ID where the token is deployed | | `address` | string | Token contract address | | `symbol` | string | Token symbol | | `decimals` | integer | Number of decimal places for the token | | `name` | string | Token name | # Index Token Manually trigger indexing of a token deployment transaction. ### Endpoint ``` POST https://clanker.world/api/tokens/index ``` ### Authentication Requires a valid partner API key passed in the `x-api-key` header. API keys are validated against the `partners` table in the database. ### Rate Limiting * **10 requests per minute** per IP address * Returns `429 Too Many Requests` when limit is exceeded ### Request #### Headers | Header | Required | Description | | -------------- | -------- | ---------------------------------- | | `Content-Type` | Yes | Must be `application/json` | | `x-api-key` | Yes | Partner API key for authentication | #### Body | Field | Type | Required | Description | | --------- | -------- | -------- | ------------------------------------------------------------------------- | | `txHash` | `string` | Yes | Transaction hash of the token deployment (0x-prefixed, 64 hex characters) | | `chainId` | `number` | Yes | Chain ID where the token was deployed | #### Supported Chain IDs | Chain | Chain ID | | -------- | -------- | | Base | `8453` | | Monad | `143` | | Arbitrum | `42161` | | Unichain | `130` | | Ethereum | `1` | ### Response #### Success (200) ```json { "success": true, "address": "0x1234567890abcdef1234567890abcdef12345678", "url": "/clanker/0x1234567890abcdef1234567890abcdef12345678" } ``` #### Error Responses | Status | Error | Description | | ------ | --------------------------------- | ------------------------------------ | | `400` | `Invalid transaction hash format` | txHash is missing or not a valid hex | | `400` | `Unsupported chain` | chainId is missing or not supported | | `400` | `Failed to index transaction` | Indexer could not process the tx | | `401` | `API key is required` | Missing x-api-key header | | `401` | `Unauthorized` | Invalid API key | | `429` | `Too many requests...` | Rate limit exceeded | | `500` | `Internal server error` | Unexpected server error | ### Example #### cURL ```bash curl -X POST https://clanker.world/api/tokens/index \ -H "Content-Type: application/json" \ -H "x-api-key: YOUR_API_KEY" \ -d '{ "txHash": "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef", "chainId": 143 }' ``` #### JavaScript (fetch) ```javascript const response = await fetch('https://clanker.world/api/tokens/index', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'YOUR_API_KEY', }, body: JSON.stringify({ txHash: '0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef', chainId: 143, }), }); const data = await response.json(); console.log(data); // { success: true, address: "0x...", url: "/clanker/0x..." } ``` ### Notes * The endpoint indexes the token synchronously and returns the token address on success * Ensure the token deployment transaction has been confirmed prior to fetching the indexing * If the token has already been indexed, it will update the existing record * After successful indexing, the token will be available at the returned URL # Get Tokens by Admin Retrieves a paginated list of tokens where the specified address is the token admin. ### Endpoint ``` GET /api/tokens/fetch-by-admin ``` ### Authentication This endpoint requires API key authentication. | Header | Required | Description | | ----------- | -------- | ------------------------------- | | `x-api-key` | Yes | Your API key for authentication | ### Query Parameters | Parameter | Type | Required | Default | Description | | --------------- | --------- | -------- | ------- | ------------------------------------------------------------- | | `admin` | `string` | Yes | - | The admin wallet address (0x...) to filter tokens by | | `limit` | `number` | No | `10` | Number of tokens to return per page (min: 1, max: 200) | | `cursor` | `string` | No | - | Pagination cursor for fetching the next page of results | | `chainId` | `number` | No | - | Filter by specific chain ID (e.g., `8453` for Base) | | `includeUser` | `boolean` | No | `false` | Include user/creator data in the response | | `includeMarket` | `boolean` | No | `false` | Include market data (price, market cap, etc.) in the response | ### Response #### Success (200 OK) ```json { "data": [ { "id": "uuid", "contract_address": "0x...", "name": "Token Name", "symbol": "TKN", "admin": "0x...", "chain_id": 8453, "deployed_at": "2024-01-01T00:00:00.000Z", "pool_address": "0x...", "img_url": "https://...", ... } ], "total": 42, "cursor": "eyJpZCI6Ii4uLiJ9" } ``` | Field | Type | Description | | -------- | ---------------- | --------------------------------------------------- | | `data` | `array` | Array of token objects | | `total` | `number` | Total number of tokens matching the query | | `cursor` | `string \| null` | Cursor for the next page, `null` if no more results | #### Error Responses **401 Unauthorized** Missing or invalid API key. ```json { "error": "API key is required" } ``` **400 Bad Request** Missing or invalid admin address. ```json { "error": "Admin address is required" } ``` ```json { "error": "Invalid admin address" } ``` ### Examples #### Basic Request ```bash curl -X GET "https://clanker.world/api/tokens/fetch-by-admin?admin=0x1234567890abcdef1234567890abcdef12345678" \ -H "x-api-key: your-api-key" ``` #### With Pagination ```bash curl -X GET "https://clanker.world/api/tokens/fetch-by-admin?admin=0x1234567890abcdef1234567890abcdef12345678&limit=20&cursor=eyJpZCI6Ii4uLiJ9" \ -H "x-api-key: your-api-key" ``` #### With All Options ```bash curl -X GET "https://clanker.world/api/tokens/fetch-by-admin?admin=0x1234567890abcdef1234567890abcdef12345678&limit=50&chainId=8453&includeUser=true&includeMarket=true" \ -H "x-api-key: your-api-key" ``` #### JavaScript/TypeScript Example ```typescript const response = await fetch( 'https://clanker.world/api/tokens/fetch-by-admin?' + new URLSearchParams({ admin: '0x1234567890abcdef1234567890abcdef12345678', limit: '20', includeMarket: 'true', }), { headers: { 'x-api-key': 'your-api-key', }, } ); const { data, total, cursor } = await response.json(); ``` ### Pagination To paginate through results: 1. Make an initial request without a `cursor` 2. If the response includes a `cursor` value, use it in your next request 3. Continue until `cursor` is `null` or undefined ```typescript let cursor: string | undefined; const allTokens = []; do { const params = new URLSearchParams({ admin: '0x...', limit: '50' }); if (cursor) params.set('cursor', cursor); const response = await fetch(`/api/tokens/fetch-by-admin?${params}`, { headers: { 'x-api-key': 'your-api-key' }, }); const result = await response.json(); allTokens.push(...result.data); cursor = result.cursor; } while (cursor); ``` ### Rate Limits Authenticated requests are subject to standard API rate limits. Contact support for rate limit details. # Get Claimed Fees \[beta] Returns claimed fee history for a specific v4 token and fee recipient address. Data is sourced from indexed on-chain ClaimedRewards events since February 2nd, 2026 (until we run a complete backfill). ### Endpoint ``` GET /api/get-claimed-fees/{tokenAddress}/{feeRecipient} ``` ### Authentication Requires a valid partner API key passed via the `x-api-key` header. | Header | Required | Description | | ----------- | -------- | --------------- | | `x-api-key` | Yes | Partner API key | ### Path Parameters | Parameter | Type | Required | Description | | -------------- | -------- | -------- | ------------------------------------- | | `tokenAddress` | `string` | Yes | The Clanker token contract address | | `feeRecipient` | `string` | Yes | The fee recipient (fee owner) address | Both addresses must be valid Ethereum addresses (checksummed or lowercase). ### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | -------- | -------- | ------- | ---------------------------------------- | | `chainId` | `number` | No | `8453` | Chain ID (defaults to Base mainnet) | | `limit` | `number` | No | `50` | Number of tx hashes to return (max 100) | | `offset` | `number` | No | `0` | Number of records to skip for pagination | #### Supported Chains | Chain | Chain ID | | ------------- | -------- | | Base | `8453` | | Base Sepolia | `84532` | | Arbitrum | `42161` | | Monad Testnet | `10143` | ### Response #### 200 OK ```json { "tokenAddress": "0x9f86dB9fc6f7c9408e8Fda3Ff8ce4e78ac7a6b07", "feeRecipient": "0xF60633D02690e2A15A54AB919925F3d038Df163e", "chainId": 8453, "totalClaimed": "1789486765760743877", "claimCount": 15274, "txHashes": [ "0x43a117b1a5345d6ac56a4b7fb2a6d11654ce1835ba12b78acefb9d5cf38799c7", "0x1de665b41ef55e3cd966163e40c55a6a0bc0be33a17d07eb69cc978b240f611d", "0xf18645b103e71a952c38888e8af7bd9a7c295b63c35f75b3c1a3f3cfc4ca05c9" ], "pagination": { "limit": 50, "offset": 0, "hasMore": true } } ``` | Field | Type | Description | | -------------- | ---------- | ---------------------------------------------------------- | | `tokenAddress` | `string` | Checksummed token contract address | | `feeRecipient` | `string` | Checksummed fee recipient address | | `chainId` | `number` | Chain ID used for the query | | `totalClaimed` | `string` | Total claimed amount in wei (sum of **all** claims) | | `claimCount` | `number` | Total number of claim events (across all pages) | | `txHashes` | `string[]` | Transaction hashes for the current page, most recent first | | `pagination` | `object` | Pagination metadata | **Pagination Object** | Field | Type | Description | | --------- | --------- | ------------------------------------------- | | `limit` | `number` | Number of results per page | | `offset` | `number` | Current offset | | `hasMore` | `boolean` | Whether more results exist beyond this page | #### 400 Bad Request ```json { "error": "Invalid token address" } ``` ```json { "error": "Invalid fee recipient address" } ``` ```json { "error": "Unsupported chain" } ``` #### 401 Unauthorized ```json { "error": "API key is required" } ``` ```json { "error": "Unauthorized" } ``` #### 500 Internal Server Error ```json { "error": "Failed to fetch claimed fees" } ``` ### Caching Responses are cached for 60 seconds with a 120-second stale-while-revalidate window. ### Example ```bash # First page (default limit=50, offset=0) curl -H "x-api-key: YOUR_API_KEY" \ "https://clanker.world/api/get-claimed-fees/0x9f86dB9fc6f7c9408e8Fda3Ff8ce4e78ac7a6b07/0xF60633D02690e2A15A54AB919925F3d038Df163e?chainId=8453" # Paginated request curl -H "x-api-key: YOUR_API_KEY" \ "https://clanker.world/api/get-claimed-fees/0x9f86dB9fc6f7c9408e8Fda3Ff8ce4e78ac7a6b07/0xF60633D02690e2A15A54AB919925F3d038Df163e?chainId=8453&limit=20&offset=40" ``` # Core Contracts {% content-ref url="/pages/fOTIabyVqIakp48nyHnV" %} [v4](/documentation/references/core-contracts/v4) {% endcontent-ref %} {% content-ref url="/pages/JPda6c92ea2Zv7urf2y7" %} [v3.1](/documentation/references/core-contracts/v3.1) {% endcontent-ref %} # v4 Overview of Clanker's v4 contracts Clanker v4 introduces a modular framework, allowing for individual components that can be swapped out and upgraded as needed. The code can be found [here](https://github.com/clanker-devco/v4-contracts). ## Core Contracts Clanker v4 consists of three main contracts that are non-upgradeable and can be expected to remain unchanged throughout the lifetime of v4: * **Clanker**: The factory contract responsible for token deployment, triggering pool creation, triggering liquidity placement via the LpLocker, and triggering extensions. * [**ClankerFeeLocker**](/documentation/references/core-contracts/v4/fee-management-contracts/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**](broken://pages/HGVc2v9wR2qwSWuJ3phT): A super-chain compatible ERC20 contract. A new contract is deployed for every call to `deployToken()`. Clanker v4 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 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 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 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 includes the following contracts which implement the above interfaces. #### IClankerHooks: v4.0 * [**ClankerHook**](/documentation/references/core-contracts/v4/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**](/documentation/references/core-contracts/v4/clankerhook/clankerhookstaticfee): An extension of the ClankerHook which enables users to set a static fee for both the deployed token and the paired token. * [**ClankerHookDynamicFee**](/documentation/references/core-contracts/v4/clankerhook/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. v4.1 * [**ClankerHookV2**](/documentation/references/core-contracts/v4/clankerhook/clankerhookdynamicfee): The same as ClankerHook but with expanded capabilities including [Pool Extensions](/documentation/references/core-contracts/v4/clankerhookv2/pool-extensions) and mev modules that can change the applied LP fee. * [**ClankerHookStaticFeeV2**](/documentation/references/core-contracts/v4/clankerhookv2/clankerhookstaticfeev2): The same as ClankerHookStaticFee except with ClankerHookV2 as the base instead of ClankerHook. * [**ClankerHookDynamicFeeV2**](/documentation/references/core-contracts/v4/clankerhookv2/clankerhookdynamicfeev2): The same as ClankerHookDynamicFee except with ClankerHookV2 as the base instead of ClankerHook. #### IClankerLPLockers: * [**ClankerLpLockerFeeConvesrion**](/documentation/references/core-contracts/v4/fee-management-contracts/clankerlplockerfeeconversion): A locker implementation which enables 7 different reward recipients to be specified and 7 different initial LP positions to be placed, each able to specify which token they prefer to accumulate fees in. This locker works with the IClankerHook implementations to automatically collect LP fees on every swap and distribute the fees to reward recipients via the ClankerFeeLocker. #### IClankerExtensions: * [**ClankerVault**](/documentation/references/core-contracts/v4/extensions/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**](/documentation/references/core-contracts/v4/extensions/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. * [**ClankerAirdropV2**](/documentation/references/core-contracts/v4/extensions/clankerairdropv2): Similar to ClankerAirdrop but with more admin controls and the ability to change the merkle root post launch. * [**ClankerUniv4EthDevBuy**](/documentation/references/core-contracts/v4/extensions/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: v4.0 * [**ClankerMevModule2BlockDelay**](/documentation/references/core-contracts/v4/mev-modules): 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. * [**ClankerSniperAuctionV0**](/documentation/references/core-contracts/v4/mev-modules/clankersniperauctionv0): A MEV module for priority ordered L2s that auctions off the first swaps on a block, directing the auction fees to token creators. v4.1 * [**ClankerMevDescendingFees**](/documentation/references/core-contracts/v4/mev-modules/clankermevdescendingfees): A MEV module which enables deployers to select a starting LP fee (up to 80%), an ending fee, and a duration to decay the fee over (max 2 mintues). The fee descends parabolically. * [**ClankerSniperAuctionV2**](/documentation/references/core-contracts/v4/mev-modules/clankersniperauctionv2): The same as ClankerSniperAuctionV0 but with the fee behavior of ClankerMevDescendingFees. Auctioned swaps pay the starting fee and the fee descent starts after the auction ends. # Deployment Config Documentation of v4's Token Deployment Parameters ## Token Deployment Tokens are deployed through the permissionless deployToken() function on the Clanker factory. All fields are expected to be filled out and additional info for each section can be found in the section's subpage. ```solidity /** * Deployment function for new Clanker token launches. Callable by anyone. **/ function deployToken(DeploymentConfig memory deploymentConfig) external payable returns (address tokenAddress); /** * Configuration settings for token creation. Explanation of fields defined below. */ struct DeploymentConfig { TokenConfig tokenConfig; PoolConfig poolConfig; LockerConfig lockerConfig; MevModuleConfig mevModuleConfig; ExtensionConfig[] extensionConfigs; } struct TokenConfig { address tokenAdmin; string name; string symbol; bytes32 salt; string image; string metadata; string context; uint256 originatingChainId; } struct PoolConfig { address hook; address pairedToken; int24 tickIfToken0IsClanker; int24 tickSpacing; bytes poolData; } struct LockerConfig { address locker; // reward info address[] rewardAdmins; address[] rewardRecipients; uint16[] rewardBps; // liquidity placement info int24[] tickLower; int24[] tickUpper; uint16[] positionBps; bytes lockerData; } struct ExtensionConfig { address extension; uint256 msgValue; uint16 extensionBps; bytes extensionData; } struct MevModuleConfig { address mevModule; bytes mevModuleData; } ``` ### Token Config The following parameters are required for token creation: * **`tokenAdmin`**: The address that will manage the token's admin rights. * **`name`**: Token name. * **`symbol`**: Token symbol. * **`salt`**: Address salt value to allow for token address customization. * **`image`**: Token image. The tokenAdmin can update this. * **`metadata`**: Token metadata. The tokenAdmin can update this. * **`context`**: Additional token context containing information about who deployed the token. This is immutable. * **`originatingChainId`**: Chain ID where the token's supply is deployed. Supply is set to 100 billion tokens with 18 decimals. ### Pool Config The following parameters are required for pool creation: * **`hook`**: The address of the hook to use for the pool. Must be an allowlisted hook on the factory. * **`pairedToken`**: The address of the paired token. * **`tickIfToken0IsClanker`**: The tick value to start the pool at as if the deployed token is the `token0`. The deployment configuration interface always assumes that the deployed token is `token0`, and if this is untrue the implementation handles the conversion. * **`tickSpacing`**: The tick spacing to use for the pool. * **`poolData`**: Additional pool data, specific to the hook being used. ### Locker Config The lockers in v4 manage the placement of liquidity positions and the distribution of LP fees to the reward recipients. Fees are collected by locker contracts and are routed to the ClankerFeeLocker contract for users to claim. The following parameters are required for the liquidity locker creation: * **`locker`**: The address of the locker to use for the pool. Must be an allowlisted locker on the factory for the target pool. * **`rewardAdmins[]`**: The addresses of the admins who will be able to modify the reward recipients that match their index. * **`rewardRecipients[]`**: The addresses of the recipients who will be able to receive the portion of the LP fees that match their index. * **`rewardBps[]`**: The portion of the LP fees to be distributed to the recipients in basis points. Must sum to 10,000. * **`tickLower[]`**: The lower tick value to use for a liquidity position. * **`tickUpper[]`**: The upper tick value to use for a liquidity position. * **`positionBps[]`**: The portion of the pool's allocated token supply to be used for the liquidity position in basis points. Must sum to 10,000. * **`lockerData`**: Additional data to be passed to the locker, specific to the locker being used. See the [ClankerLpLockerFeeConversion](/documentation/references/core-contracts/v4/fee-management-contracts/clankerlplockerfeeconversion) documentation for how to fill out this variable. Rewards are a tuple of `rewardAdmin`, `rewardRecipient`, and `rewardBps`. The `rewardRecipient` receives the trading fees in the ClankerFeeLocker and can be updated by the `rewardAdmin`. The `rewardBps` is the portion of fees, out of 10,000, for the recipient to receive. The total number of reward basis points must equal 10,000. The reward BPS distribution is not changeable post-token deployment and a maximum of 7 reward recipients are allowed per deployment. Liquidity positions are a tuple of `tickLower`, `tickUpper`, and `positionBps`. The `tickLower` is the lower tick value for a position and the `tickUpper` is the higher tick, both are assumed to be as if token0 is the deployed token, similar to the pool's starting tick. The `positionBps` array is used to determine how to split up the pool's token allocation among positions. The tick ranges all must be equal to or higher than the `tickIfToken0IsClanker` value, but otherwise are only constrained by normal tick rules. The positions do not have to be contiguous and can overlap. ### Extension Config Extensions are contracts that can be used to add new functionality to the token deployment process. The following parameters are required for the extension creation: * **`extension`**: The address of the extension to use for the pool. Must be an allowlisted extension on the factory. * **`msgValue`**: The msg.value to send to the extension. * **`extensionBps`**: The amount of the token supply to be allocated to the extension in basis points. * **`extensionData`**: Additional data to be passed to the extension, specific to the extension being used. If the `msg.value` passed into the `deployToken()` function does not match the sum of the `msgValue` of the extensions, the deployment will revert. The maximum amount of the token supply allocatable to extensions is 90%. ### MEV Module Config The following parameters are required for the MEV module creation: * **`mevModule`**: The address of the MEV module to use for the pool. Must be an allowlisted MEV module on the factory. * **`mevModuleData`**: Additional data to be passed to the MEV module, specific to the MEV module being used. # Fee Management Contracts The **ClankerFeeLocker** and **IClankerLpLocker** contracts are used to manage the fees generated from the tokens. The **IClankerLpLocker** is on its second implementation, **ClankerLpLockerFeeConversion,** which is used to manage the LP fees for a token's deployment liquidity. # ClankerFeeLocker Documentation of Clanker's ClankerFeeLocker The **ClankerFeeLocker** contract is the user-facing contract for managing the fees generated from the tokens. Anyone is able to trigger the `claim()` function to transfer fees from the fee locker to the user's address. This design decision was made because many users point their fees to multisigs or other contracts which cannot trigger the `claim()` function themselves. {% hint style="info" %} The fees from paired tokens are grouped together for a single fee recipient. Meaning, if a user creates more than a single token paired with WETH, the WETH fees for all of the created tokens are claimable with a single call. There is no onchain way to see the breakdown of WETH per token. For that, we recommend inspecting the [`IClankerLpLocker.ClaimedRewards`](https://github.com/clanker-devco/v4-contracts/blob/530851868af87cbda2d4163745fb7154168b1225/src/interfaces/IClankerLPLocker.sol#L32) event on Dune. This event is emitted each time the rewards are claimed from a token's LP positions and moved into the fee locker. The reward arrays contain the breakdown of token rewards per reward recipient. {% endhint %} User Facing Functions: ```solidity // callable by anyone, transfers the available fees to the recipient // // note: the 'token' parameter is the token that is being claimed, not the token // that is generating the fees. In other places in Clanker, the 'token' parameter // is the token that is generating the fees. function claim(address feeOwner, address token) external; // view function to return the amount of `token` fees available to claim for a `feeOwner` function availableFees(address feeOwner, address token) external view returns (uint256); ``` # ClankerLpLockerMultiple \[Deprecated] Documentation of Clanker's ClankerLpLockerMultiple {% hint style="info" %} Note: This locker has been deprecated in favor of [ClankerLpLockerFeeConversion](/documentation/references/core-contracts/v4/fee-management-contracts/clankerlplockerfeeconversion)\ \ All tokens deployed with the ClankerLpLockerMultiple will continue to function but no new deployments will be allowed. {% endhint %} The **ClankerLpLockerMultiple** contract is used to manage who is receiving the LP fees for a token's deployment liquidity. The LP is split between the list of reward recipients specified in the `LockerConfig` struct, with the split being specified in the `rewardBps` array. The `rewardAdmin` is able to update the `rewardRecipient` for their array position (and also update themselves). The `rewardBps` array is not changeable post deployment. See the [Deployment Config](/documentation/references/core-contracts/v4/deployment-config)'s `LockerConfig` section for how to configure Clanker lockers. User Facing Functions: ```solidity // callable by the index's recipient admin, updates the reward admin for the reward index // // note: the 'token' parameter is the deployed token's address function updateRewardAdmin(address token, uint256 rewardIndex, address newAdmin) external; // callable by the index's recipient admin, updates the reward recipient for the reward index function updateRewardRecipient(address token, uint256 rewardIndex, address newRecipient) external; ``` # ClankerLpLockerFeeConversion Documentation of Clanker's ClankerLpLockerFeeConvsersion The **ClankerLpLockerFeeConversion** contract is used to manage who is receiving the LP fees for a token's deployment liquidity and in which token a recipient's fees accumulate in. The LP is split between the list of reward recipients specified in the `LockerConfig` struct, with the split being specified in the `rewardBps` array. Fee recipients can choose to accumulate their fees in: the deployed token, the paired token, or, both tokens. The `rewardAdmin` is able to update the `rewardRecipient` and the `feePreference` for their array position (and also update themselves). The `rewardBps` array is not changeable post deployment. See the [Deployment Config](/documentation/references/core-contracts/v4/deployment-config)'s `IClanker.LockerConfig` section for how to configure Clanker lockers. The `feePreferences` are set through the `LockerConfig.lockerdata` field, with the following struct expected as input: ```solidity // IClankerLpLockerFeeConversion.sol enum FeeIn { Both, Paired, Clanker } struct LpFeeConversionInfo { FeeIn[] feePreference; // needs to be same length as IClanker.LockerConfig's other reward arrays } ``` Solidity snippet of example encoding: 
// example of how to encode:
IClanker.DeploymentConfig memory exampleConfig;

IClankerLpLockerFeeConversion.FeeIn[] memory feeIn =
    new IClankerLpLockerFeeConversion.FeeIn[](3);
feeIn[0] = IClankerLpLockerFeeConversion.FeeIn.Paired;
feeIn[1] = IClankerLpLockerFeeConversion.FeeIn.Clanker;
feeIn[2] = IClankerLpLockerFeeConversion.FeeIn.Both;

exampleConfig.lockerConfig.lockerData =
    abi.encode(IClankerLpLockerFeeConversion.LpFeeConversionInfo({feePreference: feeIn}));
User Facing Functions: ```solidity // callable by the index's recipient admin, updates the reward admin for the reward index // // note: the 'token' parameter is the deployed token's address function updateRewardAdmin(address token, uint256 rewardIndex, address newAdmin) external; // callable by the index's recipient admin, updates the reward recipient for the reward index function updateRewardRecipient(address token, uint256 rewardIndex, address newRecipient) external; // callable by the index's recipient admin, updates the fee preference for the reward index function updateFeePreference(address token, uint256 rewardIndex, FeeIn newFeePreference) external; ``` # Extensions Documentation for Clanker's v4.0.0 Extensions ## Extension Contracts Extensions are contracts that can be used to add new functionality to the token deployment process. During deployment they are able to request a portion of the token's supply, an amount of ETH via msg.value, and can take actions on the token's deployed pool. Examples of actions that extension code can implement include: adding unlocked liquidity to the pool, distributing tokens, and making swaps on the deployed pool. The portion of the token supply requested by the extensions is reduced from the amount that would otherwise be used in the pool's initial liquidity positions. Up to 90% of the token supply can be allocated to extensions. The total amount of ETH requested by the extensions must sum to the msg.value passed into the deployToken function. To deploy a token with an extension, you would add an ExtensionConfig struct to the DeploymentConfig's list of extensions. The ExtensionConfig struct has the following shape: ```solidity struct ExtensionConfig { address extension; // address of the deployed extension, must be allowlisted on the factory uint256 msgValue; // the `msg.value` to send to the extension uint16 extensionBps; // the portion of the token supply to be allocated to the extension bytes extensionData; // additional data to be passed to the extension, specific to the extension being used, normally a struct } ``` Extensions must be allowlisted by the Clanker team to be used on the factory and we do reserve the right to remove extensions. ### # ClankerVault Documentation of Clanker v4.0.0's Vault Extension The **ClankerVault** extension allows a deployer to vault a portion of the token supply for a single admin. The tokens can be configured with an initial `lockupDuration` and an optional `vestingDuration`. The tokens will be inaccessible until the `lockupDuration` passes and then will start a linear vest after the `lockupDuration` ends. The vault has a minimum lockup duration of 7 days and has no required vesting duration. For example, if a deployer wants to vault 10% of the token supply for 30 days and have all tokens available 60 days post-unlock, they would set the lockupDuration to 30 days and the vestingDuration to 30 days. At 45 days post-deployment, half of the vaulted token supply would be accessible. Anyone is able to trigger the `claim()` function to transfer funds from the vault to the admin's address. This means it's okay if the admin is a contract. The **ClankerVault**'s extension data is in the form of: ```solidity struct VaultExtensionData { address admin; // the address to receive the tokens, can update itself uint256 lockupDuration; // the duration of the lockup period uint256 vestingDuration; // the duration of the vesting period } ``` In this version, only a single vault extension is allowed per deployment. **User Facing Functions:** ```solidity // callable by anyone, transfers the available tokens to the `admin` function claim(address token) external; // callable by the token's admin, updates the vault admin to a new address function editAllocationAdmin(address token, address newAdmin) external; // view function to return the amount of `token` available to claim function amountAvailableToClaim(address token) external view returns (uint256); ``` # ClankerAirdrop Documentation of Clanker v4.0.0's Airdrop Extension The **ClankerAirdrop** extension will allow a deployer to airdrop a portion of the token supply via a merkle root. To claim tokens, the recipient must have a leaf in the merkle root. The tokens can be configured with an initial `lockupDuration` and a follow-up `vestingDuration`. The tokens will be inaccessible until the `lockupDuration` passes and then will start a linear vest after the `lockupDuration` ends. The airdrop has a minimum lockup duration of 1 day and has no required vesting duration. Anyone is able to trigger the `claim()` function to transfer funds from the airdrop to the recipient's address. For example, if a deployer wants to lock the airdropped tokens for 30 days and have all tokens available 60 days post-unlock, they would set the `lockupDuration` to 30 days and the `vestingDuration` to 30 days. At 45 days post-deployment, half of the airdropped token supply would be accessible. The **ClankerAirdrop**'s extension data is in the form of: ```solidity struct AirdropExtensionData { bytes32 merkleRoot; // the merkle root of the airdrop uint256 lockupDuration; // the duration of the lockup period uint256 vestingDuration; // the duration of the vesting period } ``` The airdrop expects leaves to be in abi-encoded format of: `(address recipient, uint256 amount)`. The **OpenZeppelin** MerkleProof library is used to verify the proof against the merkle root, with a JavaScript package available [here](https://github.com/OpenZeppelin/merkle-tree). Note: this extension does not verify on-chain that the merkle root's leaves add up to the total supply of the token. It is the responsibility of the deployer to ensure that the merkle root is valid. If the recipient is granted tokens in multiple leaves, the amount of tokens they are able to claim will be the maximum of the granted amounts. **User Facing Functions:** ```solidity // callable by anyone, transfers the available tokens to the recipient function claim(address token, address recipient, uint256 allocatedAmount, bytes32[] calldata proof) external; // helper function to surface the amount available to claim for a user, // assumes that there exists a proof for the allocated amount function amountAvailableToClaim(address token, address recipient, uint256 allocatedAmount) external view returns (uint256); ``` # ClankerAirdropV2 The **ClankerAirdropV2** extension allows a deployer to airdrop a portion of the token supply via a merkle root. ClankerAirdropV2 is an upgrade of ClankerAirdrop with increased admin controls. ### How to Set Up At the time of token deployment, the deployer needs to supply the following: 1. How much supply to allocate to the airdrop (max 90%) 2. How long to lock up the airdrop (minimum 1 day) 3. How long to vest the airdrop (can be zero) 4. The merkle root specifying the recipients and their token amounts (can be zero and set later) The **ClankerAirdrop** extension data is in the form of: ```solidity struct AirdropExtensionData { address admin; // controller of the token's airdrop admin functions bytes32 merkleRoot; // the merkle root of the airdrop uint256 lockupDuration; // the duration of the lockup period uint256 vestingDuration; // the duration of the vesting period } ``` #### Merkle Root Format The airdrop expects leaves to be in ABI-encoded format: `(address recipient, uint256 amount)`. The **OpenZeppelin** MerkleProof library is used to verify the proof against the merkle root, with a JavaScript package available [here](https://github.com/OpenZeppelin/merkle-tree). > **Important:** This extension does not verify on-chain that the merkle root's leaves add up to the total supply of the token. It is the responsibility of the deployer to ensure that the merkle root is valid. If a recipient is granted tokens in multiple leaves, the amount of tokens they are able to claim will be the maximum of the granted amounts. ### Admin Capabilities Admins are able to perform two main actions: 1. **Recover unclaimed tokens** two weeks after an airdrop's lockup + vesting time period has passed. If an airdrop has a 7-day lockup and a 7-day vest, the admin can recover tokens 28 days post-launch (7-day lockup + 7-day vest + 14-day protected user claim window = 28 days). 2. **Change the merkle root** for their token. Admins are able to do this: * Anytime if the root was initially set to zero and is still zero * 1 day after the lockup period has ended and no users have claimed their tokens #### Admin-Facing Functions Only a token's admin can call the following functions: ```solidity // admins can claim the remaining balance after the claim expiration // interval has been reached function adminClaim(address token, address recipient) external; // update the merkle root of the airdrop by admin if the merkle root is // zero or if the claim overwrite interval has passed without a claim function updateMerkleRoot(address token, bytes32 newMerkleRoot) external; // update the admin of the airdrop function updateAdmin(address token, address newAdmin) external; ``` ### How to Claim To claim tokens, the recipient must have a leaf in the merkle root. Anyone is able to trigger the `claim()` function to transfer funds from the airdrop to the recipient's address. Claiming can begin after a token's lockup period has ended, and the amount available to claim is a function of time over an optional vesting period. For example, if a deployer wants to lock the airdropped tokens for 30 days and have all tokens available 60 days post-unlock, they would set the `lockupDuration` to 30 days and the `vestingDuration` to 30 days. At 45 days post-deployment, half of the airdropped token supply would be accessible. #### User-Facing Functions ```solidity // callable by anyone, transfers the available tokens to the recipient function claim(address token, address recipient, uint256 allocatedAmount, bytes32[] calldata proof) external; // helper function to surface the amount available to claim for a user, // assumes that there exists a proof for the allocated amount function amountAvailableToClaim(address token, address recipient, uint256 allocatedAmount) external view returns (uint256); ``` # ClankerUniv4EthDevBuy Documentation of Clanker v4.0.0's DevBuy The **ClankerUniv4EthDevBuy** extension is used to perform an initial swap of the token using passed-in ETH. If the paired token is not WETH, the extension will swap the passed-in ETH for the paired token before swapping the paired token for the deployed token. For non-WETH pairs, the paired token must have a WETH<>PairedToken Uniswap v4 pool. In this version, multiple devBuy extensions are allowed per deployment. The **ClankerUniv4EthDevBuy**'s extension data is in the form of: ```solidity struct Univ4EthDevBuyExtensionData { // pool key to swap from W/ETH to paired token if the paired token is not WETH. // Can be set to fake data if the paired token is WETH but needs to be the // correct byte length PoolKey pairedTokenPoolKey; // minimum amount of token to receive from the W/ETH -> paired token swap uint128 pairedTokenAmountOutMinimum; // recipient of the tokens, should be specified address recipient; } ``` The `pairedTokenPoolKey` parameter is the full `PoolKey` and not the `PoolID`. For example, if the paired token was USDC, the following `PoolKey` on Base could work: ```solidity // PoolKey for USDC<>ETH on Base Mainnet // PoolID: 0x96d4b53a38337a5733179751781178a2613306063c511b78cd02684739288c0a poolKey: { currency0: '0x0000000000000000000000000000000000000000', currency1: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913', fee: 500, tickSpacing: 10, hooks: '0x0000000000000000000000000000000000000000', } ``` There are no user-facing functions for the **ClankerUniv4EthDevBuy** extension.
# ClankerPresaleEthToCreator Clanker's **ClankerPresaleEthToCreator** extension is a special type of presale where the raised funds go to the creator of the presale instead of being deposited into the liquidity pool. ### Features * **Price Discovery**: Creators can set a min and a max ETH goal to raise. The starting price of the token goes up as more people buy into the presale. * **Optional Allowlists**: Creators can opt to manage a merkle-root based allowlist with per-address overrides. See [**ClankerPresaleAllowlist**](/documentation/references/core-contracts/v4/extensions/clankerpresaleallowlist) for more details. * **Presale Tokens Lockup and Vesting**: Presale tokens must be locked up for a minimum of 7 days post token creation, with optional vesting on top. This is to help ensure smooth post-launch market dynamics. ### Fees The Clanker team takes a 0% cut on raised funds for successful presales. All ETH raised goes directly to the creator. There is no fee for buyers on entering/exiting positions. {% hint style="info" %} This presale is not permissionless. If your team is interested in using this presale, please reach out to the Clanker team. {% endhint %} ### Creating a Presale Presale creators need to provide the following to start a presale: * **`presaleDuration`**: Maximum amount of time to run the presale for. * **`maxEthGoal`**: Maximum amount of ETH to raise. If this number is hit, the presale stops accepting new bids and the token can be launched immediately. * **`minEthGoal`**: Minimum ETH goal to hit for a presale to be considered successful. The token can be launched if this minimum is hit after the presale duration has passed or if the presale owner requests it. * **`deploymentConfig`**: The token to deploy once a presale hits a success condition. This is a normal Clanker v4 deployment config with all features except the DevBuy fully accessible. The presale contract needs to be the last specified extension. * **`presaleOwner`**: Address used to claim raised ETH and to manage the optional allowlist. * **`lockupDuration`**: How long to lock up presale tokens for. Minimum 7-day lockup is required. * **`vestingDuration`** (optional): How long to vest the presale tokens for. The vesting is linear and starts after the lockup period has ended. For example, if this is set to 10 days and the lockup duration is set to 10 days, on day 15 half of the supply would be claimable and on day 20 the token becomes fully claimable. * **`allowlist`** (optional): Address of the allowlist module to use to manage the presale. * **`allowlistInitializationData`** (optional): ABI-encoded data to pass to the allowlist module if it exists. Each created presale receives a `presaleId`. ```solidity function startPresale( IClanker.DeploymentConfig memory deploymentConfig, uint256 minEthGoal, uint256 maxEthGoal, uint256 presaleDuration, address presaleOwner, uint256 lockupDuration, uint256 vestingDuration, address allowlist, bytes calldata allowlistInitializationData ) external onlyAdmin returns (uint256 presaleId); ``` ### Participating in the Presale #### Buying into a Presale Buying into a presale is tax-free and is done with the `buyIntoPresale()` function. The `msg.value` sent is used to buy into the presale. If the amount of ETH sent exceeds a presale's maximum, the sender is refunded the excess. ```solidity function buyIntoPresale(uint256 presaleId) external payable; ``` If the presale is using an allowlist which requires buyers to prove that they're approved to buy in with a certain amount of ETH, they can use the `buyIntoPresaleWithProof()` function which forwards the proof data to the allowlist module. ```solidity function buyIntoPresaleWithProof(uint256 presaleId, bytes calldata proof) external payable; ``` Presale owners are able to actively change the amount of ETH a user can use to buy into the presale with. Owners are not able to revoke ETH for people who have already bought in. #### Withdrawing from a Presale Users are able to withdraw their funds from a presale if the presale has failed or if the presale has not yet reached the maximum ETH goal. ```solidity function withdrawFromPresale( uint256 presaleId, uint256 amount, address recipient // address to receive the refunded ETH, can be the same as the msg.sender ) external; ``` ### Ending a Presale Presales can end in either token deployment (success) or with all buyers being able to withdraw their funds tax-free (failed). Presales can be ended by calling the `endPresale()` function: ```solidity function endPresale(uint256 presaleId, bytes32 salt) external; ``` Presale tokens can be deployed in three scenarios: 1. The `maxEthGoal` is hit at any point. 2. The `minEthGoal` was hit and the `presaleDuration` has passed. 3. The `minEthGoal` is hit and the presale owner requests it to end early. If in scenarios (1) or (2), the presale owner has a single day where they are the only entity who can deploy the token. Once this day buffer passes, anyone is able to select a salt and end the presale. If three days total have passed without anyone ending the presale, the presale is considered failed and buyers can recover their funds through the `withdrawFromPresale()` function. ### Claiming Tokens #### Claiming Tokens Buyers of successful presales can claim their tokens through the `claimTokens()` function. The tokens will be available as the lockup and vesting durations pass. ```solidity function claimTokens(uint256 presaleId) external; ``` #### Claiming ETH The `presaleOwner` is able to claim the raised ETH funds immediately after a presale has successfully deployed a token. ```solidity // only callable by the presaleOwner function claimEth(uint256 presaleId, address recipient) external; ``` # ClankerPresaleAllowlist The **ClankerPresaleAllowlist** pairs with the **ClankerPresaleEthToCreator** to give presale creators the ability to manage who can buy into a presale. ### Features * **Merkle Root**: Presale owners can set a merkle root whose leaves specify buyers and their allowed ETH amounts. This merkle root can be updated at any point during a presale's lifetime. * **Per-address override**: Presale owners can override the merkle root on a per-address basis if desired. * **Blanket disable**: Presale owners can disable the allowlist at any point if they'd like to allow anyone to buy into the presale. The allowlist can also be re-enabled. ### Initializing the Presale To use this allowlist, at the point of presale creation, the presale creator needs to set the `startPresale()` function's `allowlist` argument to the address of the ClankerPresaleAllowlist. Presale creators can specify a merkle root at the time of creation. If it is not specified, no one will be able to buy into the presale until the presale owner takes a management action to allow buyers. ```solidity // format of initialization data struct AllowlistInitializationData { bytes32 merkleRoot; } // method to call on ClankerPresaleEthToCreator function startPresale( ... address allowlist, // set to the ClankerPresaleAllowlist address bytes calldata allowlistInitializationData // optional, abi encoded AllowlistInitializationData ) external onlyAdmin returns (uint256 presaleId); ``` The OpenZeppelin MerkleProof Solidity library is used to verify the proof against the merkle root, with a JavaScript package available [here](https://www.npmjs.com/package/@openzeppelin/merkle-tree). The leaves are expected to be in the format of `(address buyer, uint256 allowedEthAmount)`. **Note**: This extension does not verify on-chain that the merkle root's leaves add up to the min or max ETH amount for the presale. ### Managing the Presale Presale owners have three function they can call to manage presale buyers. ```solidity // presale owners can update the merkle root at any point function setMerkleRoot(uint256 presaleId, bytes32 merkleRoot) external; // presale owners can set overrides at any point function setAddressOverride( uint256 presaleId, address buyer, uint256 allowedAmount ) external; // presale owners can blanket enable/disable the allowlist at any point function setAllowlistEnabled(uint256 presaleId, bool enabled) external; ``` # ClankerHook The **ClankerHook** contract is the abstract base contract that our other hooks inherit from. The **ClankerHook** contract itself facilitates: * Automatic fee collection of the initial LP position's fees. Fees are collected by the **IClankerLpLocker** contracts and are routed to the [**ClankerFeeLocker**](/documentation/references/core-contracts/v4/fee-management-contracts/clankerfeelocker) contract for users to claim. * Collection of a DEX-level protocol fee, separate from the creator LP fees, always in the paired token. * Triggering of a pool's `MevModule` until it is disabled or expired. Mev Modules can run for up to 2 mintues max. Note: both of the fee collection mechanisms lag by a swap, so the fees collected in a swap are the fees from the previous swap. This is because a swap's fees are only sent into the `PoolManager` contract after the swap has completed. v4.0.0's initial release introduces two different fee hook types: `ClankerHookStaticFee` and `ClankerHookDynamicFee`. For both hooks, the protocol's DEX fee is always taken in the paired token and will always be 20% of the active LP fee. The maximum LP fee is 30% of a swap. It is NOT recommended to set the fee this high if it is desired for the token to work with every router; fees that high should be reserved for esoteric use cases only. Clanker's hooks allow for deployment of pools not created by the factory via an 'open' version of the initialization pathway. Pools created via this method do not have automatic LP fee claiming or mev module operations. Note: this function will revert if called with the `clanker` address set to `WETH`. We only collect the protocol's fee on the paired token and would prefer it to be `WETH` when possible. ```solidity // callable by anyone function initializePoolOpen( address clanker, address pairedToken, int24 tickIfToken0IsClanker, int24 tickSpacing, bytes calldata poolData ) public returns (PoolKey memory) ``` # ClankerHookStaticFee Documentation for Clanker's Static Fee Hook The **ClankerHookStaticFee** hook inherits from the **ClankerHook** and is used to set a static fee for both the deployed token and the paired token. The fees are able to be different from each other and have a max of 30%. The fee unit is in Uniswap BPS, where `1` = 1/100th of a basis point. A fee of 1% is represented by `10_000,` and a fee of 30% by `300_000`. The expected `PoolConfig.poolData` is in the form of: ```solidity struct PoolStaticConfigVars { // the fee taken on the deployed token when it's the input token uint24 clankerFee; // the fee taken on the paired token when it's the input token uint24 pairedFee; } ``` These fees are not changeable post deployment. # ClankerHookDynamicFee Documentation for Clanker's Dynamic Fee Hook The **ClankerHookDynamicFee** hook inherits from the **ClankerHook** and is used to set a dynamic fee for both the deployed token and the paired token. The math governing the dynamic fee took inspiration from Meteora's Dynamic Liquidity Market Maker's [fee model](https://docs.meteora.ag/product-overview/meteora-liquidity-pools/dlmm-overview/dynamic-fees). The goal of the dynamic fee is to charge higher fees when there is volatility is present on the pool. We measure the volatility by simulating the price impact of a swap (measured in the difference between the `beforeTick` and `afterTick`) and applying a fee based on the magnitude. The resulting fee we apply is a mixture of the tick difference, recent swaps on the pool, and safeguards to prevent bot manipulation. ### User Controlled Configuration Variables The following configuration is used to control the range and sensitivity of the dynamic fees. The fee unit is in Uniswap BPS, where `1` = 1/100th of a basis point. A fee of 1% is represented by `10_000,` and a fee of 30% by `300_000`. ```solidity struct PoolDynamicConfigVars { uint24 baseFee; // the minimum LP fee to be taken on a swap uint24 maxLpFee; // the maximum LP fee to be taken on a swap uint256 referenceTickFilterPeriod; uint256 resetPeriod; int24 resetTickFilter; uint256 feeControlNumerator; // the denominator is set to 10_000_000_000 uint24 decayFilterBps; } ``` Users are able to tune the dynamic fees as they choose, but we do provide a set of recommended configuration values on deployments through our website and API. We also have a spreadsheet that replicates this process and can provide it upon request. The following configuration is our current recommendation for tokens starting at a 10ETH marketcap: ```solidity IClankerHookDynamicFee.PoolDynamicConfigVars({ baseFee: 5000,// 0.5% minimum fee maxLpFee: 50000, // 5% max fee referenceTickFilterPeriod: 30 seconds, resetPeriod: 120 seconds, resetTickFilter: 200, // 2% price movement feeControlNumerator: 500000000, // Constant for scaling variable fee component decayFilterBps: 7500 // 75% decay after filter period }) ``` ### Dynamic Fee Calculation The dynamic fee is calculated by the following equation: 
uint24 dynamicFee = 
  MIN(
      (baseFee + (feeControlNumerator * (volatilityAccumulator ** 2)) / FEE_CONTROL_DENOMINATOR),
      maxLpFee
  );
The `volatilityAccumulator` is a value that is updated on each swap and is calculated by the process described below. **Volatility Accumulator** The volatility accumulator is our way of measuring the amount of volatility on the pool. It is a value that is updated on each swap and is affected by recent swaps on the pool under different time frames. We use two lagging tick values, two time periods, and a decayed version of a previous volatility accumulator to calculate a swap's volatility accumulator. The equation for the volatility accumulator is: ```solidity volatilityAccumulator = |afterTick - referenceTick| + prevVR; ``` The values of `referenceTick` and `prevVR` are updated based on snapshots of pool activity captured by the lagging ticks and time periods. The two lagging tick values are: * `referenceTick`: When the `referenceTickFilterPeriod` has passed or if a `resetPeriod` has been triggered with a failing reset condition, this tick value is updated to the `beforeTick` of a swap. This tick value is kept the same until hitting one of these update conditions. * `resetTick`: This tick is updated to the `beforeTick` of a swap when the `referenceTick` is updated, and is additionally updated when the `resetPeriod` has passed and a swap's `beforeTick` is at least `resetTickFilter` ticks away from the `resetTick` (a passing reset condition). The two time periods and their uses are: * `referenceTickFilterPeriod`: If the previous swap was less than `referenceTickFilterPeriod` seconds away, we use the recorded `referenceTick` for the dynamic fee calculation instead of the `beforeTick` of the current swap. This prevents bots from avoiding the dynamic fee by cutting their swap into smaller swaps. * `resetPeriod`: If a `referenceTick` has not been updated for over `resetPeriod` seconds, we want to ensure that there is true volatility happening on the pool. The goal is to prevent bots from keeping the pool's fee high by sending in micro swaps to avoid updating the `referenceTick`. If the `resetPeriod` has passed and the `beforeTick`'s difference from the recorded `resetTick` is smaller than the `resetTickFilter` (a failing reset condition), we update both the `referenceTick` and `resetTick` to the `beforeTick` of the current swap to clear out the stored volatility. If the `resetPeriod` has passed and the `beforeTick`'s difference from the recorded `resetTick` is larger than the `resetTickFilter` (a passing reset condition), we only update the `resetTick` to the `beforeTick` of the current swap and keep the `referenceTick` the same. Additionally, the two time periods are used to determine the `prevVR` value. The `prevVR` is used to smooth volatility over a period of time and is set to a value when the `referenceTickFilterPeriod` has passed but the `resetPeriod` has not. The value is set to the last swap's volatility accumulator multiplied by the `decayFilterBps` value. The `prevVR` is set to zero when the `resetPeriod` passes with a failed condition or if a `resetPeriod` amount of time has passed without a swap. The same `prevVR` is used as long as the `referenceTick` has not been updated. Note: there is a slight drift between the simulated `afterTick` and the resulting `afterTick`. This is because the applied fee for the simulated swap is an estimate either reusing the previous swap fee or just the `prevVR` under some reset conditions. We deemed that this drift is acceptable for our intended outcomes. # ClankerHookV2 The [**ClankerHookV2**](https://github.com/clanker-devco/v4.0-contracts/blob/main/src/hooks/ClankerHookV2.sol) contract is the abstract base class that the V2 hooks inherit from. It's a slight upgrade of **ClankerHook** with the following changes: * The maximum LP fee that users can specify is 10% instead of 30%. * Mev Modules are able to set the applied LP fee for a swap, with a maximum fee of 80%. If the Mev Module is trying to set a fee that is lower than what the pool would normally set the fee to, the module's change is ignored. The modules can still only run for up to 2 minutes. * At the time of token deployment, an external [**Pool Extension**](/documentation/references/core-contracts/v4/clankerhookv2/pool-extensions) contract can be specified to be called during the Hook's `afterSwap` flow. The purpose of the extensions is to enable developers to perform per-swap fee automations such as: staking, buybacks of external tokens, and performance-based fee unlock thresholds. Only tokens deployed via the factory can add pool extensions. The other major change is the formatting of the deployment config's `PoolConfig.poolData` and swap `hookData` encoding. The previous version of **ClankerHook** did not expect this data to be in a specific shape, but **ClankerHookV2** expects the following format: ```solidity struct PoolInitializationData { address extension; // address of the pool extension bytes extensionData; // data to pass to the pool extension bytes feeData; // data to use to configure the pool's fees (specific to the hook) } ``` It is now expected that swap `hookData`, if present, will be encoded in the following shape: ```solidity struct PoolSwapData { bytes mevModuleSwapData; // data to pass to the mev module bytes poolExtensionSwapData; // data to pass the the pool extension } ``` # Pool Extensions Pool Extensions are a **ClankerHookV2** feature that enables users to specify custom logic to run in the hook's `afterSwap()` flow. The custom logic must reside in an external contract that implements the [`IClankerHookV2PoolExtension`](https://github.com/clanker-devco/v4-contracts/blob/main/src/hooks/interfaces/IClankerHookV2PoolExtension.sol) interface. The Clanker Team must approve pool extensions before they are used, feel free to reach out to us during the design process so we can give feedback. We expect most Pool Extensions to perform actions with the pool's generated fees, but the end logic is up to the token's deployer. ### Examples of Pool Extension Capabilities Pool Extensions can perform various actions, including: * **Token swapping**: Use generated fees from one of the token's specified reward recipients to purchase a different token. See our [`UniV3SwapExtension`](https://github.com/clanker-devco/v4-contracts/blob/main/src/hooks/pool-extension-examples/UniV3SwapExtension.sol) or [`UniV4SwapExtension`](https://github.com/clanker-devco/v4-contracts/blob/main/src/hooks/pool-extension-examples/UniV4SwapExtension.sol) as examples of using generated WETH fees to swap for a different token. * **Fee distribution**: Split the generated fees between people who stake a token on the extension contract or between people who have swapped on the pool. * **Conditional fee unlocking**: Unlock the generated fees only if the pool reaches and sustains a certain market cap. These are just examples, and we'll update this list as people develop interesting implementations. ### Security Limitations For security reasons, Pool Extensions are limited in what they can do. Pool Extensions **cannot**: * **Stop a swap**: Pool Extensions cannot prevent a swap from occurring. If the Pool Extension reverts, the swap will complete normally. This is because we do not want pool extensions to break and prevent users from exiting their positions. * **Modify a swap**: Pool Extensions cannot modify the swap's LP fee or balance deltas. Additionally, pool extensions run after a swap completes, meaning you cannot use a pool extension to front-run swaps. ### Pool Extension Partial Swap Coverage Not all swaps made on a pool will trigger the pool extension. There are two types of swaps which will not cause the pool extensions to be called out to: 1. Swaps made during the token's factory level extensions. For example, the swap made during the `ClankerUniv4EthDevBuy` logic will not trigger the pool extension. This is due to the pool extenion's second initialization call, `initializePostLockerSetup()`, occurring after a token's extensions are called. 2. Swaps made during the hook's fee conversion process. If a LP fee needs to be converted by the [ClankerLpLockerFeeConversion](/documentation/references/core-contracts/v4/fee-management-contracts/clankerlplockerfeeconversion) contract, the fee conversion swap will not trigger the pool extension. This ensures that a pool extension is only called once per user-level swap. ### Initialization Pool Extensions must be specified during a token's deployment and cannot be modified afterward. The address of the Pool Extension and initialization data can be set on the [`IClankerHookV2.PoolInitializationData`](https://github.com/clanker-devco/v4-contracts/blob/main/src/hooks/interfaces/IClankerHookV2.sol) struct, as shown below: ```solidity struct PoolInitializationData { address extension; // address of the pool extension bytes extensionData; // initialization data to pass to the pool extension bytes feeData; // data used to configure the pool's fees (specific to the static/dynamic fee logic) } ``` #### Example Encoding Here's an example of encoding on the higher-level token deployment struct: ```solidity // token deployment struct passed into deployToken() IClanker.DeploymentConfig memory deploymentConfig; // fill out to specify a pool extension deploymentConfig.poolConfig.poolData = abi.encode( IClankerHookV2.PoolInitializationData({ extension: address(univ3SwapBackExample), // pool extension's address extensionData: abi.encode(""), // pool extension's custom initialization data // fee-specific info feeData: ... }) ); ``` #### Initialization Functions Two initialization functions are triggered during a Pool Extension's setup: one called during the pool's initialization function and one during the later Mev module's initialization step. The first call receives the `extensionData` from above, and the second receives the `IClankerLpLocker` address, which can be queried to retrieve information about the token's fee configuration. See the two initialization functions below: ```solidity interface IClankerHookV2PoolExtension { // initialize the user extension, called once by the hook per pool during pool initialization flow function initializePreLockerSetup( PoolKey calldata poolKey, bool clankerIsToken0, bytes calldata poolExtensionInitData ) external; // initialize the user extension, called once by the hook per pool after the locker is set up, // during the MEV module initialization flow function initializePostLockerSetup( PoolKey calldata poolKey, address locker, bool clankerIsToken0 ) external; } ``` ### Runtime Logic For every swap on a pool, the ClankerHookV2 implementation will attempt to run the pool's extension if one exists. Most available information about the swap is passed into the Pool Extension's `afterSwap()` implementation: ```solidity interface IClankerHookV2PoolExtension { // after a swap, the pool extension is called to perform any post-swap actions function afterSwap( PoolKey calldata poolKey, IPoolManager.SwapParams calldata swapParams, BalanceDelta delta, // positive if owed to the caller, negative if owed to the pool bool clankerIsToken0, bytes calldata poolExtensionSwapData // the extension's portion of the hookData ) external; } ``` #### Hook Data Support Optionally, a Pool Extension can operate on data passed into the `hookData` field of the PoolManager's `swap()` function. Not all swap routers support `hookData` today, so this information would most likely only be present for swaps coming through custom frontends or mini apps. The `poolExtensionSwapData` needs to be encased in the `IClankerHookV2`'s `PoolSwapData`, which accommodates both the MEV module's and pool extension's custom data: ```solidity struct PoolSwapData { bytes mevModuleSwapData; // abi-encoded MEV module swap data bytes poolExtensionSwapData; // abi-encoded pool extension swap data } ``` **Important**: It is difficult to determine the identity of the swapper. The `tx.origin` can be an account abstraction entity, and the swap's normal `msg.sender` is typically a router. We recommend using the `poolExtensionSwapData` feature to pass in a swapper's identity if needed and otherwise assuming a best-effort level of identifying swappers. ### Legal Disclaimer Please consult your lawyers before deployment. Clanker takes no responsibility for activities taking place in Pool Extensions. # ClankerHookStaticFeeV2 **ClankerHookStaticFeeV2** operates the same as **ClankerHookStaticFee** except that it inherits from **ClankerHookV2** instead of **ClankerHook**. See [**ClankerHookStaticFee**](/documentation/references/core-contracts/v4/clankerhook/clankerhookstaticfee)'s documentation for details. # ClankerHookDynamicFeeV2 **ClankerHookDynamicFeeV2** operates the same as **ClankerHookDynamicFee** except that it inherits from **ClankerHookV2** instead of **ClankerHook**. See [**ClankerHookDynamicFee**](/documentation/references/core-contracts/v4/clankerhook/clankerhookdynamicfee)'s documentation for details. # Mev Modules Clanker v4.0.0 introduces the ability to modify a pool's behavior at the time of deployment through different MEV modules. The goal of these modules is to lessen the negative impact that snipers have on users. ### Functionality MEV modules are specified on pool deployment and are enabled after a token has finished deploying. This happens after extensions have finished executing to allow extensions to either make swaps or add liquidity to the pool. MEV Modules are active until they disable themselves or expire after 2 minutes. We have this expiry period as a safeguard in case the pool's underlying sequencer environment changes and the MEV module breaks. Additionally, liquidity adds are restricted during the MEV module's operation, as we want to reserve the ability to use the `donate()` function to send payments to only the beneficiaries of the original LP position. ### Current Mev Modules Clanker has four mev modules currently written: **v4.0, ClankerHook**: * [**ClankerMev2BlockDelay**](/documentation/references/core-contracts/v4/mev-modules/clankermevmodule2blockdelay): Prevents swaps on freshly deployed pools for 2 blocks to stop snipers from trying to search in the same block of deployment. * [**ClankerSniperAuctionV0**](/documentation/references/core-contracts/v4/mev-modules/clankersniperauctionv0): Auctions off the first few swaps for freshly deployed pools, giving the auction proceeds to creators. **v4.1, ClankerHookV2**: * [**ClankerMevDescendingFees**](/documentation/references/core-contracts/v4/mev-modules/clankermevdescendingfees): A MEV module which enables deployers to select a starting LP fee (up to 80%), an ending fee, and a duration to decay the fee over (max 2 mintues). The fee descends parabolically. Only compatible with **ClankerHookV2**. * [**ClankerSniperAuctionV2**](/documentation/references/core-contracts/v4/mev-modules/clankersniperauctionv2): The same as ClankerSniperAuctionV0 but with the fee behavior of ClankerMevDescendingFees. Auctioned swaps pay the starting fee and the fee descent starts after the auction ends. Only compatible with **ClankerHookV2**.
# ClankerMevModule2BlockDelay Clanker's fallback mev module if no chain specific module exists Clanker's fallback mev module, **ClankerMevModuleDelay**, exists when no other mev module is suitable for a chain. The module simply blocks swaps until 2 blocks after deployment. This delay is to prevent Clanker deployments from causing gas spikes. For example, when Clanker was deployed on v3, searchers caused a spike in the gas price of the network by attempting to search for deployments in the same block (documented [here](https://x.com/0xdoug/status/1861662510023123030)). The solution to this problem was to add a delay between when a pool was deployed and when it is swappable. Our initial MEV module, **ClankerMevModuleDelay**, is used to add a delay between when a pool is deployed and when it is enabled for searching. # ClankerSniperAuctionV0 Clanker's mev module for priority ordered L2s **ClankerSniperAuctionV0** is a mev module that allows snipers to bid for the right to execute the next swap on a freshly deployed pool. At deployment, a maximum of 5 auctions can run per pool, with one auction occurring every 2 blocks. If an auction block passes without any valid bids, the auction is disabled and normal swaps can execute. The original design doc can be found [here](https://hackmd.io/@lobstermindset/rkwlyMpkgl). The following contracts are a part of this setup: * [`ClankerSniperAuctionV0.sol`](https://github.com/clanker-devco/v4-contracts/blob/main/src/mev-modules/ClankerSniperAuctionV0.sol): `IClankerMevModule` instance running Clanker's first version of a sniper auction. * [`ClankerSniperUtilV0.sol`](https://github.com/clanker-devco/v4-contracts/blob/main/src/mev-modules/sniper-utils/ClankerSniperUtilV0.sol): Auxiliary helper contract providing an example of how snipers can interact with the auction process. ### How It Works The auction leverages the fact that Base uses priority ordering, meaning transactions with higher gas fees are placed before others. The auction module records the gas price each time the auction resets and uses an inflated version as the "starting" gas price for the auction. The amount of WETH collected as payment is a multiple of the difference between the winning transaction's gas price and the inflated gas price. The inflated gas price, next auction block, and current auction round can be found by querying the contract and can be easily replicated off-chain. The auction payments are split between the token's reward recipients and the Clanker factory at a 80/20 split. The following auction configuration variables are of importance to snipers: * `blocksBetweenDeploymentAndFirstAuction`: The number of blocks between the pool's deployment and the first auction. * `blocksBetweenAuction`: The number of blocks between subsequent auctions. * `maxRounds`: The maximum number of auctions that can run per pool. * `paymentPerGasUnit`: The amount of WETH to pay per gas unit above the gas peg for an auction. All of these variables are queryable on the `ClankerSniperAuctionV0` contract and can be changed by the Clanker team with advanced notice. The following auction state variables are of importance to snipers and are queryable per PoolId: * `round`: The current auction round. * `nextAuctionBlock`: The block number at which the next auction will accept bids at. * `gasPeg`: The gas price which the next round of the auction will start at. The following auction events are of importance to snipers and are emitted by the `ClankerSniperAuctionV0` contract: ```solidity // emitted when a new auction is initialized with the first round's parameters event AuctionInitialized( PoolId indexed poolId, uint256 gasPeg, uint256 indexed auctionBlock, uint256 round ); // emitted when an auction is reset, with the next round's parameters event AuctionReset( PoolId indexed poolId, uint256 gasPeg, uint256 indexed auctionBlock, uint256 round ); // emitted when a sniper wins an auction event AuctionWon(PoolId indexed poolId, address indexed payee, uint256 paymentAmount, uint256 round); // emitted when the gas payment expectation is updated // note: advanced warning will be given, will not be updated often event SetPaymentPerGasUnit(uint256 oldPaymentPerGasUnit, uint256 newPaymentPerGasUnit); ``` ### Example Auction Iteration A pool is deployed in block 1 with a base fee of 10 gwei. The first auction round occurs in block 3 with a starting auction gas price of 12 gwei. Three snipers attempt to snipe with the following configurations: * **Sniper A** sets their transaction gas price to 13 gwei, approves a WETH payment of 0.0001 ether, and lands in block 3 * **Sniper B** sets their transaction gas price to 15 gwei, approves a WETH payment of 0.0003 ether, and lands in block 3 * **Sniper C** sets their transaction gas price to 17 gwei, approves a WETH payment of 0.0005 ether, and lands in block 4 **Result:** Sniper B wins since Sniper C landed in the wrong block. The auction module uses block 3's actual gas price of 11 gwei to set the starting gas price for round 2 to 13 gwei, with bids being accepted in block 5. Note: the first auction parameters set by the Clanker team have the blocks between the first auction and deployment and subsequent auctions set to 2. These can be changed to different values after we get more data on the auction's performance. ### ClankerSniperUtilV0 Contract The `ClankerSniperUtilV0` contract is a shared utility for snipers to bid in auctions and serves as a user-facing example of how bidding works. It handles approval spending, round management, and encoding the auction swap's hook data. Snipers are welcome to rewrite and redeploy the utility themselves, as it is auxiliary to the auction setup itself. ### Example Usage ```solidity // addresses of the sniper util and auction ClankerSniperAuctionV0 sniperAuction; ClankerSniperUtilV0 sniperUtil; // addresses of the deployed clanker token, paired token, and associated poolKey // (can be found on the TokenCreated event) address clankerToken; PoolKey memory clankerPoolKey; address pairedToken; // amount of the input token to swap uint256 amountIn = AMOUNT_TOKEN_TO_SWAP; // amount of eth to pay as bid (needs to be multiple of IClankerSniperAuctionV0.PAYMENT_PER_GAS_UNIT()) uint256 bidAmount = AMOUNT_TO_BID; // approve the sniper util to pull in the swap's input token IERC20(pairedToken).approve(address(sniperUtil), amountIn); // build the desired swap to run if the bid is winning IV4Router.ExactInputSingleParams memory swapParams = IV4Router.ExactInputSingleParams({ poolKey: poolKey, amountIn: uint128(amountIn), amountOutMinimum: 0, zeroForOne: pairedToken > clankerToken, // util will fill out, needs to be address to pull WETH bid payment from hookData: abi.encode("") }); // get token's gas peg uint256 gasPeg = sniperAuction.gasPeg(poolKey.toId()); // get next auction block uint256 nextAuctionBlock = sniperAuction.nextAuctionBlock(poolKey.toId()); // get current round uint256 round = sniperAuction.round(poolKey.toId()); // determine gas price that needs to be used to match desired payment amount uint256 txGasPrice = sniperUtil.getTxGasPriceForBidAmount(gasPeg, bidAmount); // bid in auction // NOTE: you need to land this in the correct block with the correct gas price, // this will be the hardest part of using the auction until we can get // bundle support on Base, please complain on twitter to the Flashbot / Base people // that we want transactions to be able to specify which block they land in :( sniperUtil.bidInAuction{value: bidAmount}(swapParams, round); ``` ### Disclaimer Clanker reserves the right to upgrade to other auction versions depending on the usage of V0 and to change V0's configuration. We will give advanced warning of upgrades, but we may toggle how many blocks between auctions are ran and the payment multiplier. ### Warning on Approving `ClankerSniperAuctionV0` to spend WETH We do NOT recommend approving `ClankerSniperAuctionV0` to spend WETH unless you have an auxiliary contract handling the approval that reverts if the bid is not won. For example, if an EOA approves the auction contract to spend WETH, anyone can spend the EOA's WETH by passing in the EOA's address as the `auctionData` parameter to the `ClankerSniperAuctionV0::beforeSwap` function. We've provided the `ClankerSniperUtilV0` contract as an example of how to handle this. # ClankerMevDescendingFees **ClankerMevDescendingFees** is a Mev module designed to impose higher fees on snipers. Deployers are able to specify a starting LP fee (up to 80%), an ending fee, and a time to descend (up to 2 minutes). Clanker's initial recommended configuration will start effective fees at 80% and descend to 5% over 30 seconds, after which the pool's normal fee behavior will commence. For the motivation behind these choices, see our [v4 sniper activity writeup](https://paragraph.com/@clankerworld/clanker-v4_1-sniper-tech). The fees decay following the formula: `fee = endingFee + feeRange * (timeDecay / timeToDecay)²`. Swaps are able to start in the second after deployment.
The fee applied to the swap is the LP's fee plus Clanker's additional 20% fee. Clanker's default starting market cap is $40k USD, and with the proposed starting fee of 80%, we're setting the starting price for snipers at a market cap of $200k.
### Initialization Token deployers can configure the fee parameters with the following struct: ```solidity struct FeeConfig { uint24 startingFee; // LP fee to start at uint24 endingFee; // LP fee to descend to uint256 secondsToDecay; // seconds to decay over } ``` This config is set on the deployment struct as follows: ```solidity address clankerMevDescendingFees; // address of the deployed MEV module IClanker.DeploymentConfig memory deploymentConfig; // setup the MEV module data IClankerMevDescendingFees.FeeConfig memory feeConfig = IClankerMevDescendingFees.FeeConfig({ startingFee: 666777, // 66%, 80% applied fee endingFee: 50000, // 5% secondsToDecay: 30 // 30 seconds }); deploymentConfig.mevModuleConfig.mevModule = address(clankerMevDescendingFees); deploymentConfig.mevModuleConfig.mevModuleData = abi.encode(feeConfig); ``` # ClankerSniperAuctionV2 **ClankerSniperAuctionV2** is the same as [**ClankerSniperAuctionV0**](/documentation/references/core-contracts/v4/mev-modules/clankersniperauctionv0) but with fee behavior similar to that of [**ClankerMevDescendingFees**](/documentation/references/core-contracts/v4/mev-modules/clankermevdescendingfees). Deployers are able to specify a starting LP fee (up to 80%), an ending fee, and a time to descend (up to 2 minutes). Clanker's initial recommended configuration will start effective fees at 80% and descend to 5% over 30 seconds, after which the pool's normal fee behavior will commence. For the motivation behind these choices, see our [v4 sniper activity writeup](https://paragraph.com/@clankerworld/clanker-v4_1-sniper-tech). All auctioned swaps will pay the applied LP fee from the `FeeConfig.startingFee`, and the fee descent will start in the block that the auction concludes in. ### Initialization **ClankerSniperAuctionV2**, unlike V0, requires configuration data to be passed in. The setup matches that of the **ClankerMevDescendingFees** module: ```solidity address clankerSniperAuctionV2; // address of the deployed mev module IClanker.DeploymentConfig memory deploymentConfig; // setup the mev module data IClankerMevDescendingFees.FeeConfig memory feeConfig = IClankerMevDescendingFees.FeeConfig({ startingFee: 666777, // 66%, 80% applied fee endingFee: 50000, // 5% secondsToDecay: 30 // 30 seconds }); deploymentConfig.mevModuleConfig.mevModule = address(clankerSniperAuctionV2); deploymentConfig.mevModuleConfig.mevModuleData = abi.encode(feeConfig); ``` ### Sniper Interactions The interface to pass in swap data changed between **ClankerHook** and **ClankerHookV2**. For a swap's `hookData` to reach the Mev module, it needs to be encoded in the `PoolSwapData` struct: ```solidity struct PoolSwapData { bytes mevModuleSwapData; bytes poolExtensionSwapData; } ``` We made a new **ClankerSniperUtilV2** example implementation which performs the expected encoding and works with both versions of the sniper auction. ### Warning on Approving `ClankerSniperAuctionV2` to spend WETH We do NOT recommend approving `ClankerSniperAuctionV2` to spend WETH unless you have an auxiliary contract handling the approval that reverts if the bid is not won. For example, if an EOA approves the auction contract to spend WETH, anyone can spend the EOA's WETH by passing in the EOA's address as the `auctionData` parameter to the `ClankerSniperAuctionV0::beforeSwap` function. We've provided the `ClankerSniperUtilV2` contract as an example of how to handle this. # Administrative Permissions Clanker as a whole aims to be permissionless where possible and is committed to decentralization. All of our contracts currently either have no owner or are owned by Clanker's team multisig. Any 'admin' role can be assumed to be controlled by either Clanker multisigs or EOAs. None of the contracts are upgradeable. #### Clanker.sol Role: `Owner` Permissions: * Add/remove admins via `setAdmin()`. * Initialize the contract with `teamFeeRecipient` addresses, can only be done once. * Pause supplied token deployments with `setDeprecated()`. * Change the `teamFeeRecipient` via `setTeamFeeRecipient()`. * All of admin's capabilities Role: `Admin` Permissions: * Claim protocol fees to `teamFeeRecipient` via `claimTeamFees()`. * Enable/disable hooks via `setHook()`. * Enable/disable extensions via `setExtension()`. * Enable/disable mev modules via `setMevModule()`. * Enable/disable lockers via `setLocker()`. #### ClankerLpLockerMultiple.sol, ClankerLpLockerFeeConversion.sol Role: `Owner` Permissions: * Withdraw ETH sent to the contract by accident via `withdrawEth()`. * Withdraw ERC20s sent to the contract by accident via `withdrawERC20()`. #### ClankerFeeLocker.sol Role: `Owner` Permissions: * Add additional depositors via `addDepositor()`. #### No Administrative Permissions Clanker has no administrative abilities on the following contracts: * ClankerHook.sol * ClankerStaticHook.sol * ClankerDynamicHook.sol * ClankerAirdrop.sol * ClankerVault.sol * ClankerUniv4EthDevBuy.sol * ClankerMevBlockDelay.sol * ClankerToken.sol # v3.1 ## 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.
# Clanker (Direct Contract Deployments) ## Deploying a Token Tokens are deployed through the Clanker contract using the `deployToken` function: ```solidity /** * Configuration settings for token creation */ struct RewardsConfig { uint256 creatorReward; address creatorAdmin; address creatorRewardRecipient; address interfaceAdmin; address interfaceRewardRecipient; } struct TokenConfig { string name; string symbol; bytes32 salt; string image; string metadata; string context; uint256 originatingChainId; } struct VaultConfig { uint8 vaultPercentage; uint256 vaultDuration; } struct PoolConfig { address pairedToken; int24 tickIfToken0IsNewToken; } struct InitialBuyConfig { uint24 pairedTokenPoolFee; uint256 pairedTokenSwapAmountOutMinimum; } struct DeploymentConfig { TokenConfig tokenConfig; VaultConfig vaultConfig; PoolConfig poolConfig; InitialBuyConfig initialBuyConfig; RewardsConfig rewardsConfig; } function deployToken(DeploymentConfig tokenConfig) external payable {...} function deployTokenWithCustomTeamRewardRecipient(DeploymentConfig tokenConfig, address teamRewardRecipient) external payable {...} ``` ### Rewards Configuration Rewards deployed through the launchpad are split as follows: * 20% to Clanker * Up to 80% to the Creator (set with the `creatorReward` parameter) * Remaining to the Interface (can be 0%) Four addresses must be specified for token deployment: * `creatorAdmin`: The address that will manage the creator's locked token supply, creator's portion of the trading fee rewards, the token's metadata, and the receiver of the initial supply purchase (the "creator buy") * `creatorRewardRecipient`: The address that will initially receive the creator's portion of the trading fee rewards * `interfaceAdmin`: The address that will manage the interface's trading fee rewards * `interfaceRewardRecipient`: The address that will initially receive the interface's portion of the trading fee rewards ### Token Configuration The following parameters are required for token creation: * `name`: Token name * `symbol`: Token symbol * `image`: Token image * `metadata`: Token metadata (`creatorAdmin` can update this) * `context`: Additional token context containing information about who deployed the token (immutable) * `salt`: Address salt value to allow for token address customization * `originatingChainId`: Chain ID where the token's supply is deployed {% hint style="info" %} Tokens will be deployed with a fixed supply of 100,000,000,000. {% endhint %} ### Vault Configuration (Optional) Users can lock a portion of the token supply in a vault with these parameters: * `vaultDuration`: Lock duration (minimum 30 days) * `vaultPercentage`: Percentage of supply to lock (maximum 30%) The `creatorAdmin` address will have administrative control over the locked tokens in the ClankerVault contract. ### Pool Configuration After token creation, a 1% fee tiered Uniswap V3 Pool is deployed. The remaining non-vaulted token supply is then added as a single-sided liquidity position. Required parameters: * `tickIfToken0IsNewToken`: Initial token price in the pool * `pairedToken`: Token to pair with the new token The liquidity position's NFT is transferred to the LpLockerv2 contract, where each fee-receiving entity has control over who receives their portion of the trading fees. ### Initial Swap Configuration (Optional) Users can perform an initial swap (a creator buy) using ETH (sent via `msg.value`). For non-WETH paired tokens, the contract first internally swaps ETH to the paired token (ETH -> pairedToken -> new token). Required parameters: * `msg.value`: ETH amount for the swap * `pairedTokenSwapAmountOutMinimum`: Minimum amount of paired tokens to receive if ETH is not the paired token * `pairedTokenPoolFee`: Pool fee for the ETH -> pairedToken swap The `creatorAdmin` address receives the new tokens purchased with the ETH sent. # LpLockerv2 The LpLockerv2 contract manages trading fees from the Clanker contract, with a 20/80 split between Clanker and token's interface / creator. Only the Clanker contract can deposit new liquidity position NFTs. The `tokenId` parameter is the token's associated liquidity position NFT ID (emitted and returned from `deployToken()`). ### User Functions `updateCreatorRewardAdmin()`: Allows creator NFT admin to change the admin for their token ```solidity // note: will revert if not called by the token's admin function updateCreatorRewardAdmin( uint256 tokenId, // Token ID to update address newAdmin // New administrator address ) public {...} ``` A similar function exists for the interface's reward recipient, `updateInterfaceRewardAdmin()`. `updateCreatorRewardRecipient()`: Allows creator NFT admin to update the reward recipient for their token ```solidity // note: will revert if not called by the token's admin function updateCreatorRewardRecipient( uint256 tokenId, // Token ID to update address newRecipient // New reward recipient ) public {...} ``` A similar function exists for the interface's reward recipient, `updateInterfaceRewardRecipient()`. `claimRewards()`: Allows any address to claim accumulated trading fees ``` // note: callable by anyone function claimRewards( uint256 tokenId // Token ID for claiming rewards ) public {...} ``` Claimed rewards are distributed with 20% going to Clanker and 80% split between the creator and the interface. If the reward recipient is set to the zero address for non-Clanker rewards, the Clanker receives all fees. # ClankerVault The ClankerVault contract manages locked tokens from the Clanker contract. Only the Clanker contract can deposit tokens into the vault, and tokens can only be vaulted once. Each token has the `creatorAdmin` as the initial admin for the token. The token's address (emitted and returned from `deployToken()`) is used as the token parameter for all ClankerVault functions. ### User Functions `withdraw()`: Allows users to withdraw tokens that have reached their unlock time ```solidity // note: will revert if not called by the token's admin function withdraw( address token, // Token to withdraw uint256 amount, // Withdrawal amount address to // Recipient address ) external {...} ``` `editAllocationAdmin()`: Allows changing the token's admin ```solidity // note: will revert if not called by the token's admin function editAllocationAdmin( address token, // Token to modify address newAdmin // New administrator address ) external {...} ``` # ClankerToken v3.1.0 and v4.0.0 The tokens deployed by the Clanker factory are ERC20s with ERC20Permit, ERC20Votes and ERC20Burnable capabilities. Tokens are deployed with an 'admin' key which is able to verify the contract, update the image, and update the metadata. #### User Facing Functions: ```solidity // only callable by token's admin function updateImage(string memory image_) external; // only callable by token's admin function updateMetadata(string memory metadata_) external; // only callable by token's admin function verify() external; ``` ## 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](https://docs.optimism.io/stack/interop/superchain-erc20). {% hint style="info" %} 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. {% endhint %} 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: ```solidity // Use the same tokenConfig as that was used to deploy the token on the // originating chain with the `creatorAdmin as the `tokenAdmin` function deployTokenZeroSupply(_version_specific_parameters_) external returns (address tokenAddress) {...} ``` # Brand Assets A collection of designs, logos, and ephemera in PNG and SVG format [Google Drive](https://drive.google.com/drive/folders/15-9L23e79K9w7_tXk279aCs8aZtE5dmv?usp=drive_link) {% embed url="" %} [Figma](https://www.figma.com/design/AcUDfTVpycMZZrC8lHxcRn/Clanker---Public-Assets?node-id=0-1\&p=f\&t=o1xe8FIgq86SZiIh-0) {% embed url="" fullWidth="false" %} # Audits ### August 2025, Clanker v4.1 #### Macro {% file src="/files/0NV12ITjTIwinUa2W4SX" %} ### June-July 2025, Clanker v4 #### Cantina {% file src="/files/oJout3avKFGUCOvkYSrm" %} #### Macro {% file src="/files/iF0BdM4Kw5L9tbTVG8b0" %} {% file src="/files/okxhAjl3C2zqoDUQ5zqE" %} ### March 2025, Clanker v3.1.0 #### Macro {% file src="/files/iqzfONkm8p8NVbVW0Lfe" %} ### January 2025, Clanker v2.0.0 #### Quantstamp {% file src="/files/EAtllA9RHfJOsD9hPVOy" %} # Compatible Trading Platforms {% hint style="info" %} If you are a trading platform or venue and would like to integrate with Clanker's pools, please reach out at [Contact](/documentation/references/contact). {% endhint %} ### Clanker v4.0.0 Clanker v4.0.0 deploys tokens into Uniswap v4 pools and utilizes custom Uniswap v4 hooks. Due to the complexity of Clanker's custom hooks, not all trading platforms and venues currently support trading through Clanker v4.0.0 pools. Integrations with additional trading venues are underway. {% hint style="warning" %} Most Telegram trading bots on Base have not yet integrated Uniswap v4 and / or Clanker's Uniswap v4 hooks. {% endhint %} Please see below for a list of known, compatible trading platforms as of `July 8, 2025`: **Aggregators** * 0x / Matcha **Wallets** * Rainbow * Rabby * Coinbase Wallet **Other Trading Platforms / Frontends** * Clanker.world * Uniswap * Oku Trade * LlamaSwap * Based Trading Bot ### Clanker v3.1.0 and Previous Clanker v3.1.0 and previous versions deploys tokens into Uniswap v3 pools, which are widely supported by almost all trading venues. Users may run into issues trading Clanker tokens with paired tokens other than $WETH if the paired token does not have a liquid `$pairedToken / $WETH` pool. In this case, users will need to hold the paired token directly to avoid attempting to pool hop ($ETH to $pairedToken to $clankerToken) when trading.
# Deployed Contracts ## Mainnet Deployments ### Base: 8453
v4.1.0 | Contract | Contract Address | | ----------------------------- | ------------------------------------------ | | ClankerHookDynamicFeeV2 | 0xd60D6B218116cFd801E28F78d011a203D2b068Cc | | ClankerHookStaticFeeV2 | 0xb429d62f8f3bFFb98CdB9569533eA23bF0Ba28CC | | ClankerSniperAuctionV2 | 0xebB25BB797D82CB78E1bc70406b13233c0854413 | | ClankerSniperUtilV2 | 0xC5AA2945d52a4096b946891ef8e01668f82eB74E | | ClankerAirdropV2 | 0xf652B3610D75D81871bf96DB50825d9af28391E0 | | ClankerPoolExtensionAllowlist | 0xaa12bb11E9876FCAFc7c46dBEB985d3fA23832c9 |
v4.0.0 | Contract | Contract Address | | ---------------------------- | ------------------------------------------ | | Clanker | 0xE85A59c628F7d27878ACeB4bf3b35733630083a9 | | ClankerFeeLocker | 0xF3622742b1E446D92e45E22923Ef11C2fcD55D68 | | ClankerLpLockerFeeConversion | 0x63D2DfEA64b3433F4071A98665bcD7Ca14d93496 | | ClankerVault | 0x8E845EAd15737bF71904A30BdDD3aEE76d6ADF6C | | ClankerAirdrop | 0x56Fa0Da89eD94822e46734e736d34Cab72dF344F | | ClankerUniv4EthDevBuy | 0x1331f0788F9c08C8F38D52c7a1152250A9dE00be | | ClankerMevBlockDelay | 0xE143f9872A33c955F23cF442BB4B1EFB3A7402A2 | | ClankerSniperAuctionV0 | 0xFdc013ce003980889cFfd66b0c8329545ae1d1E8 | | ClankerSniperUtilV0 | 0x8806169969aE96bfaaDb3eFd4B10785BEEb321b3 | | ClankerHookDynamicFee | 0x34a45c6B61876d739400Bd71228CbcbD4F53E8cC | | ClankerHookStaticFee | 0xDd5EeaFf7BD481AD55Db083062b13a3cdf0A68CC | | ClankerLpLocker | 0x29d17C1A8D851d7d4cA97FAe97AcAdb398D9cCE0 |
v3.1.0 | Contract | Contract Address | | ------------ | ------------------------------------------ | | Clanker | 0x2A787b2362021cC3eEa3C24C4748a6cD5B687382 | | LpLockerv2 | 0x33e2Eda238edcF470309b8c6D228986A1204c8f9 | | ClankerVault | 0x42A95190B4088C88Dd904d930c79deC1158bF09D |
v3.0.0 | Contract | Contract Address | | -------------- | ------------------------------------------ | | Clanker | 0x375C15db32D28cEcdcAB5C03Ab889bf15cbD2c5E | | ClankerPreSale | 0x71cDc0bDF30F5601fb0ac80Cf1d20B771342C035 | | LPLockerv2 | 0x5eC4f99F342038c67a312a166Ff56e6D70383D86 |
v2.0.0 | Contract | Contract Address | | ---------- | ------------------------------------------ | | Clanker | 0x732560fa1d1A76350b1A500155BA978031B53833 | | LPLockerv2 | 0x618A9840691334eE8d24445a4AdA4284Bf42417D |
v1.0.0 | Contract | Contract Address | | ------------- | ------------------------------------------ | | Clanker | 0x9B84fcE5Dcd9a38d2D01d5D72373F6b6b067c3e1 | | LockerFactory | 0x18db5Fce22bE8814B7E31FBDA2f6488d607A1172 |
v0.0.0 | Contract | Contract Address | | ----------------- | ------------------------------------------ | | SocialDexDeployer | 0x250c9FB2b411B48273f69879007803790A6AeA47 | | LockerFactory | 0x515d45F06EdD179565aa2796388417ED65E88939 |
### Arbitrum One: 42161
v4.1.0 | Contract | Contract Address | | ---------------- | ------------------------------------------ | | ClankerAirdropV2 | 0x8Cb6e0216e98A7ACF622DC2dD6a39F1b4FF37014 |
v4.0.0 | Contract | Contract Address | | ---------------------------- | ------------------------------------------ | | Clanker | 0xEb9D2A726Edffc887a574dC7f46b3a3638E8E44f | | ClankerFeeLocker | 0x92C0DCbAba17b0F5f3a7537dA82c0F80520e4dF6 | | ClankerLpLockerFeeConversion | 0xF3622742b1E446D92e45E22923Ef11C2fcD55D68 | | ClankerVault | 0xa1da0600Eb4A9F3D4a892feAa2c2caf80A4A2f14 | | ClankerAirdrop | 0x303470b6b6a35B06A5A05763A7caD776fbf27B71 | | ClankerUniv4EthDevBuy | 0x70aDdc06fE89a5cF9E533aea8D025dB06795e492 | | ClankerMevBlockDelay | 0x4E35277306a83D00E13e8C8A4307C672FA31FC99 | | ClankerHookDynamicFee | 0xFd213BE7883db36e1049dC42f5BD6A0ec66B68cC | | ClankerHookStaticFee | 0xf7aC669593d2D9D01026Fa5B756DD5B4f7aAa8Cc |
### Unichain: 130
v4.1.0 | Contract | Contract Address | | ---------------- | ------------------------------------------ | | ClankerAirdropV2 | 0xE143f9872A33c955F23cF442BB4B1EFB3A7402A2 |
v4.0.0 | Contract | Contract Address | | ---------------------------- | ------------------------------------------ | | Clanker | 0xE85A59c628F7d27878ACeB4bf3b35733630083a9 | | ClankerFeeLocker | 0x1d5A0F0BD3eA07F78FC14577f053de7A3FEc35B2 | | ClankerLpLockerFeeConversion | 0x691f97752E91feAcD7933F32a1FEdCeDae7bB59c | | ClankerVault | 0xA9C0a423f0092176fC48d7B50a1fCae8cf5BB441 | | ClankerAirdrop | 0x35bfE89d95F26674bF06bB8bFE55f8D73E9280D2 | | ClankerUniv4EthDevBuy | 0x267259e36914839Eb584e962558563760AE28862 | | ClankerMevBlockDelay | 0x42A95190B4088C88Dd904d930c79deC1158bF09D | | ClankerHookDynamicFee | 0x9b37A43422D7bBD4C8B231be11E50AD1acE828CC | | ClankerHookStaticFee | 0xBc6e5aBDa425309c2534Bc2bC92562F5419ce8Cc | | ClankerSniperAuctionV0 | 0x78B512C5074a1084bf3b8e6cbA8a1710d2a8d0A2 | | ClankerSniperUtilV0 | 0xA25e594869ddb46c33233A793E3c8b207CC719a2 |
### Mainnet: 1
v4.1.0 | Contract | Contract Address | | ---------------- | ------------------------------------------ | | ClankerAirdropV2 | 0x303470b6b6a35B06A5A05763A7caD776fbf27B71 |
v4.0.0 | Contract | Contract Address | | ---------------------------- | ------------------------------------------ | | Clanker | 0x6C8599779B03B00AAaE63C6378830919Abb75473 | | ClankerFeeLocker | 0xA9C0a423f0092176fC48d7B50a1fCae8cf5BB441 | | ClankerLpLockerFeeConversion | 0x00C4b21889145CF0D99f2e05919103e0c3991974 | | ClankerVault | 0xa1da0600Eb4A9F3D4a892feAa2c2caf80A4A2f14 | | ClankerAirdrop | 0x303470b6b6a35B06A5A05763A7caD776fbf27B71 | | ClankerUniv4EthDevBuy | 0x70aDdc06fE89a5cF9E533aea8D025dB06795e492 | | ClankerMevBlockDelay | 0x33e2Eda238edcF470309b8c6D228986A1204c8f9 | | ClankerHookDynamicFee | not supported | | ClankerHookStaticFee | 0x6C24D0bCC264EF6A740754A11cA579b9d225e8Cc | | ClankerSniperAuctionV0 | 0x33e2Eda238edcF470309b8c6D228986A1204c8f9 | | ClankerSniperUtilV0 | 0x33e2Eda238edcF470309b8c6D228986A1204c8f9 |
## Binance: 97
v4.1.0 | Contract | Contract Address | | ---------------- | ------------------------------------------ | | ClankerAirdropV2 | 0xBB0f069b995e0205cD5F92C84a1dF056a3F47900 |
v4.0.0 | Contract | Contract Address | | ---------------------------- | ------------------------------------------ | | Clanker | 0xea30438E0B5f99096cb05A8Da63be55A6A298F6a | | ClankerFeeLocker | 0x67D04Ae42F03D9b63dE0E6F2d82bB186A0306bBb | | ClankerLpLockerFeeConversion | 0x1166022e1becc70E7E9aB2250aF1aC7842B9B420 | | ClankerVault | 0x15ee8382DBd8Fb991F653B59CA11bf504a07372D | | ClankerAirdrop | 0xBB0f069b995e0205cD5F92C84a1dF056a3F47900 | | ClankerUniv4EthDevBuy | 0x302989E1cA167B6E78f9711e5a08d1BD555DdAc4 | | ClankerMevBlockDelay | 0x33e2Eda238edcF470309b8c6D228986A1204c8f9 | | ClankerHookDynamicFee | 0x011a8ed40095F2D7E9c19125B8254b19678D68Cc | | ClankerHookStaticFee | 0xC5d309026BCAb6630888d51CE21154AD2f4828cC | | mevModuleV2 | 0xec1310cf227a2D671176000aE0849DE6417b175a | | mevModule | 0xEE2940CC010820B7F22DF627e081d707693989a6 |
## Monad: 143
v4.1.0 | Contract | Contract Address | | ---------------------------- | ---------------------------------------------------------- | | Clanker | 0xF9a0C289Eab6B571c6247094a853810987E5B26D | | ClankerFeeLocker | 0xDe51a86D3b6EC9ac4756115D3744335Aa2c30144 | | ClankerLpLockerFeeConversion | 0x46B77BaCFd712D79131F1AD7611794869483C353 | | ClankerVault | 0xe7D402A5BEd94E5c49Ac0639E80f784D06E2D397 | | ClankerAirdrop | 0x654E7221fa51d4359ded21D524E3AfF18e93A507 | | ClankerUniv4EthDevBuy | 0x8790d79283eB941c719b616CfD0Ef116D13C7683 | | ClankerMevBlockDelay | 0x3231D1ddfdC4Ad585cF1939FfEcd9c88b338Dbf2 | | ClankerHookDynamicFee | 0x0000000000000000000000000000000000000000 (not supported) | | ClankerHookStaticFee | 0x94F802a9EFE4dd542FdBd77a25D9e69A6dC828Cc | | mevModuleV2 | 0x3231D1ddfdC4Ad585cF1939FfEcd9c88b338Dbf2 | | mevModule | 0x3231D1ddfdC4Ad585cF1939FfEcd9c88b338Dbf2 |
## Solana Tag `@clanker` on Farcaster or `@clanker_world` on X to deploy a Meteora token on Solana. ## Testnet Deployments ### Base Sepolia: 84532
v4.1.0 | Contract | Contract Address | | ----------------------------- | ------------------------------------------ | | ClankerHookDynamicFeeV2 | 0xBF4983dC0f2F8FE78C5cf8Fc621f294A993728Cc | | ClankerHookStaticFeeV2 | 0x11b51DBC2f7F683b81CeDa83DC0078D57bA328cc | | ClankerSniperAuctionV2 | 0x8CBD6694A9DFc0eF4D1cd333e013B88E7003E10A | | ClankerSniperUtilV2 | 0x4DC6348D38E3e199D7Ea032c8cfE4EbDe94b442A | | ClankerAirdropV2 | 0x5c68F1560a5913c176Fc5238038098970B567B19 | | ClankerPoolExtensionAllowlist | 0x532d79D18F0F1782884662fCC1e74581A3289680 |
v4.0.0 | Contract | Contract Address | | ---------------------------- | ------------------------------------------ | | Clanker | 0xE85A59c628F7d27878ACeB4bf3b35733630083a9 | | ClankerFeeLocker | 0x42A95190B4088C88Dd904d930c79deC1158bF09D | | ClankerLpLockerMultiple | 0x33e2Eda238edcF470309b8c6D228986A1204c8f9 | | ClankerVault | 0xcC80d1226F899a78fC2E459a1500A13C373CE0A5 | | ClankerAirdrop | 0x29d17C1A8D851d7d4cA97FAe97AcAdb398D9cCE0 | | ClankerUniv4EthDevBuy | 0x691f97752E91feAcD7933F32a1FEdCeDae7bB59c | | ClankerMevBlockDelay | 0x71DB365E93e170ba3B053339A917c11024e7a9d4 | | ClankerHookDynamicFee | 0xE63b0A59100698f379F9B577441A561bAF9828cc | | ClankerHookStaticFee | 0xDFcCcfBeef7F3Fc8b16027Ce6feACb48024068cC | | ClankerSniperAuctionV0 | 0x261fE99C4D0D41EE8d0e594D11aec740E8354ab0 | | ClankerSniperUtilV0 | 0x8806169969aE96bfaaDb3eFd4B10785BEEb321b3 | | ClankerLpLockerFeeConversion | 0x824bB048a5EC6e06a09aEd115E9eEA4618DC2c8f |
v3.1.0 | Contract | Contract Address | | ------------ | ------------------------------------------ | | Clanker | 0x2A787b2362021cC3eEa3C24C4748a6cD5B687382 | | LpLockerv2 | 0xa1da0600Eb4A9F3D4a892feAa2c2caf80A4A2f14 | | ClankerVault | 0xA9C0a423f0092176fC48d7B50a1fCae8cf5BB441 |
### Monad Testnet: 10143
v3.1.0 | Contract | Contract Address | | ------------ | ------------------------------------------ | | Clanker | 0xA0C65813DD1Cde7092922a57548Ec1eD25994318 | | LpLockerv2 | 0xcd89C55d36097a64f777066A6cc8F2c31B7541F7 | | ClankerVault | 0x9505A57Bf782058890f078bE301575cD75045a9b |
# Supported Quote Tokens {% hint style="info" %} These quote tokens are supported for deployments via the @clanker bot on Farcaster and API deployments. Starting with release v0.3.1, users may permissionlessly interact with the Clanker token factory to deploy tokens paired with arbitrary quote tokens and that start at arbitrary market caps. {% endhint %} {% hint style="warning" %} The Starting Market Cap, denominated in the quote token, is subject to change. Please refer to this page for the latest info. {% endhint %}
Token NameTickerChainContract AddressApproximate Starting Market CapInitial Tick
Wrapped EtherWETHBase0x420000000000000000000000000000000000000610 WETH-230400
A0xA0XBase0x820c5f0fb255a1d18fd0ebb0f1ccefbc4d546da7~6.85B A0X-152800
Coinbase Wrapped BTCcbBTCBase0xcbB7C0000aB88B473b1f5aFd9ef808440eed33Bf0.1 cbBTC-391600
DegenDEGENBase0x4ed4E862860beD51a9570b96d89aF5E1B0Efefed666,667 DEGEN-164600
higherHIGHERBase0x0578d8A44db98B23BF096A382e016e29a5Ce0ffe1,250,000 HIGHER-134600
NativeNATIVEBase0x20DD04c17AFD5c9a8b3f2cdacaa8Ee7907385BEF25,000,000 NATIVE-167600
Super AnonANONBase0x0Db510e79909666d6dEc7f5e49370838c16D950f10,000,000 ANON-167600
tokenbotCLANKERBase0x1bc0c42215582d5A085795f4baDbaC3ff36d1Bcb500 CLANKER-179200
# Core Team * Jack Dishman: [Farcaster](https://warpcast.com/dish), [X](https://x.com/JackDishman) * Carter Appleton: [Farcaster](https://warpcast.com/carter) * Rishav Mukherji: [Farcaster](https://farcaster.xyz/rish), [X](https://x.com/rish_neynar) * Manan Patel: [Farcaster](https://farcaster.xyz/manan), [X](https://x.com/rish_neynar) # Contact Please leave us a message [here](https://clanker.world/contact-us). We'd love to hear from you!