A wallet that refuses to send is usually not broken. Almost every error it shows traces back to one of three things: a counter called the nonce, the endpoint your wallet talks to, or the fee ceiling you set. Once you know which of the three is complaining, the fix is short — and in most cases it costs nothing.
What the account nonce actually is
On account-based chains, every account you send from carries a count of how many transactions it has already sent. That count is the nonce, and it starts at zero. Your first transaction uses nonce 0, your second uses nonce 1, and so on, with no gaps allowed.
The rule is strict on purpose. It fixes the order in which your transactions execute, and it makes each one impossible to replay: once nonce 4 has been confirmed, any later transaction claiming nonce 4 is rejected outright.
This is a different thing from the nonce in mining, which is a number a miner varies to search for a valid block. Same word, unrelated job. The one your wallet complains about is the account counter.
Nonce too high, nonce too low
Your wallet does not ask the network for a nonce every time you press send. It keeps its own count, and it adds the transactions it has already broadcast but not yet seen confirmed. That local count can drift away from what the chain actually recorded, and the two error messages are the two directions of that drift.
Nonce too low means the number you offered has already been used. The chain has moved past it. This is common after a transaction you thought had failed turned out to confirm.
Nonce too high means you left a gap. The network is expecting nonce 7 and your wallet offered 9, so the transaction cannot execute yet — it waits in the queue for 7 and 8 to arrive. Nothing is spent while it waits, but nothing happens either until the gap is filled — and nodes hold queued transactions only for a while, so a long gap can end with the transaction being dropped rather than executed. The usual causes are a transaction that was dropped from the mempool after your wallet had already counted it, or a wallet whose cached history no longer matches the chain.
The fix for a gap is to fill it or to forget it. Sending the missing nonce releases everything queued behind it. Clearing the wallet's cached transaction history — most wallets expose this as resetting the account — makes it re-read the count from the network and start again from the real number. Neither touches your keys or your balance; the nonce lives on the chain, not in the wallet.
Replacing a transaction instead of waiting
A pending transaction can be replaced rather than cancelled. You send a new one with the same nonce and a higher fee, and whichever version confirms first invalidates the other. Sending it to yourself for zero value is the ordinary way to cancel; sending it with the original details is the ordinary way to speed up.
The catch is that nodes do not accept an arbitrarily small increase. Each client sets its own floor — go-ethereum's default is that a replacement must beat the transaction it displaces by at least 10%; miss it and the node keeps what it already has and answers replacement transaction underpriced. Raising the fee properly — not by a token amount — is what makes the replacement stick.
Bitcoin solves the same problem differently, through replace-by-fee, which works on inputs rather than on an account counter. The idea is the same; the mechanics are not, so do not carry one wallet's steps over to the other.
When the wallet warns about the fee
Fees on modern account-based chains have two parts: a base fee the network sets and burns, and a priority fee that goes to whoever includes you. When you send, your wallet commits to a maximum it is willing to pay per unit of gas. That ceiling is where fee warnings come from.
Set the ceiling below the current base fee and the transaction cannot be included at all until the base fee falls to meet it. Set it far above, and the wallet may warn you that the worst case is much larger than the transfer is worth — you are unlikely to pay the full ceiling, but you have authorised it. Either way the warning is about the ceiling you chose, not about the amount you will probably pay. How gas is priced is worth reading once, because every one of these warnings is downstream of it.
RPC endpoints and what breaks when they fail
Your wallet does not hold a copy of the chain. It asks a node through an RPC endpoint, and everything you see — balances, history, whether a transaction went through — arrives through that connection.
So when the endpoint is down, rate-limiting you, or lagging behind the chain tip, the wallet is not wrong so much as uninformed. Balances look stale. A confirmed transaction shows as pending. A broadcast fails with a connection error even though nothing about your account is wrong.
Switching endpoints usually clears it, and it is worth knowing the one real risk: an endpoint sees every request you make, and a hostile one can show you whatever it likes. Add endpoints from sources you would trust with that, and check that the chain ID matches the network you think you are on.
| What you see | What it means | What to do |
|---|---|---|
| Nonce too low | That number is already spent | Let the wallet re-read the count; nothing is stuck |
| Nonce too high | You left a gap in the sequence | Fill the missing nonce, or reset the account's cached history |
| Replacement transaction underpriced | The bump was too small to displace the pending one | Resend the same nonce with a clearly higher fee |
| Max fee below base fee | Your ceiling is under what the network currently charges | Raise the ceiling, or wait for the base fee to fall |
| Endpoint not responding | The node you are asking is down or rate-limiting | Switch to another endpoint and verify the chain ID |
Missing transactions after importing a wallet
Restoring a wallet on a new device sometimes shows an empty history, which is alarming and almost never means what it looks like. Your funds are recorded on the chain against an address; the wallet holds only the seed phrase it derives that address from.
Three things explain most empty histories. The wallet may have derived a different address than the one you used, because the derivation path or the account index differs. The network selector may be pointing somewhere else. Or the history simply has not loaded, because the list you are looking at comes from an indexing service rather than from the chain itself.
The way to settle it is to compare the address, not the balance. Put it into a block explorer. If the explorer shows your transactions, nothing is lost and the problem is in what the wallet is displaying — a topic worth reading about in how to read a failed or missing transaction.
The bottom line
Three moving parts explain nearly every wallet transaction error: a counter that has to stay in sequence, a connection that can go stale, and a fee ceiling you set yourself. None of them involves your keys, and none of them is fixed by sending the same transaction again harder.
Read the message before you act on it. It names which of the three is complaining, and that is most of the answer. To keep learning the fundamentals, follow more from Bitbase Academy.
Related reading
Other Bitbase articles on this topic:
- Crypto Trading Fees Explained: The Costs You Actually Pay
- What Is a Crypto Transaction Fee?
- Crypto On-Ramp vs Off-Ramp: What Is the Difference?
- ETF NAV, Premium/Discount and Tracking Error
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of September 2026; refer to the latest official information.
References
[1] ethereum.org, "Transactions" ethereum.org
[2] EIP-1559: Fee market change eips.ethereum.org
[3] go-ethereum, core/txpool/legacypool/legacypool.go github.com
[4] ethereum.org, "Nodes and clients" ethereum.org






