Portal Community
This node is CCIP-only. Chainlink Data Feeds, VRF, Automation, and Functions are separate Chainlink products and are not implemented here — see below for what each needs.

Operations Cut From the Original Design

Two operations from the original design spec were cut during implementation after a deep design review found no real CCIP API endpoint backs either:

Cut OperationWould Have DoneWhy Cut
message/getMessageByTransaction (design ID CCIP-MSG03)Look up a CCIP message by its source-chain transaction hash.No confirmed real CCIP API v2 endpoint supports this lookup.
message/listMessagesByAddress (design ID CCIP-MSG04)List CCIP messages sent by a given address.Same — no confirmed real endpoint.

If Chainlink's CCIP API adds these endpoints in the future, they would follow the same partial-class/service pattern as today's message operations.

Unconfirmed / Placeholder Data

ItemStatus
CCIP API v2 response field-name casingNot fully reconfirmed — a re-fetch during design review got a contradictory result from the same live, JS-rendered docs page. The HTTP client tries several candidate field names per value to compensate.
Router addresses beyond Ethereum mainnetRepresentative placeholders, not independently confirmed against the live CCIP Directory. See Networks.
message/getTokenTransferRateLimit's on-chain getterExact function name/ABI unconfirmed — this operation returns a prepared call descriptor, not a resolved value. See Message Operations.
Reconcile before production use beyond Ethereum mainnet. Anyone extending this node or relying on it for non-Ethereum-mainnet production traffic should independently reconfirm the CCIP API response schema and the network reference table against Chainlink's live CCIP Directory first.

Planned: Manual Execution Submission

message/checkManualExecutionRequired only reports whether a failed message is eligible for manual re-execution — it doesn't submit one. Actually performing a manual execution needs the exact authorization/calldata shape for that on-chain call, which was not confirmed during design review. This would follow the same partial-class/service pattern as today's operations once that shape is confirmed.

Out of Scope: Chainlink Data Feeds

Chainlink's price/data feeds (the "priceFeed" product most people associate with the Chainlink name) are explicitly out of scope for this node. Reading a Data Feed is a generic Ethereum contract read (the AggregatorV3Interface.latestRoundData() call) — this delegates entirely to the Ethereum ExecutionNode's generic contract-call path plus the Standards Registry rather than being reimplemented here.

Out of Scope: VRF, Automation, Functions

Chainlink VRF (verifiable randomness), Automation (upkeep scheduling), and Functions (off-chain compute) are explicitly deferred — not implemented by this node or any other node in this codebase today. Each would need its own dedicated design pass; none is planned as an extension of this CCIP-focused node.

Live CCIP Directory Integration

The per-network reference table (Networks) is a small, bundled static table today rather than a live lookup against Chainlink's own CCIP Directory/Configuration API. A future revision could source it live, removing the placeholder-data caveat above — the real CCIP Directory API's exact shape was never independently confirmed during this node's design review, which is why a static table was chosen for the initial implementation.

Want something here sooner? Track progress via the BizFirst.Ai team — reconfirming the CCIP API response schema and the live Directory data are the two most load-bearing pieces of follow-up work for this node.