How to Record a Failed DeFi Transaction
What to save when a transaction fails, including status, network, hash and source notes.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
A failed transaction is not a loss event, but it is not a no-op either. It consumed a nonce, it may have cost gas, and the reason it failed is the only part of it that tells you what to do differently next time.
Recording it takes two minutes and turns a confusing moment into a usable data point.
Separate the four things that happened
When a transaction fails, four distinct things are true, and they are worth writing down separately because they have different causes:
- It was submitted. Your wallet signed and broadcast it. This is the point where gas is spent, if it is spent at all.
- It reached the network. Inclusion in a block means the network accepted it, which rules out the local connection problems that look identical from the wallet side.
- It reverted. The code ran and then undid its own changes. Your balance is unchanged, apart from fees.
- It was dropped or ran out of gas. No state change happened, and the outcome depends on whether a replacement transaction overrode it.
A failure that never reached the network and a revert look identical in a wallet interface. Separating them is the first useful thing a record does.
The five fields to capture
Write these down at the time of the failure, while the interface still shows them:
- Network and chain id. Most confusing failures are wrong-network failures, and the record is what makes that pattern visible later.
- Transaction hash. Without the hash you cannot look anything up, and a record without a hash is not a record.
- Revert reason. The decoded error string tells you which require statement failed. An undecoded raw error is still worth keeping.
- Intended action. “Swap 500 USDC for ETH on Uniswap v3,” not “the swap.” The intent is what lets you match the failure against what you were actually trying to do.
- Gas settings and deadline. The gas limit, the fee cap, and whether a deadline was set. A failure that only happens when the deadline is tight is a different problem from one that always happens.
How to read the result afterward
Look up the hash on a block explorer for the correct network. This confirms three things at once: whether it was included, whether it reverted, and what the input and output values were.
The most common causes, in rough order of frequency:
- Slippage. The quoted output could not be met. This is the expected failure when a price moves during the transaction, not a bug.
- Insufficient allowance. The contract tried to move more than the approval allows. Fix by approving, then retrying.
- Deadline expired. The transaction sat in the mempool too long and the block arrived after the expiry.
- Wrong network. The call targets a chain the contract is not deployed on.
- Reverted by protocol logic. Minimum deposit, paused state, or an invariant check. The revert reason names which one.
Two questions worth answering
Did it fail because the state changed, or because my inputs were wrong? Most repeat failures are the second kind, and those are fixed by changing the input rather than retrying.
Would you do this again the same way? If the answer is yes, the failure was environmental and will probably resolve itself. If no, the record is what stops you from repeating it.
Keep it cheap
A line per failure is enough. A spreadsheet or plain text file with the five fields above will be more useful in six months than a folder of screenshots, because a screenshot cannot be searched.
Review the log when the same operation fails twice in a row. That is the signal that the input, not the network, is the problem.
This guide is informational and does not replace the documentation of the protocol or application involved.