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 Transfer volume Methodology

## 1. Overview

Transfer volume is measured as the total USD value of assets transferred through the Chainlink Cross-Chain Interoperabilty Protocol (Cross-Chain Interoperabilty Protocol (CCIP)) on a daily basis. Economic value flowing through Chainlink's interoperability infrastructure is quantified by tracking all cross-chain asset transfers initiated via Cross-Chain Interoperabilty Protocol (Cross-Chain Interoperabilty Protocol (CCIP)) OnRamp contracts. Asset transfer amounts are aggregated from parsed blockchain events, converted to USD using end-of-day price feeds, and summed daily across all supported chains and cross-chain routes.

## 2. Data sources

- **Blockchain events**: `CCIPSendRequested` events from `EVM2EVMOnRamp` contracts, `CCIPMessageSent` events from `OnRampV3` and `OnRampCCIP2` contracts, `OnRampSet` events from `Router` contracts, and `CcipSend` from `CcipRouter` programs, covering Ethereum, Arbitrum, Avalanche, Base, and 19 other chains
- **External data**: End-of-day price feeds for assets and asset metadata for decimal normalization

## 3. Step-by-step calculation

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

- **Purpose**: The extraction of all cross-chain transfer events from the Chainlink Cross-Chain Interoperabilty Protocol (Cross-Chain Interoperabilty Protocol (CCIP))
- **Logic**: `CCIPSendRequested` events from `EVM2EVMOnRamp` contracts, `CCIPMessageSent` events from `OnRampV3` and `OnRampCCIP2` contracts, and `CcipSend` from `CcipRouter` programs are parsed across supported chains. For legacy and Cross-Chain Interoperabilty Protocol (Cross-Chain Interoperabilty Protocol (CCIP)) V1.6.0 transfers, asset transfer arrays are unnested to create individual records for each asset transferred in a transaction. For transfers using Cross-Chain Interoperabilty Protocol (Cross-Chain Interoperabilty Protocol (CCIP)) V1.6.0, asset addresses are resolved by joining the `sourcePoolAddress` from the `CCIPMessageSent` event with a dedicated mapping of token pools. For Cross-Chain Interoperabilty Protocol (Cross-Chain Interoperabilty Protocol (CCIP)) 2.0 transfers, token addresses and transfer amounts are decoded from the binary `encodedMessage` field. For legacy transfers, the token address is extracted directly from the `CCIPSendRequested` event. Reverted transactions are filtered out by including only non-removed events.
- **Key fields**: `block_timestamp` (timing), `transaction_hash`, `account_address` (OnRamp contract), `chain`, `token_address` (asset identification), and `amount` (transfer quantities)

### Component B: Cross-chain route mapping

- **Purpose**: The mapping of transfer events to their respective destination chains
- **Logic**: Destination chains are resolved based on the protocol version. For legacy Cross-Chain Interoperabilty Protocol (Cross-Chain Interoperabilty Protocol (CCIP)), `OnRampSet` events from `Router` contracts are parsed to build a mapping between OnRamp addresses and destination chain selectors. For Cross-Chain Interoperabilty Protocol (Cross-Chain Interoperabilty Protocol (CCIP)) V1.6.0 and Cross-Chain Interoperabilty Protocol (Cross-Chain Interoperabilty Protocol (CCIP)) 2.0, the destination chain selector is extracted directly from the `CCIPMessageSent` event or `CcipSend` from `CcipRouter` programs. Numeric chain selectors are translated to human-readable chain names using a lookup table. Routes that do not match known chain selectors are classified as "Other".
- **Key fields**: Chain of origin, `account_address` (OnRamp contract address), `destination_chain_selector`, and resolved destination chain name

### Component C: Transfer volume with route information

- **Purpose**: The combination of transfer events with route information to identify cross-chain flows
- **Logic**: Raw transfer events are joined with the appropriate route mapping based on the protocol version. Destination chain information is added to each transfer event. Cross-chain routes are formatted as descriptive strings combining origin and destination chains (e.g., "Ethereum - Arbitrum"). Routes to unmapped destinations are labeled as "Other".
- **Key fields**: All transfer details plus cross-chain route designation (`cross_chain_route`) and destination chain information

### Component D: Token address normalization

- **Purpose**: The standardization of asset addresses for consistent price lookups
- **Logic**: Asset address substitutions are applied to ensure price feed compatibility. LINK assets on Polygon and BSC are mapped to Ethereum LINK addresses since price feeds may not have direct coverage for these chains. Similarly, snxUSD assets on Ethereum and Optimism are mapped to their respective DAI asset addresses as price proxies. The chain identifier is temporarily changed to match the price feed chain during conversion, then restored afterward.
- **Key fields**: Adjusted asset addresses for price lookup and temporarily modified chain identifiers

### Component E: Aggregation and USD conversion

- **Purpose**: The combination of components and normalization to USD
- **Logic**: Processed transfer events are aggregated using the USD conversion and decimal correction logic, where asset decimal normalization is performed and end-of-day USD prices are applied. Asset decimal places are corrected based on asset metadata and amounts are converted to USD using end-of-day price feeds for the appropriate date. Transfer volumes are grouped by day using timestamp truncation, with daily boundaries determined by the `block_timestamp` of each transfer event. Daily transfer volumes are summed across all assets and routes, with a zero-fill strategy applied to ensure no gaps in the time series.

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

Total value of assets moved across chains through a bridge.

ChainlinkLINK

Transfer volume

Transfer volume

Competitive landscape

Chain breakdown