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 Expenses Methodology

## 1. Overview

Operational costs and expenses incurred in the provision of cross-chain messaging services are represented by LayerZero expenses. The question "What are LayerZero's operating expenses across all supported blockchains?" is answered by this metric. Currently, zero expenses are reported across all time periods and chains. Either a strategic decision to not disclose operational costs or the handling of expenses through a different accounting methodology not captured in this metric is indicated by this zero value.

## 2. Data sources

The dimensional structure of the expenses metric is established using the following data sources:

- **Blockchain events**: `DVNFeePaid` and `ExecutorFeePaid` events from `SendUln301` and `SendUln302` contracts, and `send` function calls from `EndpointV1` contracts, covering Ethereum, Arbitrum, Base, Polygon, and 26 other chains
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: DVN fee collection

- **Purpose**: Data Verification Network fees paid by users for message verification services are collected.
- **Logic**: Fee amounts are extracted from parsed `DVNFeePaid` events across LayerZero V1 and LayerZero V2 protocols on all supported chains. For events with multiple fees in arrays, the fee values are summed to calculate the total DVN fee. Block timestamp, transaction hash, chain identifier, product version (LayerZero V1 or LayerZero V2), and fee amount are included in each fee record. Records are filtered to incremental time windows for efficient processing.
- **Key fields**: `timestamp` (timing), `transaction_hash` (transaction linking), `chain` (blockchain identification), `product_id` (version tracking), `fees` (raw fee amount)

### Component B: Executor fee collection

- **Purpose**: Fees paid to executors for the execution of messages on destination chains are collected.
- **Logic**: Executor fee amounts are extracted from parsed `ExecutorFeePaid` events across LayerZero V1 and LayerZero V2 protocols. A fee paid to an executor for processing a cross-chain message is represented by each event. The same dimensional structure as DVN fees is included in these records, but executor-specific fee data is captured. Incremental processing is supported with partition-based filtering.
- **Key fields**: `timestamp` (timing), `transaction_hash` (linking), `chain` (blockchain), `product_id` (protocol version), `fees` (executor fee amount)

### Component C: V1 destination fee calculation

- **Purpose**: Destination fees for the LayerZero V1 protocol are calculated for periods before dedicated fee events were deployed.
- **Logic**: `send` function calls from `EndpointV1` contracts are analyzed to extract fees from transaction value and adapter parameters. Adapter parameter hex data is decoded to identify the version and to extract airdrop amounts when version 2 is identified. Estimated fees are calculated by subtracting airdrop amounts from the message value. Only transactions before February 5, 2024, are processed, after which explicit fee events were deployed.
- **Key fields**: `value` (total transaction value), `adapterparams` (encoded fee parameters), `airdrop_native_amount` (extracted airdrop value), `estimated_fee` (calculated destination fee)

### Component D: Fee aggregation and normalization

- **Purpose**: All fee types are combined and values are normalized across different asset decimals.
- **Logic**: DVN fees, executor fees, and LayerZero V1 fees are unioned into a single dataset. Fees are aggregated by day using timestamp truncation, with grouping by chain, product, and fee type. Chain-specific asset mappings are applied to identify the correct asset address and decimal places for each chain. Raw fee amounts are normalized by decimal precision. Comprehensive coverage is created across 30 supported blockchains.
- **Key fields**: `timestamp` (day grain), `chain_id` (blockchain), `product_id` (protocol version), `fee_type` (categorization), `token_address` (chain's native or wrapped asset), `fees` (normalized fee amount)

### Component E: Final aggregation and cost override

- **Purpose**: The final expenses metric is aggregated and overridden to zero.
- **Logic**: The dimensional structure (timestamp, chain, product, and asset) is provided by the fee aggregation, but all values are overridden by the actual expense calculation. Regardless of the underlying fee amounts collected from the blockchain events, all cost of revenue values are hardcoded to zero. No currency conversion is performed since all expense values are set to zero. Daily time boundaries are maintained from the fee structure to ensure consistent time series coverage across all chains and products. The expenses metric is set equal to the cost of revenue (zero) for all time periods, chains, and products. A fill-zeros strategy is applied by the `finalize_metric_expenses` macro to ensure complete time series coverage with no gaps, and periods when chains were not supported by LayerZero are excluded by chain availability filtering.
- **Key fields**: `timestamp` (day grain), `chain_id` (blockchain), `product_id` (protocol version), `expenses` (hardcoded to zero)

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

Total project operating and incentive expenses.

LayerZeroZRO

Expenses

Expenses

Competitive landscape

Chain breakdown