Validators process transactions and receive fees from users (supply-side fees).

Celo is a smart contract platform for decentralized applications (a blockchain). Celo was founded by Rene Reinsberg and Marek Olszewski and launched in 2020.

CELO holders own and govern the protocol. They currently take a cut of the total transaction fees paid by users (revenue). Celo's investors include a16z, Greenfield, Electric Capital, etc.

governance

github

twitter

discord

etherscan

website

Blockchains (L2)

Celo

# Celo Average transaction fee Methodology

## 1. Overview

The Celo L1 (legacy) average transaction fee metric measures the daily average cost per transaction on the Celo L1 (legacy) network, expressed in USD. This metric is calculated by dividing the total daily transaction fees by the total daily transaction count. The calculation accounts for Celo L1 (legacy)'s unique multi-currency fee system where users can pay transaction fees in various tokens, not just the native Celo L1 (legacy) token. The methodology includes a transition point at March 26, 2025, reflecting changes in the underlying blockchain infrastructure (likely the Celo L1 (legacy) L2 transition).

## 2. Data sources

The calculation uses several key data sources:

- **Celo L1 (legacy) blockchain transaction data**: Raw transaction records from the Celo L1 (legacy) network containing transaction hashes, block timestamps, gas usage, gas prices, fee currencies, sender and receiver addresses
- **End-of-day token price feeds**: Daily closing prices for Celo L1 (legacy) and other tokens that can be used as fee currencies on the Celo L1 (legacy) network
- **Token metadata**: Decimal precision and symbol information for proper unit conversion of different fee currencies

## 3. Step-by-step calculation

### Component A: Transaction data extraction and standardization
- **Purpose**: Extract and standardize raw Celo L1 (legacy) transaction data for fee calculation
- **Logic**: Raw Celo L1 (legacy) transaction data is extracted and standardized with consistent field types and formats. The `fee_currency` field is normalized by defaulting null values to the Celo L1 (legacy) native token address (`0x471ece3750da237f93b8e339c536989b8978a438`). Gas usage is extracted as `receipt_gas_used` and gas pricing information varies based on the time period - before March 26, 2025, `receipt_effective_gas_price` is used and divided by 10^18 for proper decimal handling, while after this date, standard `gas_price` is used
- **Key fields**: `block_timestamp` for daily aggregation, `transaction_hash` for counting, `receipt_gas_used` for gas consumption, `effective_gas_price` or `gas_price` for pricing, `fee_currency` for currency identification

### Component B: Individual transaction gas fee calculation  
- **Purpose**: Calculate the gas fee for each individual transaction
- **Logic**: For transactions before March 26, 2025, gas fees are calculated by multiplying `gas_used` by `effective_gas_price` (which has already been converted to proper decimal format). For transactions on or after March 26, 2025, the calculation uses `gas_price` multiplied by `gas_used` and then divided by 1e18 for decimal adjustment. This dual methodology reflects changes in the underlying blockchain's gas pricing mechanism
- **Key fields**: `gas_fee` as the calculated fee amount, `token_address` for the fee currency, `block_timestamp` for time-based processing

### Component C: Daily fee aggregation and USD conversion
- **Purpose**: Aggregate all transaction fees by day and convert to USD
- **Logic**: Individual transaction fees are grouped by day using timestamp truncation to daily boundaries. Fees are summed by day while preserving the fee currency information. The aggregated fees are then converted to USD using end-of-day price feeds matched by token address and date. Token decimal corrections are applied during this conversion process to ensure proper unit representation. The system handles Celo L1 (legacy)'s multi-currency fee structure by converting each fee currency to USD before summing
- **Key fields**: `timestamp` for daily grouping, `fees` as the aggregated USD amount, `chain_id` and `product_id` for identification

### Component D: Daily transaction count aggregation
- **Purpose**: Count the total number of transactions per day
- **Logic**: Raw transaction data is grouped by day using timestamp truncation. Unique transaction hashes are counted using distinct count aggregation to ensure each transaction is counted exactly once. The counting includes grouping by destination address (`to_address`) and other dimensional fields for consistency with the broader metrics framework. Both pre and post March 26, 2025 transactions are processed with the same counting logic, but categorized under different product IDs (`Celo L1 (legacy)` vs `Celo L1 (legacy) L2`)
- **Key fields**: `transaction_count` as the daily count, `timestamp` for daily grouping, product classification fields for proper categorization

### Final aggregation
- **Combining components**: The daily fee totals and daily transaction counts are joined on the timestamp field to ensure matching time periods. The join ensures that only days with both fee data and transaction count data are included in the final calculation
- **Currency conversion**: All fees are converted to USD using end-of-day price feeds before aggregation, with proper decimal adjustments applied based on token metadata
- **Time aggregation**: Daily boundaries are established by truncating timestamps to day level, ensuring consistent 24-hour periods across all calculations
- **Final calculation**: The average transaction fee is calculated using safe division of total daily fees by total daily transaction count. Safe division prevents division by zero errors on days with no transactions, returning null instead of causing errors

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

CeloCELO

Average transaction fee

Average transaction fee

Competitive landscape

Chain breakdown