CCIP v2.0.0 Token Pools

Token pools are the onchain contracts that custody, burn, mint, and/or route tokens as part of CCIP transfers. Your choice of pool determines the token custody model, required token permissions, and operational assumptions.

Choose a pool model

Lock / Release

Use this model when tokens are bridged by escrowing liquidity on the source chain and releasing escrowed liquidity on the destination chain.

Pick this when:

1. You cannot mint/burn the token.
2. You want a custody-based bridge model with explicit pool liquidity.

Start here:

1. LockReleaseTokenPool: Standard lock-and-release pool for most ERC20 tokens.
2. SiloedLockReleaseTokenPool: Lock-and-release with additional isolation constraints (use when you need stricter separation semantics).

Related:

1. ERC20LockBox: Helper contract used in some lock/release setups.

Links:

1. LockReleaseTokenPool
2. SiloedLockReleaseTokenPool
3. ERC20LockBox

Burn / Mint

Use this model when the token supports controlled supply changes and your pool can be granted burner and minter permissions.

Pick this when:

1. The token implements a burn/mint interface compatible with the pool variant.
2. You want a model that does not require destination-side liquidity escrow.

Start here:

1. BurnMintTokenPool: Standard burn-on-source and mint-on-destination pool.
2. If you need a specific burn signature or mint target behavior, choose one of the variants below.

Variants (choose based on token interface and desired behavior):

1. BurnFromMintTokenPool
2. BurnWithFromMintTokenPool
3. BurnToAddressMintTokenPool
4. BurnMintWithLockReleaseFlagTokenPool

Reference base:

1. BurnMintTokenPoolAbstract: Abstract base that implements shared mint-side logic and optional behaviors for burn/mint pools.

Links:

1. BurnMintTokenPool
2. BurnMintTokenPoolAbstract
3. BurnFromMintTokenPool
4. BurnWithFromMintTokenPool
5. BurnToAddressMintTokenPool
6. BurnMintWithLockReleaseFlagTokenPool

Operational notes:

1. You must plan role management for mint/burn permissions (grant, rotate, revoke).
2. Failures in mint/burn permissions manifest as execution failures on the destination chain.

USDC (CCTP-backed)

Use these pools when bridging USDC via Circle’s CCTP message flow (as wired by CCIP).

Pick this when:

1. You are bridging USDC and want CCTP semantics.
2. You need the CCIP-managed pool implementations for USDC.

Start here:

1. USDCTokenPoolProxy: Proxy pool for USDC integrations.
2. CCTPThroughCCVTokenPool: Token pool that routes through CCV verification for CCTP-based transfers.
3. CCTPMessageTransmitterProxy: Proxy used to interface with the CCTP MessageTransmitter in supported setups.
4. SiloedUSDCTokenPool: USDC pool variant with additional isolation constraints.

Links:

1. USDCTokenPoolProxy
2. CCTPThroughCCVTokenPool
3. CCTPMessageTransmitterProxy
4. SiloedUSDCTokenPool

Specialized

Use these pools only when you specifically need their underlying integration model.

Links:

1. LombardTokenPool

Base contract reference

TokenPool is the shared base implementation used by multiple pool types. Most builders will use a concrete pool above rather than deploying TokenPool directly.

Link:

1. TokenPool