Fees are the virtual fuel needed to power decentralized economies. They act as strong economic incentives to ensure blockchain users behave according to the network rules.

In both Proof-of-Work and Proof-of-Stake consensus mechanisms, fees are paid by users based on their block space usage, and are redistributed to actors that guarantee the network security (miners, validators). But variations on how fees are paid, rewarded, distributed, shared and consumed are endless. 

Over the past few years, we have witnessed an incredible amount of innovation to scale and increase blockchains’ efficiency by rethinking incentive mechanisms for existing popular Layer 1 solutions like Ethereum (e.g., EIP-1559), BNB chain, Avalanche, or by designing entirely new sidechains (e.g., Polygon) and rollups like Optimism and Arbitrum to offload transaction processing off of Ethereum mainnet, increasing throughput (transaction speed) and reducing gas fees.

In this post, we will uncover fee mechanisms summarized in the table below, and walk through the process of creating new open-source datasets called Spells that anyone can query on Dune for each of the aforementioned chains, LFG!

‍

Part 1. Gas spells on Ethereum, BNB chain and Avalanche

1. Ethereum

On Ethereum and all the other EVM-compatible chains, gas is virtual fuel used to execute smart contracts, and gas fees are paid to cover the computational effort required to execute transactions.

It keeps the Ethereum network secure by preventing accidental or hostile infinite loops (e.g., DDoS attacks) that would cause computational wastage.

Gas fees are paid in Ethereum's native currency, Ether (ETH), and the maximum amount of gas a transaction may consume is defined as the gas limit. 

1.1. Pre London Upgrade and EIP-1559

Since its inception, very few changes were introduced in the fee structure of the Ethereum network. But on Aug 5th 2021, a major upgrade was implemented after the community approved the Ethereum Improvement proposal (EIP) 1559.

To construct a spell around Ethereum gas fees that’s historically accurate, we first need to understand how fees were calculated before the London Upgrade: 

Total transaction fee = Gas units used * Gas price per unit

Note that the gas price is the amount a user is willing to pay for every unit of gas required to complete a transaction, and gas refers to the unit that measures the amount of computational effort required to execute specific operations on the Ethereum network.

The amount of gas units used for a transaction cannot exceed the gas limit, otherwise, it will result in a failed transaction and lost gas fees. Before EIP-1559, the entire transaction fee would be paid to the block miner (now validator). Easy! Now how do we get that on Dune? 

Well we just query the fields we’re interested in from the ethereum.transactions table, here is an example of fields we are interested in including for ethereum gas fees before EIP-1159:

2. Post London Upgrade and EIP-1559

EIP-1559 was introduced to make gas fees more predictable, which results in a more efficient network, but it also makes the transaction fee mechanism a bit more complex than it used to be. It introduced three new variables: the base fee, the max fee, and the priority fee. 

The base fee is automatically determined by the network based on its usage of blockspace in the previous block: If the network was overutilized, which means the amount of gas used for all transactions within the last block, then the base fee can increase up to 12.5%. This mechanism ensures gas fees are more predictable, and its exponential increase based on network usage is an incentive to discourage users from saturating block space for a long time. 

Another interesting feature is that base fees (not priority fees) are burned when the block is mined, this effectively reduces ETH issuance compared to Pre EIP 1559!

EIP-1559 also introduces the priority fee, or the miner’s tip, that is entirely paid out to the validator/miner when a block is mined.

For regular transactions, a minimal tip is usually included, but most of its use is currently supported by block builders that extract value from reordering transactions within blocks.

This concept is commonly referred to as Maximum extractable value (MEV) and frequently leads to bidding wars to get the miner/validator to accept the order of transactions they propose!

Lastly, the max fee is a parameter that can be set by the user, just to make sure the sum of the base fee and the miner’s tip don’t exceed a certain amount. To sum up, Post EIP 1559, the total transaction fee looks like this:

Total transaction fee = Gas units used * (Base fee + Priority Fee)

If the max fee is higher than the total transaction fee, the difference is refunded after the transaction is executed. 

To reflect these changes on Dune, all you need to do is adapt the formula you use to compute transaction fees after the upgrade that happened on block 12,965,000 for transactions that adopted the EIP-1559.

Note that users had to upgrade their wallets to opt into post EIP 1559 type transactions. Luckily, the ‘ethereum.transactions’ table on Dune has a ‘type’ column for this: ‘Legacy’ means the transaction is using the pre EIP 1559 standard, while ‘Dynamic Fee’ means the transaction has adopted the new changes.

