Hop allows users to send tokens from one rollup to another almost immediately without having to wait for the rollup’s challenge period. Liquidity providers deposit funds into Hop AMM pools and receive trading fees from traders (supply-side fees).

Hop is a scalable rollup-to-rollup general token bridge. Hop was co-founded by Christopher Whinfrey and launched in 2021.

HOP tokenholders own and govern the protocol. They currently take a cut of the total transfer fees paid by users (revenue). Hop’s investors include 1confirmation, Infinite Capital, etc.

governance

github

twitter

discord

etherscan

website

Bridges

Hop Protocol

# Hop Protocol Revenue Methodology

## 1. Overview

This metric measures the daily revenue generated by Hop Protocol from its cross-chain bridging service. The revenue consists of bonder fees charged to users when transferring tokens between different blockchain networks through Hop's bridge infrastructure. Bonders are liquidity providers who facilitate instant cross-chain transfers by fronting capital, and they collect fees as compensation for this service. The metric answers the business question: "How much daily revenue does Hop Protocol generate from its bridging operations?"

## 2. Data sources

The calculation uses the following raw data sources:
- **Ethereum L1 bridge contract events**: Parsed `TransferSentToL2` events from Hop Protocol's L1 bridge contracts for various tokens (USDC, DAI, ETH, USDT, WBTC, HOP, MATIC, MAGIC, RETH, SNX, SUSD)
- **Layer 2 bridge contract events**: Parsed `TransferSent` events from Hop Protocol's L2 bridge contracts across Arbitrum, Optimism, Polygon, Base, and Gnosis chains for supported tokens
- **End-of-day token price feeds**: USD price data for all supported tokens to enable revenue conversion to USD
- **Token metadata**: Decimal precision information for proper token amount normalization
- **Chain mapping data**: Reference data mapping chain IDs to chain names for cross-chain transfer tracking

## 3. Step-by-step calculation

### Component A: L1 bridge transfer extraction
- **Purpose**: Captures transfers from Ethereum mainnet to Layer 2 networks
- **Logic**: Extracts `TransferSentToL2` events from Hop Protocol's L1 bridge contracts on Ethereum. These events occur when users initiate transfers from Ethereum to supported L2 networks. Key data extracted includes block timestamp, transaction hash, bridge contract address, recipient address, target chain ID, transfer amount, and token details. For L1-to-L2 transfers, the `bonder_fee_amount` is set to zero since these transfers don't involve bonder fees - users pay only gas fees on the origin chain
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for transaction identification, `account_address` for the bridge contract, `recipient` for the destination address, `chainId` for target chain, `amount` for transfer size, and hardcoded token symbol and address mappings

### Component B: L2 bridge transfer extraction  
- **Purpose**: Captures transfers between Layer 2 networks and from L2s back to L1, which include bonder fees
- **Logic**: Extracts `TransferSent` events from Hop Protocol's L2 bridge contracts across Arbitrum, Optimism, Polygon, Base, and Gnosis. These events occur when users transfer tokens between L2 networks or from L2 back to L1. The critical difference from L1 events is the presence of the `bonderFee` field, which represents the fee charged to users for the bonder service. This fee compensates bonders who provide instant liquidity for cross-chain transfers
- **Key fields**: Same core fields as L1 transfers, plus `bonderFee` containing the actual fee amount charged to users

### Component C: Chain mapping and metadata enrichment
- **Purpose**: Standardizes chain identification and adds business context
- **Logic**: Maps numeric chain IDs to readable chain names using predefined mappings (Arbitrum=42161, Base=8453, Ethereum=1, Gnosis=100, Optimism=10, Polygon=137). Enriches each transfer record with business metadata including business line classification as 'Bridging', market sector as 'bridges', and business segment as 'mint_and_burn' to align with Token Terminal's taxonomy
- **Key fields**: `chain_id` mapped to `chain` names, plus business classification fields

### Component D: USD conversion and decimal correction
- **Purpose**: Normalizes all bonder fee amounts to USD values with correct decimal precision
- **Logic**: Takes the raw `bonder_fee_amount` values (which are in token native units) and applies two transformations. First, corrects for token decimals to convert from the smallest token unit to standard token units (e.g., wei to ETH). Second, converts to USD using end-of-day price feeds for each token. This ensures all revenue is measured consistently in USD regardless of the underlying token
- **Key fields**: `revenue` field containing USD-denominated bonder fee amounts

### Final aggregation
- **Combining components**: L1 and L2 transfer data are combined using union operations, with L1 transfers contributing zero revenue and L2 transfers contributing actual bonder fee revenue
- **Currency conversion**: All bonder fee amounts are converted to USD using end-of-day token prices and proper decimal adjustment to ensure consistent monetary measurement
- **Time aggregation**: Timestamps are truncated to daily boundaries, creating daily revenue totals aggregated across all chains and tokens
- **Final calculation**: The final daily revenue equals the sum of all USD-converted bonder fees collected from L2 bridge transfers on that day, with L1 transfers contributing zero to revenue. The fill zeros strategy ensures continuous daily time series coverage even on days with no bridge activity

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

Hop ProtocolHOP

Revenue

Revenue

Competitive landscape

Chain breakdown