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.

github

twitter

discord

etherscan

website

Interoperability

Chainlink

# chainlink Fees Methodology

## 1. Overview

Fees are measured as the total value paid in USD for using Chainlink Cross-Chain Interoperability Protocol (CCIP) services. Both direct fees paid for individual cross-chain transactions and aggregated fees collected through Chainlink's payment infrastructure are included. Insights into the economic value generated by Chainlink's interoperability services across multiple blockchain networks are provided by this metric.

## 2. Data sources

- **Blockchain events**: `CCIPSendRequested` events from `EVM2EVMOnRamp` contracts, `OnRampSet` events from `Router` contracts, and ERC-20 token transfers to the fee aggregator, covering Ethereum, Arbitrum, Avalanche, Monad, and 4 other chains
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Cross-Chain Interoperability Protocol (CCIP) transaction fees

- **Purpose**: Collection of fees paid for individual cross-chain transactions through Chainlink Cross-Chain Interoperability Protocol (CCIP)
- **Logic**: All `CCIPSendRequested` events are extracted from `EVM2EVMOnRamp` contracts across seven supported chains (Ethereum, Arbitrum, Avalanche, Base, BSC, Optimism, and Polygon). A fee asset address and fee amount charged for the cross-chain message are contained within each event. Filtering is applied for non-removed events only. Transactions are classified under the 'Interoperability' business line. The contract address is extracted as the `account_address`, the fee asset as `token_address`, and the fee amount as `fees`.
- **Key fields**: `feeToken` (asset used for payment), `feeTokenAmount` (raw fee amount), `account_address` (onramp contract)

### Component B: Cross-chain route mapping

- **Purpose**: Mapping of onramp contract addresses to their corresponding destination chains for route identification
- **Logic**: `OnRampSet` events are extracted from `Router` contracts across all supported chains and versions, including Monad. The correspondence between onramp addresses and destination chain selectors is established by these events. A mapping is created from the `onRamp` address to the `destChainSelector`. Numeric chain selectors are converted to human-readable chain names using a predefined mapping (e.g., Arbitrum: 4949039107694359620, Avalanche: 6433500567565415381, Monad: 8481857512324358265). Routes to unmapped chain selectors are labeled as 'Other'.
- **Key fields**: `onRamp` (onramp contract address), `destChainSelector` (numeric destination chain identifier)

### Component C: Enriched Cross-Chain Interoperability Protocol (CCIP) fees with routing

- **Purpose**: Combination of Cross-Chain Interoperability Protocol (CCIP) transaction fees with destination chain information to create route-specific fee data
- **Logic**: Cross-Chain Interoperability Protocol (CCIP) fees are joined with the cross-chain route mapping using the chain and account address. Route labels are created by combining the source chain and destination chain (e.g., "Ethereum - Arbitrum"). Routes to unknown destinations are labeled as 'Other'. Original fee and transaction metadata are preserved while adding the cross-chain route context.
- **Key fields**: `cross_chain_route` (formatted route label)

### Component D: Payment aggregator fees

- **Purpose**: Capture of fees collected through Chainlink's centralized payment aggregator on Ethereum
- **Logic**: ERC-20 token transfers are extracted where the recipient is Chainlink's fee aggregator contract address on Ethereum (`0xd6e39d42acee7abcc460e6ea78a0844a0980e78f`). These transfers are identified as aggregated fee payments that may not be captured in individual Cross-Chain Interoperability Protocol (CCIP) events. All aggregator fees are attributed to the Ethereum chain with no specific product categorization.
- **Key fields**: `value` (transfer amount), `token_address` (transferred asset)

### Component E: Token address normalization

- **Purpose**: Normalization of asset addresses to handle price conversion challenges for LINK assets on non-Ethereum chains
- **Logic**: Special handling is applied for LINK asset addresses since price feeds are primarily available for Ethereum LINK. Polygon LINK and BSC LINK addresses are mapped to the Ethereum LINK address for price lookup purposes. Original chain and asset address information are preserved for proper attribution while the Ethereum address is used for USD conversion.
- **Key fields**: `real_chain` (original chain), `real_token_address` (original asset)

### Component F: Final aggregation and USD conversion

- **Purpose**: Combine fee components and normalize values to USD
- **Logic**: Enriched Cross-Chain Interoperability Protocol (CCIP) fees with route information are unioned with the payment aggregator fees. Fee amounts are normalized by decimal precision and converted to USD using end-of-day price feeds. Timestamps are truncated to daily boundaries and fees are grouped by day, chain, and product categories. The standard metric finalization process is applied to validate data completeness and ensure consistent schema formatting. Fee amounts are summed for each group.

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

Total value users pay to use a protocol (gross fees, user-paid fees).

ChainlinkLINK

Fees

Fees

Competitive landscape

Chain breakdown