# Cross-Chain Interoperabilty Protocol (CCIP) Revenue Methodology

## 1. Overview

Revenue measures the value retained by Chainlink through the operation of the Cross-Chain Interoperabilty Protocol (CCIP). This metric captures fees paid by users for secure cross-chain messaging and asset transfers, as well as protocol-level payments directed from the payment aggregator to the Chainlink reserve and staking reward contracts. These figures represent the gross income generated by the interoperability infrastructure before accounting for operational costs or node operator incentives.

## 2. Data sources

- **Blockchain events**: `CCIPSendRequested` events from `EVM2EVMOnRamp` contracts and `OnRampSet` events from `Router` contracts, covering Ethereum, Arbitrum, Avalanche, Polygon, Monad, and 3 other chains
- **Blockchain events**: ERC-20 `Transfer` events for the LINK asset on Ethereum
- **External data**: End-of-day price feeds for fee assets and asset metadata for decimal normalization

## 3. Step-by-step calculation

### Component A: Cross-Chain Interoperabilty Protocol (CCIP) fee extraction

- **Purpose**: Captures the fees paid by users for initiating cross-chain requests.
- **Logic**: Fees are extracted from `CCIPSendRequested` events emitted by various versions of the `EVM2EVMOnRamp` contracts (including V1, V2, and PreLaunch versions). The `feeToken` and `feeTokenAmount` fields are parsed to identify the payment asset and the quantity paid for each request. Requests that have been removed due to chain reorganizations are excluded from the aggregation.
- **Key fields**: `feeToken`, `feeTokenAmount`, `block_timestamp`

### Component B: Payment aggregator revenue tracking

- **Purpose**: Identifies protocol-level revenue distributed to reserves and staking rewards.
- **Logic**: ERC-20 `Transfer` events for the LINK asset on Ethereum are filtered. Transfers are included if the sender is the payment aggregator and the recipient is either the Chainlink reserve address or the staking rewards address. This represents the flow of accumulated fees into the protocol's core treasury and incentive modules.
- **Key fields**: `from_address`, `to_address`, `value`, `token_address`

### Component C: Route identification and mapping

- **Purpose**: Maps transaction events to specific cross-chain routes for dimensional reporting.
- **Logic**: On-ramp addresses are mapped to destination chains by parsing `OnRampSet` events from `Router` contracts. This mapping is used to associate each fee event with a specific cross-chain route (source chain to destination chain). If a destination chain selector is not recognized, the route is classified as a generic category.
- **Key fields**: `onRamp`, `destChainSelector`, `account_address`

### Component D: Normalization and USD conversion

- **Purpose**: Standardizes all collected revenue into a common currency (USD).
- **Logic**: Raw fee amounts are normalized by the decimal precision of the respective payment assets. Normalized amounts are multiplied by end-of-day price feeds. For specific chains where price feeds may be unavailable for the LINK asset, prices are referenced from the Ethereum mainnet. All values are aggregated to daily totals using UTC day boundaries.
- **Key fields**: `timestamp`, `revenue`, `token_address`, `price_usd`

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

Revenue

Infrastructure

In order to bring determinism to the oracle layer, Chainlink has developed a network of decentralized oracle networks (DONs), with each DON involving a combination of multiple security techniques needed to service a particular use case.
The Chainlink stack supports multiple open standards for designing and operating oracle services, which currently span four key verticals: 1) Data, 2) Interoperability, 3) Compliance, and 4) Privacy. Built upon these standards exists an ever-expanding collection of modular, purpose-built oracle services, which can be easily created and seamlessly composed using the Chainlink Runtime Environment (CRE). CRE is a developer platform and decentralized execution environment for running, managing, and composing oracle services into scalable end-to-end solutions, which run in a highly secure, reliable, and cryptographically verifiable manner.

Chainlink is the industry-standard oracle platform bringing the capital markets onchain and powering the majority of decentralized finance (DeFi). The Chainlink stack provides the essential data, interoperability, compliance, and privacy standards needed to power advanced blockchain use cases for institutional tokenized assets, lending, payments, stablecoins, and more. Since inventing decentralized oracle networks, Chainlink has enabled tens of trillions in transaction value and now secures the vast majority of DeFi. 
Many of the world’s largest financial services institutions have also adopted Chainlink’s standards and infrastructure, including Swift, Euroclear, Mastercard, Fidelity International, UBS, ANZ, and top protocols such as Aave, GMX, Lido, and many others. Chainlink leverages a novel fee model where offchain and onchain revenue from enterprise adoption is converted to LINK tokens and stored in a strategic Chainlink Reserve. Learn more at chain.link.

Chainlink is not a governance protocol. Chainlink is an open-sourced platform of standards developers leverage to build next-generation onchain applications. It is developed and maintained by Chainlink Labs and a broader community of contributors. While there is no onchain token-based governance like in some DeFi protocols, the direction of the protocol is guided by core developers, researchers, and ecosystem partners, with feedback from the community.

Cross-Chain Interoperabilty Protocol (CCIP)

Revenue

Revenue

Chain breakdown