CCIP v2.0.0 IPoolV2 API Reference

IPoolV2 defines the interface for CCIP V2 token pools.

If you implement this interface, you define how tokens are locked, burned, released, or minted during cross-chain transfers, along with how fees, verification requirements, and finality constraints are applied.

Compared to V1, this interface adds:

• finality configuration (requestedFinalityConfig)
• verifier selection (getRequiredCCVs)
• fee and gas configuration surfaces

requestedFinalityConfig specifies the desired finality or confirmation guarantees for the transfer.

Most applications do not interact with this interface directly. It is implemented by pool contracts used within CCIP infrastructure.

Usage Boundary

You typically do not use this interface directly.

• CCIP pools implement this interface to define token transfer behavior.
• OnRamp and OffRamp components call these functions during cross-chain execution.
• You implement this interface only if you are building a custom token pool.
• You are responsible for validation, authorization, and correct token handling.

Contract

interfaces/IPoolV2.sol

Import

import {IPoolV2} from "chainlink-ccip/interfaces/IPoolV2.sol";

If you have not installed the package:

npm install @chainlink/contracts-ccip@2.0.0

Inheritance

• IERC165

External API

lockOrBurn

function lockOrBurn(
  Pool.LockOrBurnInV1 calldata lockOrBurnIn,
  bytes4 requestedFinalityConfig,
  bytes calldata tokenArgs
) external returns (
  Pool.LockOrBurnOutV1 memory lockOrBurnOut,
  uint256 destTokenAmount
)

Locks or burns tokens on the source chain and prepares data for destination execution.

Returns:

releaseOrMint

function releaseOrMint(
  Pool.ReleaseOrMintInV1 calldata releaseOrMintIn,
  bytes4 requestedFinalityConfig
) external returns (
  Pool.ReleaseOrMintOutV1 memory releaseOrMintOut
)

Releases or mints tokens on the destination chain.

Returns:

getRequiredCCVs

function getRequiredCCVs(
  address localToken,
  uint64 remoteChainSelector,
  uint256 sourceAmount,
  bytes4 requestedFinalityConfig,
  bytes calldata extraData,
  MessageDirection direction
) external view returns (
  address[] memory requiredCCVs
)

Returns the set of verifiers required to validate a transfer based on token, amount, and finality requirements.

Returns:

getTokenTransferFeeConfig

function getTokenTransferFeeConfig(
  address localToken,
  uint64 destChainSelector,
  bytes4 requestedFinalityConfig,
  bytes calldata tokenArgs
) external view returns (
  TokenTransferFeeConfig memory feeConfig
)

Returns fee configuration for a token transfer.

Returns:

getFee

function getFee(
  address localToken,
  uint64 destChainSelector,
  uint256 amount,
  address feeToken,
  bytes4 requestedFinalityConfig,
  bytes calldata tokenArgs
) external view returns (
  uint256 feeUSDCents,
  uint32 destGasOverhead,
  uint32 destBytesOverhead,
  uint16 tokenFeeBps,
  bool isEnabled
)

Returns detailed fee information for a transfer.

Returns:

• If isEnabled is false, transfers for the given configuration are not allowed.

getRemoteToken

function getRemoteToken(uint64 remoteChainSelector) external view returns (bytes memory)

Returns the representation of the token on the remote chain.

Returns:

Notes

• This interface does not enforce validation or authorization logic.
• Implementations define how tokens are locked, burned, released, or minted.
• Implementations must ensure only authorized CCIP components can trigger token movements.
• Fee calculations depend on the exact input parameters. Changing the message or token configuration requires re-quoting the fee.
• V2 interfaces introduce configurable verification and finality, which are not present in V1.
• Incorrect implementation can result in loss of funds or inconsistent cross-chain state.

Related Interfaces & Contracts

• IPoolV1
• IPoolV1V2
• TokenPool
• Pool