LayerZero uses a decentralized network of Validator Nodes to facilitate secure and fast communication between different blockchains.

LayerZero allows users to send and receive messages between different blockchains, and to bridge tokens between different blockchains.

LayerZero is a cross-chain interoperability protocol that enables secure and fast communication between different blockchains.

twitter

etherscan

website

Interoperability

LayerZero

# LayerZero Revenue Methodology

## 1. Overview

LayerZero revenue is represented by the protocol's share of cross-chain messaging fees collected from users. However, the Protocol Fee Switch has not yet been activated by LayerZero governance, so protocol revenue is currently set to 0 across all time periods and chains. All user-paid fees (DVN fees, Executor fees, and legacy fees) are tracked to establish the foundation for revenue calculation once the Protocol Fee Switch is activated. When enabled, a portion of total cross-chain messaging fees would be captured as protocol-level revenue.

## 2. Data sources

- **Blockchain events**: `DVNFeePaid` and `ExecutorFeePaid` events from `SendUln301` and `SendUln302` contracts, plus `send` function calls from `EndpointV1` contracts, covering Ethereum, Arbitrum, Base, Polygon, and 27 other chains
- **External data**: End-of-day price feeds and asset decimal metadata for native gas assets and wrapped equivalents

## 3. Step-by-step calculation

### Component A: DVN fee collection

- **Purpose**: Fees paid to Decentralized Verifier Networks that validate cross-chain messages are captured.
- **Logic**: Fee data is extracted from parsed `DVNFeePaid` events emitted by `SendUln301` (V1) and `SendUln302` (V2) contracts across all supported blockchains. All fee elements within the `in_fees` array are unnested and summed to calculate the total DVN fee per message. Both LayerZero V1 and LayerZero V2 implementations are covered across 30 chains including Ethereum, Arbitrum, Base, Avalanche, BSC, Polygon, Optimism, and others.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for uniqueness, `fees` representing the summed DVN fee amount, `chain` identifier, and `product_id` distinguishing between LayerZero V1 and LayerZero V2

### Component B: Executor fee collection

- **Purpose**: Fees paid to Executors who deliver messages on destination chains are captured.
- **Logic**: Fee amounts are extracted from parsed `ExecutorFeePaid` events emitted by the same `SendUln301` and `SendUln302` contracts. Unlike DVN fees, executor fees are represented as single amounts rather than arrays. The same multi-chain ecosystem and version coverage as DVN fees are maintained.
- **Key fields**: `block_timestamp`, `transaction_hash`, single `fee` amount, `chain` identifier, and `product_id` for version tracking

### Component C: Legacy V1 fee calculation

- **Purpose**: Fees from the early LayerZero V1 implementation are calculated before explicit fee events were made available.
- **Logic**: `send` function calls from `EndpointV1` contracts are analyzed from before February 5, 2024, when the modern `SendUln` contracts were deployed. The message value sent with transactions is extracted, and adapter parameters are decoded to identify any airdrop amounts. The adapter parameters are represented as hex-encoded data where airdrop amounts are included starting at position 69 for version 2. Estimated fees are calculated by subtracting airdrop amounts from total message values.
- **Key fields**: `value` from transaction, `adapterparams` hex data, calculated `airdrop_native_amount` for version 2 adapters, and resulting `estimated_fee`

### Component D: Fee standardization and aggregation

- **Purpose**: Raw fee amounts are converted to a standardized decimal format and aggregated by time period.
- **Logic**: Raw fee amounts are converted to a standardized decimal format and aggregated by time period. Chain-specific asset decimal adjustments are applied using a comprehensive mapping of native assets and wrapped asset equivalents across all chains. An 18-decimal precision is utilized by most chains, but accuracy for each specific asset is ensured by the mapping. Fees are normalized by decimal precision, then aggregated daily by chain, product version, and fee type.
- **Key fields**: Standardized `fees` amounts, `token_address` for each chain's fee token, `timestamp` truncated to day level, `chain_id`, and `product_id`

### Component E: Final revenue calculation

- **Purpose**: All fee components are combined and the final protocol revenue is calculated.
- **Logic**: All three fee components (DVN, Executor, and legacy V1) are combined into a comprehensive fee dataset with daily aggregation by chain and product version. Fee amounts are converted from native asset units to USD using end-of-day price feeds and normalized by decimal precision. All fees are aggregated to daily boundaries using timestamp truncation. Despite collecting comprehensive fee data, the final revenue value is hardcoded to 0 for all records because the Protocol Fee Switch has not been activated by LayerZero governance. When activated, revenue would be calculated as a percentage of the total fee amounts collected from users.
- **Key fields**: `timestamp`, `chain_id`, `product_id`, `token_address`, and `revenue`

*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.

LayerZeroZRO

Revenue

Revenue

Competitive landscape

Chain breakdown