What to Check When a DeFi Transaction Remains Pending
A troubleshooting sequence that avoids repeated signing and duplicate actions.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
A DeFi transaction that stays pending is almost never a malfunction. It means the transaction was broadcast to the network but has not been included in a block yet, and the usual cause is ordinary: the fee offered was too low for current congestion, so validators are deprioritising it while later transactions with higher fees keep moving ahead. The damaging response is the obvious one — signing the same action again — which produces a second pending transaction and, if the first one eventually lands, two executions of something you only intended once. The correct first move is to stop signing and look the transaction up.
Why it stays pending
Every transaction enters a mempool and waits to be selected for a block. Selection depends mostly on the fee offered relative to what other pending transactions are offering. When a block fills with higher-paying transactions, a transaction priced below that level waits, sometimes for a short period and sometimes much longer, depending on how the fee market moves.
Three situations produce this in practice. The first is congestion: many people are transacting, block space is scarce, and your fee is no longer competitive. The second is a fee set too low from the start, often because it was copied from an earlier transaction when the network was quiet. The third is a transaction that cannot be included because it depends on an earlier transaction of yours that is itself still pending; some actions are sequential and must be ordered.
Under Ethereum’s fee model, the base fee moves with demand, so a transaction whose fee maximum looked generous when it was created can fall behind as the base fee shifts. This is worth knowing before concluding that something is broken.
Look it up before doing anything else
The transaction hash is the identifier you need, and it is usually available from the wallet’s activity list. Pasting it into a block explorer answers the questions that matter most, and it is safe: a hash is a public value, and reading one about cannot sign anything.
The status field tells you the state. Pending or queued means the transaction is in the mempool and not yet included. Success means it executed. Reverted means it was included and failed — the gas was still consumed, but the intended effect did not occur. Dropped or unknown usually means the transaction was never propagated or has fallen below the replacement threshold.
The replacement situation is the one to check most carefully. Wallets generally support replacement: submitting the same transaction again with a higher fee can take the place of the earlier one. The risk is doing that without knowing whether the original is still live, because if both end up included you get the effect twice.
What to actually do
- Stop. Do not sign the action again. This is the single most useful step and the one most often skipped.
- Copy the transaction hash from the wallet and open it in a block explorer.
- Read the status. Pending, success or reverted determines what follows.
- If it is pending, check the offered fee against current network conditions before deciding anything.
- If you decide to replace it, use your wallet’s explicit speed-up or replace function, which reuses the same transaction hash, rather than initiating a fresh transaction from the app.
- If it reverted, find out why before retrying. A revert usually means a slippage tolerance was exceeded or a contract condition was not met, and retrying the exact same transaction will usually fail again.
- Note the transaction hash in your own records. You will need it if the platform support path requires proof.
On gas refunds and stuck approvals
One reliable fact is worth stating plainly: if a transaction reverted, the gas is gone. Ethereum does not refund gas for a failed transaction, because the computation was performed. Only a transaction that was never included costs nothing.
A common cause of apparent pending states is an approval that succeeded while the swap that depended on it never executed. Many interfaces submit two transactions in sequence, and the pair behaves as one action in the interface even though they are distinct. When the first is mined and the second is not, the wallet shows a pending item that will not resolve on its own. The fix is still the same: find the hash, read its status, and replace or retry deliberately.
When waiting is the right answer
Pending transactions do resolve. Given enough time and enough blocks, a pending transaction is eventually included and either succeeds or reverts. Replacing is appropriate when the transaction is clearly underpriced relative to current conditions and you want it resolved sooner. Waiting is appropriate when the fee looks reasonable and the action is not urgent. Deciding which case you are in requires reading the fee from an explorer, not from a general impression of how busy things seem.
The rule that prevents most of the damage is simple: an unresolved transaction is an observation to be investigated, not a prompt to click again. Every repeated signature is a fresh transaction with its own fee and its own possible execution, and only one of them is the one you intended.