It’s also worth to include a couple more columns to your query, like block usage since the base fee depends on it, the amount of ETH that was burned (which is equal to the base fee), and to amount of ETH saved by the user, which is the difference between the max fee and the total fee that for a given transaction.

‍Here is an example query, in which both pre and post EIP 1559 fees for Ethereum are included. 

Now let’s cast a spell  🧙‍♂🪄

A spell is a customized open-source dataset built on Dune, so anyone can easily query Ethereum gas fees without having to do the research we just went through.

At their core, spells are SQL queries built into the spellbook github repository, so we can just take what we learned so far and write up a simple query that exposes the data we need in a user-friendly way (you can see the full code here.

The details of spell casting are out of the scope of this post, but make sure to check the documentation and the github repo for more information!

You can now find the spell for Ethereum Gas Fees here, and here is an example of how easy it is to visualize how much ETH has been burned since EIP-1559 using this query:

SELECT block_date
	, SUM(burned_native) AS burned_eth
  , SUM(SUM(burned_native)) OVER (ORDER BY block_date) AS cum_burned_eth
FROM gas_ethereum.fees
WHERE block_date >= '2021-05-05'
GROUP BY block_date

2. BNB chain

BNB chain, formerly known as the Binance Smart Chain (BSC), is an EVM-compatible layer 1 blockchain that was built to run in tandem with BNB Beacon Chain (former Binance Chain).

The mainnet was originally launched in September 2020 by the centralized exchange Binance, and gas fees are paid using its native BNB ("Build & Build") coin.

The two main differences between Ethereum and the BNB chain revolve around transaction speed/cost and decentralization. For context, the first iteration of the Binance Smart Chain was launched in the midst of DeFi summer 2020, when gas fees ramped up to all time highs on Ethereum and degens were looking for cheaper alternatives to borrow, stake and farm tokens for millions of % in APY.

The BNB chain relies on the combination of two consensus mechanisms: Proof-of-Authority (PoA), a mechanism in which a designated number of blockchain validators (21) take turns to validate transactions and produce blocks, and Delegated Proof of Stake (DPoS), meant to increase decentralization and favor community governance by allowing token holders to vote and elect the limited validator set. 

Having 21 carefully selected validators (compared to more than 400k for Ethereum as of now) allows for a more efficient network, decreases transaction fees and increases speed since the chain is designed to produce blocks every 3 seconds (versus 12 for Ethereum).

However, it does come at the cost of decentralization, the stake to be eligible for becoming a validator being very high (10k BNB ≈ $2.7mio) and at risk to be controlled by giant BNB stakeholders from Binance. This concern seems to be valid, as we saw during the very recent BNB chain hack during which the chain was just stopped and restarted at a moment's notice.

Now on to calculating BNB chain transaction fees using Dune’s data. The fee structure is very similar to Ethereum Pre EIP-1559; The total transaction fee is the result of gas units used multiplied by the gas price per unit.

However, we also have to take into account the BEP-95 proposal, implemented as part of the Bruno hard fork on November 30th, 2021, which introduces an automatic burning of 10% of fees rewarded to the validator for each block.

This comes in addition to quarterly burns scheduled by Binance, that were then replaced by an automatic protocol that burns BNB every 10 000 blocks according to this formula: 

B = N * 1000P + K

where B is the amount of BNB to burn, 
N is the total number of blocks produced on BNB Chain during the calendar quarter, 
‍P is an average price of BNB against the US dollar,
K is a constant value as a price anchor, initially set at 1000.

Note that this BNB Auto-Burn will be halted when the total circulation of BNB drops below 100 million, and that we won’t include it in our spell since it’s done on the BNB Beacon chain, which isn’t currently indexed on Dune.

Again, we created a spell specific to BNB chain gas metrics, but we also standardized gas spells across chains (Ethereum and BNB), so if we know want to compare how much gas has been burned on Ethereum and BNB chain in $USD, we can query the gas.fees spell:

SELECT block_date
	, CASE
  		WHEN native_token_symbol = 'ETH'
      	THEN SUM(SUM(burned_native)) OVER (ORDER BY block_date)
      ELSE END AS cum_burned_eth
	, CASE
  		WHEN native_token_symbol = 'BNB'
      	THEN SUM(SUM(burned_native)) OVER (ORDER BY block_date) 
      ELSE END AS cum_burned_bnb
FROM gas.fees
WHERE block_date >= '2021-05-05'
GROUP BY block_date

Adding Labels on Dune

While we’re at it and since there are only 21 known validators, why not build another spell dedicated to labeling BNB chain validators? 

Labels are a new feature on Dune, and can just be added as static SQL tables using the following syntax:

SELECT blockchain
	, address
  , name
  , category
  , contributor
  , source
  , created_at
  , updated_at
FROM (
	VALUES (
  	array('bnb'),
    lower('0x22b81f8e175ffde54d797fe11eb03f9e3bf75f1d'),
    'Validator: Aconcagua',
    'validators',
    'soispoke',
    'static',
    timestamp('2022-10-07'),
    now()
  ), (
  	array('bnb'),
    lower('0xb218c5d6af1f979ac42bc68d98a5a0d796c6ab01'),
    'Validator: Alan Turing',
    'validators',
    'soispoke',
    'static',
    timestamp('2022-10-07'),
    now()
  )
)	AS labels (
	blockchain,
  address,
  name,
  category,
  contributor,
  source,
  created_at,
  updated_at
)

Let’s turn this query into a spell that adds labels to all active validators on the BNB chain by submitting a Pull Request on Dune’s spellbook repo on Github:

🧙🧙🧙https://github.com/duneanalytics/spellbook/pull/1719 🧙🧙🧙

After this is merged, all you have to do is use the get_labels() function on Dune to get validators’ names corresponding to addresses! 

3. Avalanche

‍Avalanche is an open source platform, and its mainnet was launched in September 2020.

The Avalanche ecosystem is designed to support interoperable blockchains and dApps based on a novel consensus protocol capable of achieving low latency and a high-throughput of transactions without compromising decentralization.

In essence, the Avalanche consensus mechanism is fundamentally different from Ethereum or BNB chain. Instead of randomly choosing and assigning a single validator to verify a given block, consensus is reached by a process called “repeated sub-sampled voting”: For every transaction, validators are determining whether a transaction should be accepted or rejected by asking a small, random subset of other validators whether they think the transaction should be accepted or rejected (i.e., gossiping).

This process is repeated until a sufficiently large portion of queried validators reply the same way for consecutive rounds, meaning consensus is reached across the entire network! 

Another one of Avalanche’s key ideas is to allow anyone to use the Avalanche network and create a subnet.

A subnet is a subnetwork within the Avalanche primary network. It can be composed of one or many blockchains, has its own rules regarding membership and tokenomics but it can leverage a dynamic subset of Avalanche validators to achieve consensus.

Interestingly, a subnet can be used for private use-cases (permissioned blockchains) or public ones (permissionless). 

At its core (not including subnets), the Avalanche Primary Network is built around a system of three interoperable blockchains: the Exchange Chain (X-Chain), Contract Chain (C-Chain), and Platform Chain (P-Chain).

In this post, we’ll focus on the chain indexed by Dune, the C-Chain, Avalanche’s EVM implementation powered by the chain-optimized Avalanche consensus protocol called Snowman.

On the C-Chain, the transaction fees transitioned from a pre EIP-1559 legacy model to and post EIP-1559 one introducing dynamic fees. This was implemented on Avalanche mainnet on August 24th 2021 as part of the Apricot upgrade (phase 3). Before this transition, transaction fees were computed using the now familiar formula:

Total transaction fee = Gas units used * Gas price per unit

The Apricot upgrade introduced (1) a time-based, rolling window fee calculation: the minimum gas price any transaction must pay is calculated based on the amount of gas consumed in the last 10 seconds.

Note that the base fee can’t be lower than 25 GWei, but has no upper bound; (2) A variable fee cap for gas price (between 75 and 255 GWei), which was previously set at 225 GWei and that specifies the maximum price the transaction is willing to pay per unit of gas. This means fees can be lowered as much as 66%. 

Finally, the Avalanche network policy is to burn the total transaction fee (base fee + priority fee since the Apricot upgrade), unlike Ethereum in which only the base fee is burned. This means validators are not rewarded by fees at all, and only rely on staking rewards and fees for accepting delegations on their nodes. In the end, gas fees for DynamicFee type transactions on Avalanche can be computed as such: 

Total transaction fee = Gas units used * (Base Fee + Priority Fee)

You can find the Dune spell for the Avalanche C-Chain by clicking here, and we also have to add the gas_avalanche_c.fees to our more global gas.fees model, so we can, for example, query and visualize the daily average cost (in $USD) users are paying in transaction fees across chains using this query:

SELECT block_date
	, blockchain
  , AVG(tx_fee_usd)
FROM gas.fees
WHERE block_date > now() - interval '3 months' 
GROUP BY 1,2

‍

That’s a wrap!

I hope you enjoyed this, stay tuned for a part 2 dedicated to Layer 2 rollups on Dune ! 

Thomas Thiery / @soispoke