What Does CCIP Carry—and What Does It Not Do?
Chainlink’s architecture documentation distinguishes tokens, data and combinations of the two. A token-only transfer delivers the asset without calling the recipient’s application logic. A message-only transfer carries information to a receiving smart contract—software running on the destination blockchain. A programmable token transfer combines the asset with information for that contract to process.
For tokens, contracts called token pools handle the asset-specific work: locking or burning tokens at the source, then releasing or minting them at the destination. “Burning” removes tokens from circulation; “minting” creates them. Which mechanism applies depends on the token’s configuration. These issuer-owned pools are external to CCIP itself.
Chainlink’s general-availability announcement describes price data as a complementary service: Data Feeds or Data Streams can supply asset prices, while CCIP enables cross-chain connectivity. An application can use both, but evidence that it uses Chainlink prices does not by itself establish a CCIP integration.
For example, The Defiant’s Polymarket metals report explains how gold and silver price streams determine betting outcomes. Its 24/7 pricing report concerns price updates outside traditional market hours. Those are pricing stories, not explanations of cross-chain token delivery.
How Does a Message Get From Ethereum to Base?
A lane is a configured, directional route from a source blockchain to a destination blockchain. Ethereum → Base provides a documented example: The Defiant’s Sept. 28, 2026 upgrade report recorded that outbound route at version 2.0.0.
Consider a message-only transfer along that route. Under Chainlink’s CCIP 2.0 message lifecycle, it passes through these stages:
- Ethereum records the request. The application sends through CCIP’s Router, its entry-point contract. The source-side contracts check support, collect the fee and record a message with a unique identifier. If tokens accompany the message, the appropriate pool locks or burns them at this stage.
- Verifiers attest to the source action. They watch the source blockchain, wait for the required level of finality and produce signed proofs tied to the message. Chainlink documents a default Committee Verifier network of 16 independent node operators; additional verifiers can be required by the configuration.
- Proofs become available for delivery. An optional indexing service collects verifier attestations in one place. Delivery services can also obtain them directly from verifiers. An executor is the party that pays destination-chain transaction costs to submit the message and proofs; Chainlink supplies the default automated service.
- Base checks and executes. Destination-side contracts check the message’s origin and required verifier proofs before delivering its data through the Router to the receiving contract. A successful execution is recorded against the message identifier and cannot be repeated. A failed execution can be retried.
For a token-only transfer, the last stage releases or mints tokens without an application callback. For tokens plus a message, destination execution also calls the receiving application. If that call reverts—rejects the operation—the execution attempt fails as a whole, so tokens are not successfully delivered in that attempt.
Support is therefore more specific than a blockchain appearing on a network list. A token needs the appropriate pools and route configuration. A route’s protocol version, a token pool’s version and an application’s enabled features are separate facts; a CCIP 2.0 route does not automatically give every existing pool the new options.
What Determines the Wait and the Fee?
Finality is the assurance that a blockchain’s recorded transactions are extremely difficult or impossible to reverse. CCIP 2.0 waits for full source-chain finality by default, including for existing integrations, according to its finality documentation.
Faster-than-finality delivery is an explicit opt-in, not a blanket speed upgrade. The sender, relevant token pool, verifiers, executor and receiving application must permit the requested mode where applicable. Legacy pools and receivers cannot opt into it. Shorter confirmation waits accept the risk of a source-chain reorganization: blocks can be replaced after destination execution, potentially causing duplicate execution, unbacked tokens or losses.
The source confirmation wait is only part of the journey. Proof availability and destination execution still have to follow; it is not an end-to-end delivery guarantee.
Under the 2.0 fee model, the quote can include destination execution costs, verifier charges, token-pool charges and a protocol fee. The amount depends on the route, destination gas prices, message size, execution budget and selected verification and finality settings. A published protocol fee alone is not the total transfer cost.
Fees can be paid in LINK or supported alternatives, including native gas tokens. An issuer may also configure a pool charge deducted from the tokens being transferred. The destination application’s gas budget—the allowance for computational work—is priced into the quote: too little can cause failure, while unused budget is not refunded.
What If Destination Execution Fails?
Chainlink’s manual-execution documentation separates a message that has not executed from one whose execution was attempted and failed. Missing verifier data or an executor that has stopped retrying can leave a message awaiting its first destination execution. Insufficient gas, receiving-contract logic, token handling or rate limits can cause execution to fail.
A retry is not an automatic cure. The underlying condition must be resolved, and the required attestations must be available. In CCIP 2.0, anyone can submit an eligible message for destination execution; the caller need not be the original sender. That caller pays destination gas. Even a successful outer transaction receipt can contain a failed CCIP execution result, so the message’s execution state matters.
The trust limits extend beyond delivery. Chainlink’s shared-responsibility documentation leaves application correctness, token configuration, blockchain behavior and monitoring with the relevant developers and operators. Issuer policies or insufficient pool liquidity can stall a transfer. The protocol also has an onchain emergency-stop mechanism that can block affected sends and executions. Verification does not remove those dependencies or guarantee that the receiving application is safe.
A Reading Path Through the Rollout, Transporter and Upgrade
These reports cover different layers of the same system. Their launch conditions are historical snapshots, not a current support list.
- April 11, 2024 — the interface: Transporter launches. Read this for the user-facing bridging application. Chainlink’s launch announcement distinguishes Transporter, a frontend, from CCIP, the underlying infrastructure.
- April 24, 2024 — developer access: The permissionless rollout, reported by The Defiant on April 25. General availability opened access for developers to transfer onboarded tokens and send messages; it did not mean every token was supported everywhere.
- Sept. 28, 2026 — configurable verification and settlement: CCIP 2.0 launches. Read this for optional verifiers, finality choices and pool-level controls. Existing integrations retain full-finality defaults; using new pool controls requires an upgrade.
For broader background, What Is Chainlink? introduces its oracle role. For this guide’s changing operational details, the reference points are the CCIP Directory and architecture documentation: support belongs to a particular route and token configuration, while completion belongs to the destination execution result.