# Manage Token Transfer Fees Using Foundry
Source: https://docs.chain.link/ccip/evm/tutorials/cross-chain-tokens/set-transfer-fee-config-foundry
Last Updated: 2026-05-05

> For the complete documentation index, see [llms.txt](/llms.txt).

## Guide Versions

- [Foundry](/ccip/evm/tutorials/cross-chain-tokens/set-transfer-fee-config-foundry)

- [Hardhat](/ccip/evm/tutorials/cross-chain-tokens/set-transfer-fee-config-hardhat)

CCIP 2.0 token pools let pool owners opt into **pool-level token transfer fee overrides** per destination lane. When an override is disabled, the [OnRamp](https://github.com/smartcontractkit/chainlink-ccip/tree/contracts-ccip-v2.0.0/chains/evm/contracts/onRamp/OnRamp.sol) falls back to [`FeeQuoter`](https://github.com/smartcontractkit/chainlink-ccip/tree/contracts-ccip-v2.0.0/chains/evm/contracts/FeeQuoter.sol) defaults for that lane. In this tutorial you will:

1. Review the current fee configuration for both configured lanes.
2. Optionally set a fee admin who can withdraw accrued fees.
3. Configure lane-specific flat fees, transfer fees, destination gas overhead, and destination bytes overhead.
4. Send a LINK-paid transfer and inspect accrued fees in the source token pool.
5. Withdraw accrued fee tokens.
6. Disable the fee configuration on both lanes to return to `FeeQuoter` defaults.

> **NOTE: Defaults apply unless you opt in**

## Before You Begin

## Tutorial

> **TIP: Prerequisites**
>
> This tutorial assumes you have already deployed tokens and token pools on both chains. If not, complete one of the two
> tutorials first:
>
> [Burn & Mint](/ccip/evm/tutorials/cross-chain-tokens/register-from-eoa-burn-mint-foundry)
>
> [Lock & Mint](/ccip/evm/tutorials/cross-chain-tokens/register-from-eoa-lock-mint-foundry)
>
> Use the token pool address for the chain you are configuring. In a Burn & Mint setup, both pools are 
> `BurnMintTokenPool` contracts. In a Lock & Mint setup, the source chain can use a 
> `LockReleaseTokenPool` backed by an `ERC20LockBox`, while the destination chain uses a 
> `BurnMintTokenPool`. This tutorial configures the token pool, not the lockbox.
>
> ```bash filename="Terminal"
> export ETHEREUM_SEPOLIA_TOKEN=0x...
> export ETHEREUM_TESTNET_SEPOLIA_ARBITRUM_1_TOKEN=0x...
>
> export ETHEREUM_SEPOLIA_TOKEN_POOL=0x...
> export ETHEREUM_TESTNET_SEPOLIA_ARBITRUM_1_TOKEN_POOL=0x...
> ```

> **CAUTION: Troubleshooting**
>
> **Owner revert:** confirm `KEYSTORE_NAME` is the owner of the source-chain token pool.
>
> **Fee admin withdrawal revert:** confirm the fee admin was set, the correct fee admin keystore is
> used, and the action is withdrawal rather than owner-only configuration.
>
> **Missing gas:** confirm the broadcaster has native gas on the source chain.
>
> **Missing LINK:** confirm the sender has source-chain LINK when using `--fee-token LINK`.
>
> **Missing lane:** confirm the pool lane was configured with `ApplyChainUpdates.s.sol`.
>
> **Wrong lane or pool:** confirm `--rpc-url`, `DEST_CHAIN`, and the source pool
> env var match the intended source -> destination lane.
>
> **Invalid config:** confirm `DEST_GAS_OVERHEAD` is not `0`, 
> `DEST_BYTES_OVERHEAD` is at least `32`, and basis points values are below `10000`.
>
> **Fast-finality revert:** confirm the pool allows block-depth finality and the requested 
> `finality=<N>` is not below the pool minimum.
>
> **No accrued fees:** confirm `FEE_TOKENS` includes LINK and the source token, the send
> completed, native fee token was not used, and flat or basis points fee values are non-zero.

> **CAUTION: Educational Example Disclaimer**
>
> This page includes an educational example to use a Chainlink system, product, or service and is provided to
> demonstrate how to interact with Chainlink's systems, products, and services to integrate them into your own. This
> template is provided "AS IS" and "AS AVAILABLE" without warranties of any kind, it has not been audited, and it may be
> missing key checks or error handling to make the usage of the system, product or service more clear. Do not use the
> code in this example in a production environment without completing your own audits and application of best practices.
> Neither Chainlink Labs, the Chainlink Foundation, nor Chainlink node operators are responsible for unintended outputs
> that are generated due to errors in code.