Transactions Fees

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.

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

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

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

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

-- 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:

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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