> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dune.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Transaction Fees
> Understanding transaction fees and their relationship to transaction costs in blockchain networks
export const TableSample = ({tableName, tableSchema}) => <>
;
export const DuneEmbed = ({qID, vID, height = '500px'}) => <>
;
**The Dune Index has been sunset.** The underlying methodology and queries remain accessible. See the [introduction page](/data-catalog/dune-index/introduction) for details on how to continue using this data.
## Overview
Transaction fees represent the dollar costs of executing operations on blockchain networks. By measuring transaction fees, we can understand the demand for resources on the network and the incentives that drive user behavior.
Gas fee calculations are more complex than they may seem at first glance. This is because different networks have different fee structures, and some even have multiple components to their fees. We are aggregating the data from multiple sources to provide a comprehensive view of the fees paid for each network.
You can explore the daily gas fee data via `metrics.gas_fees_daily`
### EVM Networks
For EVM networks, we have developed a unified model to calculate transaction fees consistently across different types of chains. The data is accessible through the `gas.fees` table, which standardizes the fee components into `l1_fee`, `base_fee`, and `priority_fee`. This model elegantly unifies the fee structures of rollups, L1s, and L2s, providing a coherent view of gas costs across the EVM ecosystem. However, it's important to note that the specific fee components and their calculations may vary depending on the unique characteristics and design choices of each network. You can find the fee components for each network below.
Arbitrum uses a custom L1/L2 fee model that ignores priority fees (tips) in calculations and uses effective\_gas\_price instead of standard gas\_price. This helps account for the actual costs of posting data to the L1 chain.
```sql theme={null}
-- Two component fee structure
l1_fee = gas_used_for_l1 * effective_gas_price
base_fee = (gas_used - gas_used_for_l1) * effective_gas_price
```
Avalanche C-Chain uses a standard fee structure with a base fee and an optional priority fee. This allows users to tip validators for faster transaction inclusion.
```sql theme={null}
-- Two component fee structure (if priority fee exists)
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Single component fee structure (if no priority fee)
base_fee = gas_price * gas_used
```
Base employs a custom L1/L2 fee model with additional L1 data fields. This helps track the costs associated with posting data to the L1 chain for security.
```sql theme={null}
-- Three component fee structure
l1_fee = l1_fee
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Two component fee structure (if no priority fee)
l1_fee = l1_fee
base_fee = gas_price * gas_used
```
Blast uses a custom L1/L2 fee model with additional L1 data fields. This allows tracking the L1 data posting costs separately from the L2 execution fees.
```sql theme={null}
-- Three component fee structure
l1_fee = l1_fee
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Two component fee structure (if no priority fee)
l1_fee = l1_fee
base_fee = gas_price * gas_used
```
BNB Chain uses a standard fee structure with a base fee and an optional priority fee. This allows users to incentivize faster transaction processing through tips.
```sql theme={null}
-- Two component fee structure (if priority fee exists)
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Single component fee structure (if no priority fee)
base_fee = gas_price * gas_used
```
Celo is excluded due to incorrect raw data. If included, it would use a
standard fee structure with a base fee and an optional priority fee.
Ethereum uses a custom fee model with additional blob fee data. This helps
account for the costs associated with storing large data blobs on the network.
Fee components:
```sql theme={null}
-- Four component fee structure
blob_fee = blob_base_fee * blob_gas_used
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Three component fee structure (if no priority fee)
blob_fee = blob_base_fee * blob_gas_used
base_fee = gas_price * gas_used
```
Fantom uses a standard fee structure with a base fee and an optional priority fee. This allows users to tip validators for faster transaction inclusion.
```sql theme={null}
-- Two component fee structure (if priority fee exists)
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Single component fee structure (if no priority fee)
base_fee = gas_price * gas_used
```
Gnosis uses a standard fee structure with a base fee and an optional priority fee. This allows users to incentivize faster transaction processing through tips.
```sql theme={null}
-- Two component fee structure (if priority fee exists)
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Single component fee structure (if no priority fee)
base_fee = gas_price * gas_used
```
Linea uses a standard fee structure with a base fee and an optional priority fee. This allows users to tip validators for faster transaction inclusion.
```sql theme={null}
-- Two component fee structure (if priority fee exists)
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Single component fee structure (if no priority fee)
base_fee = gas_price * gas_used
```
Mantle employs a custom L1/L2 fee model with additional L1 data fields. This helps track the costs associated with posting data to the L1 chain for security.
```sql theme={null}
-- Three component fee structure
l1_fee = l1_fee
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Two component fee structure (if no priority fee)
l1_fee = l1_fee
base_fee = gas_price * gas_used
```
Optimism uses a custom L1/L2 fee model with additional L1 data fields. This allows tracking the L1 data posting costs separately from the L2 execution fees.
```sql theme={null}
-- Three component fee structure
l1_fee = l1_fee
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Two component fee structure (if no priority fee)
l1_fee = l1_fee
base_fee = gas_price * gas_used
```
Polygon uses a standard fee structure with a base fee and an optional priority fee. This allows users to incentivize faster transaction processing through tips.
```sql theme={null}
-- Two component fee structure (if priority fee exists)
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Single component fee structure (if no priority fee)
base_fee = gas_price * gas_used
```
Scroll uses a custom L1/L2 fee model with additional L1 data fields. This helps track the costs associated with posting data to the L1 chain for security.
```sql theme={null}
-- Three component fee structure
l1_fee = l1_fee
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Two component fee structure (if no priority fee)
l1_fee = l1_fee
base_fee = gas_price * gas_used
```
Sei uses a standard fee structure with a base fee and an optional priority fee. This allows users to tip validators for faster transaction inclusion.
```sql theme={null}
-- Two component fee structure (if priority fee exists)
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Single component fee structure (if no priority fee)
base_fee = gas_price * gas_used
```
{" "}
Tron uses a simplified fee structure using only gas price and gas used. This
provides a straightforward way to calculate transaction fees. Tron also
subsidizes the fees for transactions, so the fee paid is not necessarily the
actual cost of the transaction. We are correcting for this in the
`metrics.gas_fees_daily` table, but not in gas.fees yet.
```sql theme={null}
tx_fee_raw = gas_used * gas_price
```
zkEVM uses a standard fee structure with a base fee and an optional priority fee. This allows users to incentivize faster transaction processing through tips.
```sql theme={null}
-- Two component fee structure (if priority fee exists)
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Single component fee structure (if no priority fee)
base_fee = gas_price * gas_used
```
zkSync uses a simplified fee structure using only gas price and gas used. This provides a straightforward way to calculate transaction fees on the zkSync network.
```sql theme={null}
base_fee = gas_price * gas_used
```
Zora uses a custom L1/L2 fee model with additional L1 data fields. This helps track the costs associated with posting data to the L1 chain for security.
```sql theme={null}
-- Three component fee structure
l1_fee = l1_fee
base_fee = base_fee_per_gas * gas_used
priority_fee = priority_fee_per_gas * gas_used
-- Two component fee structure (if no priority fee)
l1_fee = l1_fee
base_fee = gas_price * gas_used
```
View the source code for the fees metrics implementation.
### Non-EVM Networks
For non-EVM networks we haven't yet found a consistent way to model the fee structure, so we are not yet able to provide a unified model for non-EVM networks. However, all the data is included in the `metrics.gas_fees_daily` table.
#### Solana
Solana has two "types" of transactions: *transactions* and *votes*. We track the fees for each type separately in `gas_solana.tx_fees` and `gas_solana.vote_fees`.
Solana uses a custom fee structure with a base fee and an optional prioritization fee for transactions. The base fee is calculated based on the number of signatures required for the transaction, while the prioritization fee depends on the compute unit price and compute budget limit.
```sql theme={null}
-- Two component fee structure
base_fee = # of signatures * 0.000005
priority_fee = compute_unit_price * compute_budget_limit
```
This data is standardized in `gas_solana.tx_fees`.
In Solana, votes that help the network reach consensus are also considered transactions. The fees are always 0.000005 SOL per vote, which is the base fee for a transaction with one signature.
```sql theme={null}
-- single component fee structure
fee = 0.000005
```
Vote fees are not included in `gas_solana.tx_fees` and are instead included in `gas_solana.vote_fees`.
We consider both `gas_solana.tx_fees` and `gas_solana.vote_fees` when calculating the total transaction fees for Solana in `metrics.gas_fees_daily`.
#### Bitcoin
Bitcoin uses a simple fee structure where each transaction has a fee paid to the miner. Miners pick the transactions with the highest fees to include in the next block.
```sql theme={null}
-- Single component fee structure
fee = fee
```