Chainlink
Build, track, and inspect Chainlink CCIP cross-chain messages — against the real CCIP API v2 and a minimal, independent on-chain read path
chainlink) exposes Chainlink's CCIP (Cross-Chain Interoperability Protocol) as workflow steps — building the ABI-encoded cross-chain message a sender contract needs, tracking a sent message's delivery status, reading Router contract state, and checking Lane/Risk Management Network health. This node does not itself hold a wallet or sign anything: message sending is delegated to the Ethereum ExecutionNode's contract-call step once this node has built the message.
Quick Start
- Add a Chainlink node to your workflow
- Set
resourcetomessageandoperationtogetStatus - Enter a
messageId(the CCIP message ID returned once a message was actually sent on-chain) - Run the workflow — the node returns the message's
executionState(UNTOUCHED/IN_PROGRESS/SUCCESS/FAILURE) plus source/destination network info
resource and
operation — plus a small set of operation-specific fields. Learn the shared pattern once on
Input & Output, and read CCIP Concepts
before using message/build or router/getFee for the first time.
Pages in This Guide
Configuration
appsettings.json, the optional CCIP API key, and RPC URLs for on-chain reads.
Networks
Ethereum, Arbitrum, Base — Router addresses and chain selectors.
Message Operations
build, getStatus, checkManualExecutionRequired, getTokenTransferRateLimit.
Router Operations
getAddress, isChainSupported, getFee, convertChainSelector.
Lane Operations
getSupportedLanes, getLatency, getRiskManagementStatus.
CCIP Concepts
EVM2AnyMessage, extraArgs versions, fee tokens, chain selectors.
Input & Output
The shared config-key pattern and how errors surface.
Examples
Worked workflow patterns using this node.
Troubleshooting
Common errors and how to fix them.
Roadmap
What was cut, what's unconfirmed, and what's explicitly out of scope.
Core Concepts
CCIP, Not Data Feeds
Chainlink ships several distinct products — Data Feeds, CCIP, VRF, Automation, Functions. This node covers only CCIP (cross-chain messaging). Data Feeds (price feeds) are out of scope for this node — they're reached via the Ethereum ExecutionNode's generic contract-call step plus the Standards Registry instead. VRF, Automation, and Functions are not implemented by any node in this codebase yet. See Roadmap.
Resources
Operations are grouped by resource, matching CCIP's own architecture:
- message — build a cross-chain message, then track its delivery status
- router — read the on-chain Router contract: addresses, chain support, fees, chain-selector conversion
- lane — CCIP lane (source→destination pair) discovery, latency, and Risk Management Network status
Two Mechanisms, One Node
Operations on this node use one of three different mechanisms — each operation's page says which:
- Local computation —
message/builddoes pure ABI encoding with no network call at all. - CCIP API v2 HTTP calls —
message/getStatus,lane/getSupportedLanes,lane/getLatency,lane/getRiskManagementStatuscallapi.ccip.chain.link/v2. - Real on-chain reads —
router/isChainSupportedandrouter/getFeemake a realeth_callagainst the Router contract via a minimal, independent Nethereum client (requires an RPC URL — see Configuration).
message/build prepares the message; actually calling ccipSend(...) on-chain is a
separate step performed by the Ethereum ExecutionNode's own contract-write operation, using the output of
message/build as its input.
Operation Summary
| Resource | Operation | Guide Page |
|---|---|---|
message | build, getStatus, checkManualExecutionRequired, getTokenTransferRateLimit | Message Operations |
router | getAddress, isChainSupported, getFee, convertChainSelector | Router Operations |
lane | getSupportedLanes, getLatency, getRiskManagementStatus | Lane Operations |