Fees & Billing

Using CCIP incurs fees that reflect the resources required for both offchain verification and onchain execution.

Fee Model

A CCIP message may include multiple fee components. The total fee is the sum of all applicable components and is calculated at send time.

The final quoted fee depends on the specific message configuration, including:

• Source and destination chain
• Destination chain gas price environment
• Configured receiver gas limit
• Payload size
• Selected speed (finality configuration)
• Security or compliance requirements

Fee Components

Fee components are applied in two ways:

• Additive fees are paid in the feeToken on top of the transfer amount
• Subtractive fees (if configured by the token pool owner) are deducted from the transferred token amount

Executor Fee

The Executor Fee represents the cost of delivering and executing the message on the destination chain. This fee is estimated upfront and charged on the source chain.

It is calculated as:

Executor Fee = Destination Gas Fee + (Optional) Flat Fee

The Destination Gas Fee is the variable part. It is estimated in gas units on the destination chain, then converted to the selected feeToken:

Destination Gas Fee (in feeToken) = Total destination gas × Destination gas price

Where total destination gas is:

Total destination gas = User gas limit (extra args) + Destination gas overhead + Gas for verification + Gas for token transfers + (Destination gas per payload byte × Payload size)

Destination Gas Components

• Destination gas price: CCIP maintains a cache of the destination chain's gas price on the source blockchain (in USD per gas unit). At quote time, this is converted into the selected feeToken.
• Gas limit (user-specified, extra args): The gasLimit set by the user in the message extra args. This is the maximum gas CCIP can use to call ccipReceive() on the receiver contract on the destination chain. Set to 0 for token-only transfers with no callback. The user is billed for the gas specified, not the gas actually used; unused gas is not refunded.
• Destination gas overhead: Fixed base gas CCIP adds on top of the user-specified gas limit to run delivery on the destination chain.
• Gas for verification: Gas required by any Cross-Chain Verifiers (CCVs) attached to the message. If no CCVs are used, this term is 0.
• Gas for token transfers: Additional gas to deliver tokens on the destination chain. The value is set by the Token Transfer Fee config (per destination chain default / token-specific value on the FeeQuoter), or returned by the token pool when a V2 pool has custom fee config enabled. If there are no token transfers, this term is 0.
• Destination gas per payload byte: A per-byte rate applied to the total payload size. Payload size includes the message data field plus message-encoding overhead (and any CCV or pool byte contributions). If there is no data (token-only), the data portion is 0, but a small encoding overhead still applies.

Optional flat fee

If the executor is not NO_EXECUTION_ADDRESS, the executor may also charge a flat USD fee via getFee(). That flat fee is paid in feeToken on top of the Destination Gas Fee.

Important notes

• Gas limits: The user-specified gasLimit in extra args controls the ccipReceive() budget. If set too low, execution may fail. If set too high, unused gas is not refunded.
• Execution constraints: Gas limits and execution behavior may also be affected by service limits and token pool configuration.
• Custom executors: May charge an additional flat premium via getFee(). The default Chainlink-operated executor typically charges no flat premium, but destination execution gas cost still applies.
• No execution option: If NO_EXECUTION_ADDRESS is specified, the executor flat fee is zero and execution gas cost is not added.

CCV Fee

Cross-Chain Verifiers (CCVs) may charge a fee for validating messages and generating verification data.

• The default Chainlink-operated CCV does not currently charge a flat fee.
• When a CCV does charge, the flat fee is paid in feeToken.
• CCV getFee() also returns gasForVerification and payloadSizeBytes, which feed into the executor execution gas estimate above (not billed separately).

Example: FTF transfers of USDC may route through the CCTP Verifier, and CCTP can deduct its own fee from the transferred USDC.

Token Pool Fee

Token issuers may configure fees for transferring their tokens across chains.

These fees may vary based on:

• Source/destination chain
• Finality configuration (for example, FTF vs full finality)

Token pool fees can be:

• USD-denominated and paid in the feeToken
• A percentage (bps) deducted from the transferred amount

CCIP Fee

The CCIP Fee is a protocol-level fee charged for using the CCIP system.

This fee compensates the infrastructure and services involved in message delivery.

Fee Tokens

CCIP supports fee payments in LINK and in alternative assets, including blockchain-native gas tokens and their ERC-20 wrapped versions. The payment model for CCIP is designed to reduce friction for users and scale CCIP to more blockchains by supporting fee payments that originate on many blockchains.

Fees collected in the feeToken are incremental to the amount being transferred.

Example: If the fee is $0.50 and the transfer is $100, the user pays $100.50 and receives $100.

You can see the fee tokens available for any chain:

• In the CCIP Directory
• By using the getFeeTokens() method of the CCIP SDK

Fee Quotation and Payment

Fees are calculated and paid at message submission (ccipSend()).

Developers can estimate fees before sending a message using:

• getFee(): returns total estimated fee
• A V2 token pool's getFee(): returns the pool's fees for a transfer, including the bps rate deducted from the transferred amount

This allows applications to preview costs and adjust parameters before execution.

Fee Breakdown and Observability

After sending a message, fee details can be observed through:

• Onchain events (for example, CCIPMessageSent)
• CCIP APIs
• CCIP Explorer

These surfaces show how fees are distributed across components.

Designing for Cost Efficiency

Cost-efficient CCIP applications use the least expensive message configuration that still meets their security and execution requirements. The fee quote reflects the complete message, so decisions about payload size, destination gas, token transfers, finality, CCVs, and execution all affect the cost.

Set a realistic destination gas limit

The gasLimit in extraArgs is priced as part of the fee quote, and unused gas is not refunded. Estimate the gas required by ccipReceive() under realistic destination-chain conditions, then include enough headroom for legitimate variations in execution. An arbitrarily high limit increases every quote, while a limit that is too low can cause destination execution to fail and require manual execution.

Test the receiver with representative payloads and contract states instead of estimating from its simplest execution path. Keep the gas limit configurable so that you can adjust it as the receiver changes. For additional guidance, see setting gasLimit.

Keep destination execution predictable

Avoid unbounded loops, payload-dependent workloads with no enforced maximum, and unnecessary external calls or storage writes inside ccipReceive(). If the application can safely process work asynchronously, use the callback to validate and record the message, then perform nonessential work separately. This keeps the CCIP execution path smaller and reduces the chance that a state change on the destination chain makes the configured gas limit insufficient.

Keep payloads compact

Payload bytes contribute to destination execution cost. Encode only the information the receiver needs, avoid repeating values that can be derived safely, and choose compact data structures where they remain clear and auditable.

Use token transfers and callbacks only when needed

Token transfers add additional processing requirements, while a destination callback adds user-specified execution gas. Match the message type to the work the destination actually needs to perform.