Liquidity providers deposit funds into Everclear and receive transfer fees from users (supply-side fees).

Everclear is a cross-chain liquidity network that enables fully non-custodial transfers between EVM-compatible chains and L2 systems. Everclear was co-founded by  Arjun Bhuptani, Rahul Sethuram, and Layne Haber and launched in 2021.

Everclear team & investors own and govern the protocol. They do not currently take a cut of the total transfer fees paid by users (revenue).

github

twitter

discord

etherscan

website

Bridges

Everclear

# Everclear Revenue Methodology

## 1. Overview

The Connext revenue metric tracks revenue generated by the Connext protocol from its bridge and AMM operations. Currently, Connext operates with a zero-revenue model where all fees collected are used to pay relayers and liquidity providers rather than being retained as protocol revenue. The metric is calculated by aggregating all fee-generating activities (bridge transactions and AMM swaps) but setting the revenue amount to zero, maintaining the infrastructure to track potential future revenue streams.

## 2. Data sources

The methodology uses blockchain event logs from Connext's smart contracts across multiple chains and external price data:

- **V1 bridge events**: Parsed `TransactionManager_TransactionPrepared_event` and `TransactionManager_TransactionFulfilled_event` logs from Arbitrum, Avalanche, BSC, Ethereum, Fantom, Gnosis, Optimism, and Polygon
- **V2 bridge events**: Parsed `ConnextDiamond_XCalled_event` logs from Ethereum, Arbitrum, Optimism, Gnosis, BSC, and Polygon  
- **AMM swap events**: Parsed `ConnextDiamond_TokenSwap_event` logs from Arbitrum, BSC, Gnosis, Optimism, and Polygon
- **AMM configuration events**: Parsed `ConnextDiamondSwapAdminFacet_SwapInitialized_event` logs for fee tier settings
- **Price feeds**: End-of-day token price feeds for USD conversion
- **Token metadata**: Token decimal information and alternative token address mappings for nextTokens

## 3. Step-by-step calculation

### Component A: V1 bridge fee calculation
- **Purpose**: Calculate potential fees from Connext V1 bridge transactions
- **Logic**: Extract bridge transactions from `TransactionPrepared_event` logs across 8 supported chains. Filter transactions through an allowlist by matching against `TransactionFulfilled_event` logs to ensure only completed transactions are counted. Handle null token addresses by mapping them to appropriate wrapped native assets (WETH on Ethereum/Arbitrum/Optimism, WXDAI on Gnosis). Apply a fixed fee tier of 0.05% to the `amount` field from transaction data. Group results by day, destination chain, and token address.
- **Key fields**: `transactionId` for transaction matching, `txData.amount` for transfer volume, `txData.receivingChainId` and `txData.sendingChainId` for chain identification, `txData.receivingAssetId` and `txData.sendingAssetId` for token addresses

### Component B: V2 Amarok bridge fee calculation  
- **Purpose**: Calculate potential fees from Connext V2 (Amarok) bridge transactions
- **Logic**: Extract bridge transactions from `XCalled_event` logs across 6 supported chains. Use domain IDs to map between Amarok's internal chain identifiers and standard chain names via a lookup table. Handle nextTokens by replacing their addresses with alternative token addresses for pricing purposes. Apply the same 0.05% fee tier to the `bridgedAmt` field which represents the fee amount. Group results by day, origin chain, and token address.
- **Key fields**: `params.originDomain` and `params.destinationDomain` for chain identification, `asset` for token address, `amount` for transfer volume, `params.bridgedAmt` for fee calculation

### Component C: AMM swap fee calculation
- **Purpose**: Calculate potential fees from AMM token swaps within Connext pools
- **Logic**: Extract swap transactions from `TokenSwap_event` logs across 5 supported chains. Match each swap to its corresponding pool configuration using the pool `key` identifier and transaction timestamp. Retrieve dynamic fee tiers (admin fee and swap fee) from `SwapInitialized_event` data, forward-filling fee rates daily to handle configuration gaps. Correct fee tier decimals by dividing by 10^10. Calculate total fees by applying both admin and swap fee tiers to the `tokensSold` amount. Group results by day, chain, and token address.
- **Key fields**: `key` for pool identification, `tokensSold` for swap volume, dynamic `adminFee` and `swapFee` rates from pool configuration

### Final aggregation
- **Combining components**: Union all three fee components (V1 bridge, V2 bridge, AMM) into a single dataset with standardized daily aggregation by chain and token
- **Currency conversion**: Convert all token amounts to USD using end-of-day price feeds, applying appropriate decimal corrections based on token metadata to handle different token precision standards
- **Time aggregation**: Group all transactions by day using timestamp truncation, ensuring consistent daily boundary handling across all chains and components
- **Final calculation**: Set revenue to zero for all records while preserving the complete fee calculation infrastructure, allowing the metric to track the total addressable revenue pool that could be captured if the protocol changed its revenue model. Apply chain availability filtering to exclude chains that are not currently supported in the data pipeline.

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

EverclearCLEAR

Revenue

Revenue

Competitive landscape

Chain breakdown