Blockchain technology gives users the freedom to transact in ways they’ve never been able to before. Rather than the rigid transactions expected in the formal financial world, Web3 offers users access to programmable transactions through smart contracts.
However, Web3 also introduces a host of complications and uncertainties to the transaction lifecycle. At every step of the Web3 transaction lifecycle, there is the potential for the transaction to go sideways, resulting in stuck, dropped, or failed transactions. These risks begin with creating a transaction and setting the gas price and continue until the transaction is confirmed on-chain. Users new to Decentralized Finance (DeFi) will not be accustomed to these errors.
To reduce user friction, a successful Dapp or wallet needs to make the different steps in the transaction lifecycle as transparent and accurate as possible. This will allow users to accurately compose their transaction and monitor its progress through the mempool to detect any potential issues before it is finalized. Successful transaction orchestration results in a growing user base for both the Web3 project and the crypto ecosystem as a whole as decentralized finance becomes more user-friendly. Moreover, reducing the number of stuck, dropped, or failed transactions will generally increase the metrics you care about, including Volume or TVL for your protocol.
Components of an Ethereum transaction
To best understand common transactions errors on Ethereum, you first need to understand the different components that comprise a transaction. These components directly impact the probability of the transaction being confirmed rapidly or not.
All Ethereum transactions will contain the following:
nonce: the transaction nonce dictates the order in which the transactions from a given account (ethereum address) need to be executed. Every account starts with a nonce of 0 and increases by 1 each time a user sends a transaction. Crucially, when you have multiple pending transactions, they are confirmed in the order of their nonce. If a lower nonce transaction gets stuck or dropped, your higher nonce transactions cannot confirm.
baseFee (type2 transactions): this gas fee is determined by the network itself. Depending on how full the new block is, the Base Fee is automatically increased or decreased.
MaxPriorityFee (type2 transactions): also known as the miner tip, this fee is determined by the user and is paid directly to miners. Blocknative provides industry-leading PriorityFee estimations available on our Browser Extension.
MaxFeePerGas (type2 transactions): the absolute maximum you are willing to pay per unit of gas to get the transaction included in a block. Any leftover gas will be refunded to your wallet.
gasLimit: Maximum amount of gas the transaction is authorized to consume.
to: The address to which you are directing the transaction.
value: Total ETH you want to send. Note that this field is for ETH only; ERC-20 or NFT transaction amounts don’t count towards the value field.
10 Common Ethereum Transaction Errors
The most common Ethereum transaction errors are:
The ErrAlreadyKnown transaction error occurs when users try to re-submit a transaction that was previously submitted and now resides in the mempool.
If you received “ErrAlreadyKnown,” you generally won’t need to do anything. If you made a mistake in the original transaction, you may wish to submit a replacement (i.e. a “speedup” or “cancel” transaction).
The ErrInvalidSender transaction error occurs when the signature from the address from which you are sending the transaction is invalid.
To fix the ErrInvalidSender error, sign the transaction from the correct address and try submitting the transaction again.
3. & 4. ErrNonceTooLow & ErrNonceTooHigh
ErrNonceTooLow and ErrNonceTooHigh are deceptively straightforward.
On the surface, ErrNonceTooLow occurs when the nonce value is less than or equal to the corresponding value of your last submitted transaction.
ErrNonceTooHigh, on the other hand, occurs when the Ethereum node detects a “nonce gap”, meaning it detected a transaction with a nonce that is greater than the nonce of your previous transaction plus 1.
Recall that the nonce is an integer associated with each address, which increases monotonically with each transaction submitted from that address. Thus, NonceTooLow and NonceTooHigh respectively point to insufficient and excessive nonce-increments.
But what exactly do we mean by “insufficient” and “excessive” here? Insufficient and excessive relative to what? This is where things get hairy.
Informally, the nonce increment is validated against the last transaction originating from a given address that is known by the Ethereum node that is processing the new transaction. That sentence is somewhat of a mouthful, so let us introduce some simple notation to help keep track of things.
Let’s refer to the most recent transaction you have submitted t, and let’s refer to the transaction you are currently submitting as t’. Because you are a sensible person, you have taken care to increment the nonce for t’, so nonce(t’) = nonce(t) + 1. But much to your dismay, the Ethereum node to which you submit t’ responds with ErrNonceTooHigh. What happened?
Blockchains are eventually consistent systems, and this has two important consequences. At the consensus level, a given Ethereum node may be looking at stale or invalid chain states at any given time.
Therefore, even if t is technically “on-chain”, some nodes may not observe t for some time, perhaps even several seconds. At the pre-consensus level – i.e., in the mempool – the situation is even worse; there are no consistency guarantees whatsoever, eventual or otherwise.
As such, even a correct transaction can produce ErrNonceTooHigh if t’ was submitted to a node other than the one that processed t . Similarly, NonceTooLow can fail to occur when transactions are spread across different nodes, depending on how they propagate.
The failure modes that produce ErrNonceTooHigh and ErrNonceTooLow are manifold and warrant an in-depth analysis in a separate article.
In practice, though, it’s not always obvious what to do about them. ErrNonceTooLow can usually be remedied by incrementing the nonce (though, beware of the nonce-gap!).
ErrNonceTooHigh, on the other hand, is more ambiguous. It frequently resolves on its own, as transactions propagate through the network, but may also require decrementing the nonce. Blocknative’s Mempool Explorer and Simulation Platform can help you diagnose the issue.
ErrUnderpriced occurs when a transaction's gas price is below the minimum amount that the node has been configured to accept.
To fix this error, increase the gas price for the transaction and try again. One small caveat: to avoid denial-of-service due to bidding wars, the Ethereum nodes require such “replacement transactions” to increase the gas price by a minimum amount, typically 10%.
ErrReplaceUnderpriced occurs when a user tries to replace or cancel a transaction and the amount of gas is not higher than the original transaction. If the replacement transaction’s gas is lower than the original transaction, the new transaction will not replace the original transaction.
To resolve ErrReplaceUnderpriced, increase the gas price or MaxPriorityFee of the replacement transaction, such that their aggregate value exceeds that of the original transaction by the minimum increment, typically 10%.
The ErrInsufficientFunds error is a common Ethereum transaction failure that occurs when the sending wallet does not have enough funds (ETH) to cover the maximum gas the transaction can consume plus any ETH funds directly sent in the transaction.
To fix ErrInsufficientFunds, either add more funds to the wallet, or lower the gas settings and/or value transferred until the transaction fits within the wallet’s available funds.
Before a smart contract can be executed on Ethereum, there is a fixed cost—known as the intrinsic gas—that must be paid. This cost is calculated dynamically and depends on both the transaction type and the number of bytes in the transaction payload. If the gas limit is less than the intrinsic fee, miners will reject the transaction.
To fix an ErrIntrinsicGas error, increase the transaction gas limit and submit the transaction again.
The ErrNegativeValue error occurs when trying to send a negative amount of funds. Need we say more?
ErrOversizedData occurs when the size of input data results in a transaction whose total size is above 128KB. This transaction failure is not caused by a consensus error but is implemented as a measure to protect the network against Denial-of-Service (DoS) attacks.
To fix the ErrOversizedData error, reduce the size of your input and ensure the transaction’s total size does not exceed 128KB.
Do I get my ETH back from a failed transaction?
If a transaction fails, the ETH in the value field of the transaction will remain available to the originator, and will not be sent or consumed
Do I get my gas back from a failed transaction?
Each operation executed by the Ethereum Virtual Machine (EVM) consumes some amount of gas. Despite a transaction failing, computational power was still used to make this determination, so you will still pay some gas for a failing result.
However, miners are only paid for the actual gas consumed by a transaction and any unused gas is refunded to the originator. We highly recommend simulating your transactions using Transaction Preview before submitting them to the network in order to avoid on-chain failures that cost gas.
Nonce Gaps and Transaction Errors
For an Ethereum transaction to be confirmed, its nonce value must be one more than the nonce value of the last confirmed transaction for the given account. For example, if the last confirmed transaction in an account had a nonce value of 3, a transaction with a nonce value of 5 cannot be accepted until a transaction with a nonce value of 4 is confirmed.
As a result of this feature, when transactions are dropped from the mempool new transactions from a given account cannot be processed until the original nonce gap has been resolved. As the Ethereum network becomes increasingly more congested, dropped transactions are becoming more common.
This is because times of extreme network congestion can lead to underpriced transactions being dropped from mempools. Since the dropped transactions are unable to get back into the mempool by themselves, they cannot span the transaction nonce gap, preventing wallets from completing new transactions until the nonce gap has been resolved.
How to Fix Nonce Gaps
To fix errors resulting from dropped transactions and nonce gaps, users should:
- Identify the first missing transaction in the nonce gap.
- Send a replacement transaction with the same nonce value (and enough gas to prevent it from getting stuck).
- Monitor the replacement transaction as it moves through the mempool.
- Repeat steps 1-4 until all stuck transactions have been replaced and confirmed on-chain.
Utilize Mempool Data for Measurable Results
Transaction errors result in lost gas fees, missed trades, and general confusion. Preventing failed transactions is one of the most frustrating challenges users face when interacting with Web3.
To grow your active users and succeed in this competitive industry, integrating mempool data and transaction monitoring APIs is one of the most important blockchain developer tools you can add to your Web3 tech stack.
Integrating real-time mempool transaction event data streams into your engineering efforts is a straightforward and seamless process with Blocknative APIs like Mempool Explorer, Notify, and real-time gas data with the Gas Platform API. Integrating these tools into your projects can help users identify and mitigate common Ethereum transaction errors before they become systemic issues.
Blocknative's proven & powerful enterprise-grade infrastructure makes it easy for builders and traders to work with mempool data.Visit ethernow.xyz