Understanding the path a transaction takes explains most of the situations where something appears stuck or fails unexpectedly.
Construction and signing
The wallet builds a transaction specifying inputs or account, destination, amount, fee parameters and a sequence number.
Which is then signed locally with the private key.
Nothing has been broadcast at this point, and a signed transaction not yet sent is inert.
Broadcast and the mempool
The transaction propagates to nodes, which validate it and hold it pending inclusion.
Which is where it waits, visible to anyone watching.
Nodes apply their own policies about what to accept and how long to hold it, so mempool contents differ between them.
Fee markets
Block space is limited and allocated by fee.
Which means a transaction with an inadequate fee waits until demand falls.
Fee estimation is a prediction rather than a guarantee, and estimates degrade during volatility, which is exactly when accuracy matters.
Sequence numbers and stuck transactions
Account-based systems process transactions in order per account.
Which means one stuck transaction blocks everything behind it from the same account.
The remedy is replacing it with a higher-fee transaction using the same sequence number rather than sending another.
Replacement mechanisms
Most networks support replacing a pending transaction with a higher-fee version.
Which is how wallets implement speed-up and cancel functions.
Cancelling is generally implemented as a replacement sending nothing to yourself, which is worth understanding since it still costs a fee.
Ordering and extraction
Whoever builds a block chooses the order.
Which creates opportunities to profit from that position, extracted at the expense of ordinary transactions.
Private submission routes exist that bypass the public mempool and reduce exposure to this.
Inclusion and confirmation
Inclusion in a block is not the same as finality.
Which is why services wait for a number of confirmations proportional to value.
Chain reorganisations of one or two blocks occur naturally on some networks and are not evidence of an attack.
Failures
A transaction can be included and fail — insufficient gas, a failed condition, or slippage exceeding the limit.
Which still costs the fee, since the work was performed.
Reading the failure reason on a block explorer generally identifies the cause precisely.
Fee mechanisms
Some networks use a base fee that adjusts algorithmically with demand plus a priority tip.
Which makes fee estimation more predictable than a pure auction.
The base fee is destroyed rather than paid to block producers in several designs, which changes issuance dynamics.
Block building markets
Specialised builders construct blocks and bid for the right to have them included.
Which separates the roles of proposing and building.
The arrangement improves proposer revenue and concentrates block construction among a small number of builders.
Private mempools
Submitting transactions directly to builders rather than broadcasting publicly.
Which avoids exposure to front-running and requires trusting the recipient.
Several wallets now offer this by default for trades.
Nonce management
Wallets track sequence numbers, and they can desynchronise if transactions are sent from multiple interfaces.
Which produces transactions that never confirm because a gap exists.
Most wallets provide a reset function, and understanding the cause makes it obvious what to do.
Checking status
A block explorer shows whether a transaction is pending, confirmed or failed.
Which resolves most confusion faster than any support channel.
A transaction absent from explorers was probably never broadcast successfully.
Cross-checking before sending
Verifying the destination address, the amount and the network before confirming.
Which prevents the most common irreversible errors, including sending to an address on the wrong network.
Some assets exist on multiple networks with identical address formats, and sending across them generally loses the funds.
Test transactions
Sending a small amount first when using a new address or service.
Which costs a fee and has prevented a great many large mistakes.
Irreversibility
Confirmed transactions cannot be undone by any authority.
Which is the defining property and the source of most user losses.
There is no reversal process, no chargeback, and no support channel that can recover a correct transaction sent to the wrong place.
Building habits
Address books, test transactions and reading before confirming.
Which are unglamorous and prevent most avoidable errors.
Support and recovery
No party can reverse a confirmed transaction, and anyone claiming otherwise is running a fraud.
Which includes recovery services advertised to victims of previous losses.
Secondary fraud targeting people who have already lost funds is a documented and common pattern.
Summary
Understanding the stages makes most problems diagnosable rather than mysterious.
Fee spikes
Demand surges make fees briefly extreme, and waiting is generally cheaper than paying through them.
Which requires knowing whether the transaction is time-sensitive.
Historical fee data shows recurring daily and weekly patterns worth knowing.
Knowing where a transaction is in this sequence turns most panics into a short wait.
Most apparent failures are transactions waiting in a queue, and knowing that removes the impulse to send a second one that makes things worse.