Transactions and Transaction Costs
A transaction is any action that updates the state of the blockchain. There are costs associated with each transaction that cover the computational cost of processing that transaction. These costs are variable and dependent on several factors, which are discussed below.
This page covers the basic functionality of transactions, how their associated costs are calculated, and where to see transaction data from the Energy Web Chain and Volta Testnet. If you want to read more about the fundamentals of transactions, see the Ethereum documentation on transactions, blocks, and gas,
A transaction is any ‘write’ operation that changes or updates the state of the blockchain. Transactions are always initiated by an externally owned account, and they must be signed by the account owner that initiated the transaction in order to be completed. Examples of write transactions include:
- Transferring tokens between accounts
- Deploying new smart contracts or accounts
- Calling or Interacting with existing smart contracts
Once confirmed by the initiator, transactions can be in two states: pending and validated.
In a Proof-of-Authority consensus blockchain, validators take turn validating transactions and sealing blocks. Before a transaction is validated, it is in a "pending" state in the memory pool ("mempool"). The following image shows a transaction in a "pending" state. You can view all pending transactions on the Energy Web Block Explorer here.
Notice that the transaction fee of a pending transaction is not determined yet and the "Block Number" is pending.
Transaction in pending state - from Energy Web Block Explorer
After a transaction is validated by a validator, it is added to a block. The block is designated by a block number, shown in the image below. Each block in a blockchain is made up of strictly ordered, consecutive, validated transactions.
The following image is a transaction in a "validated" state. You can view all validated transactions on the Energy Web Block Explorer here.
Notice that the transaction fee of a validated transaction is no longer 0, it has a value in EWT.
Every transaction that updates the chain has a transaction cost (transactions that are "read only" - meaning they do not update the state of the blockchain - do not have a cost.) It’s important to keep in mind that all transactions are not created equal: some are more computationally intensive than others, some are more urgent, some require greater degrees of privacy.
For example, an interaction with a smart contract that has complex functionality and many internal variables to store will be more computationally intensive than a simple transfer of tokens from one account to another.
As we’ll soon see, these differences from one transaction to the next can have an impact on ultimate transaction cost.
A transaction’s computational complexity is measured in gas, a unit that assigns a numeric value to each operational code, or instruction, that will be executed to complete the transaction. The gas cost of a transaction is determined by the amount and sophistication of code that needs to be executed as well as the amount and type of data that will be stored on the blockchain as a result. The more complex the transaction, the higher the gas cost.
To derive a concrete fee requires a gas price as well. Every user that initiates a transaction chooses a gas price they are willing to pay for that particular transaction, at that particular time. It is essentially a bid the user makes to have their transaction validated and added to the chain. Users that want to have their transaction expedited, for example, might bid a higher gas price to ensure that it’s included as soon as possible in the next available block.
Gas price is on the EW Chain is denominated in EWT (usually in minuscule units like gwei, which represent one billionth of an EWT). The price is expressed in tokens (gwei) per unit of gas.
You can specify a gas price in a transaction through MetaMask:
Gas price of .01 Gwei.
Finally, token value—usually expressed in a fiat currency equivalent—translates virtual transaction cost into ‘real’ transaction cost. And when token value varies widely, perhaps due to token market volatility, resulting transaction costs can vary too.
Using the three variables above, you can calculate the total transaction cost:
TxCost(unit:fiat$) = GasCost(unit:gas) x gasprice(unit:token/gas) x tokenvalue($/token)
Here’s how a fee would be calculated for a hypothetical transaction on the Energy Web Chain:
50,000 gas x 1 gwei per gas = 50,000 gwei = 0.00005 EWT
If the market price of EWT was $1 at the time of the transaction, this would equate to $0.00005 fee. If the price of EWT was $10, this would equate to $0.0005.
To ensure that block time remains consistent and to prevent any given block from being overloaded with transactions, the EW Chain has a predefined limit to the amount of gas that can be consumed in each block. Each block on the Energy Web Chain has a size limit of 8 million units of gas.
Gas cost, as we've mentioned, represents the computational effort that validators undertake when validating transactions and sealing blocks. The gas price is denominated in EWT, which is paid to the validators for their work.
Each validator may set their own minimum gas price that they are willing to accept in order to include a transaction in their blocks. Currently on the EWC, the default is 0.1 gwei, but the overall range is between 0.01 gwei and 1 gwei. When initiating a transaction on the EW Chain, you should make sure that your gas price is at least 0.01 gwei, and if you want to ensure that your transaction is executed within the next 1-3 blocks (roughly 15 seconds), you should choose a higher gas price.
Because each transaction uses different amounts of gas, the number of transactions that fit on a block will vary.
Each block on the Energy Web Chain has a size limit of 8 million units of gas. Hypothetically, a single extremely computationally intensive transaction could consume 8M gas, but a simple transfer of EWT between two accounts (the most basic transaction type there is) consumes 21,000 gas. This is why a simple metric of “transactions per second” is misleading; not all transactions are created equal in terms of complexity (i.e. gas cost.) If many of the transactions that are waiting in the memory pool have low computational cost, you can fit more transactions in the block. If they are larger, the block will hold less transactions.
Take a look at the details of a block added to the Energy Web Chain:
Block Details of a Single Block on the Energy Web Chain
From this we can see that:
- This block includes 43 transactions
- The gas limit for the block is 8,000,000 (this limit remains constant for every block)
- Only 1,553,623 units of gas were used to create the block (less than 20% of its limit)
- If there were more transactions waiting in the memory pool to be added to the block, this block could have processed ~6,446,377 units worth of gas.
You can see all block and transaction details for the Energy Web production chain at https://explorer.energyweb.org/.
You can see all block and transaction details for the Volta Testnet at https://volta-explorer.energyweb.org/.
The same three variables above that define transaction cost also present opportunities to manage those costs and keep them low.
1. Lean smart contracts can help keep gas costs down: App developers and other smart contract writers are incentivized to write lean, efficient code—writing smart contracts and initiating transactions that are as computationally efficient as possible.
2. Gas price bids should remain low on networks with high transaction capacity: Of the three variables that contribute to transaction costs, gas prices are arguably the most powerful lever, since the bidded prices are solely at the discretion of the user submitting a transaction to the network. For reasons we’ll explore below, in the absence of sustained block “congestion”, gas prices can remain low and stable.
3. “Just in time” gas price calculations mitigate some risks of token value volatility: For a variety of reasons, some token markets are more volatile than others. But just because a token’s value relative to a fiat currency changes, it doesn’t mean that transaction fees similarly change without warning. Users calibrate gas price bids at the time of the transaction, and thus will bid a denomination of tokens relative to the token’s value at the time. While it is possible that a past transaction fee could end up being significantly more or less expensive relative to current (or future) token value, transaction fees at the time they are incurred should remain relatively stable as a function of fiat currency.
So why would anyone bid a high price for any transaction? Shouldn’t transaction fees remain very low, as rational users consistently attempt to minimize their costs? In reality, transaction fees vary precisely because of competition among users to get transactions confirmed.
At any given moment there may be hundreds or thousands of transactions waiting to be confirmed and formally added to the blockchain. These pending transactions sit in a memory pool, or "mempool", where they are ultimately selected by validators (miners in the case of proof-of-work blockchains) to be included in a block. But each block has a finite gas limit, meaning not all transactions can be confirmed at once. As a result, validators will typically give preference to the most-lucrative (or expensive, depending on perspective) transactions in the mempool. Transactions with lower fees may end up having to wait for their transaction to get confirmed.
Ultimately, fees are about transaction prioritization. The higher the gas price you pay, the faster your transaction will be confirmed. If you don’t care about the amount of time it takes to confirm your transaction, you can offer a very low (or no) gas price. However, with this strategy you run the risk that your transaction never gets confirmed, and just sits in the mempool queue indefinitely.
At the most basic level, transaction fees on the EWC are determined as a function of supply (e.g., computational capacity of the network, as defined by block gas limit and block speed / time) and demand (i.e., number of pending transactions). Volatility comes into the equation because supply, namely block time and block gas limit, is essentially fixed, whereas demand fluctuates as a function of the number of users and and the volume and complexity of transactions in the memory pool at any given time. Occasionally, transaction fee trends diverge from transaction volume, but generally the two are correlated.
Looking at historical data since the launch of the EWC in June 2019, it’s fair to say that transaction fees are usually extremely low - with average block utilization (in terms of gas consumption) around 15-20% the minimum gas price of 0.1 gwei is almost always sufficient to ensure a transaction is validated within 2 blocks. Based on the historical market price of EWT, transaction fees expressed in terms of fiat currency are typically in the range of $0.0001 (or less).