In this article
A settlement agent routes a wire, a closing attorney coordinates fund disbursements at the table, an OTC desk executes a multi-party transfer — and then the confirmation never arrives. The block explorer shows "pending." An hour passes. Two. The word stuck starts circulating.
For professionals whose work depends on knowing when money has moved and to whom, a stuck onchain payment is not merely an inconvenience. It is a gap in the audit trail, a delay in releasing downstream obligations, and a source of the kind of uncertainty that good deal structure is specifically designed to eliminate.
The root cause almost always traces back to one small number that most people never think about: the nonce.
The nonce: a number that keeps the ledger honest
Used in cryptography as an acronym for "Number Only Used Once," a nonce is a number that functions as an identifier for a transaction. In the context of Ethereum, the term has a very specific and consequential meaning that goes beyond its cryptographic origins.
A nonce is a per-account counter that increments by one with every transaction an address sends. The first transaction an address ever broadcasts carries nonce 0. The second carries nonce 1. The ten-thousandth carries nonce 9,999. There is no skipping, no resetting, no flexibility. The counter is global to the address and permanent on the chain.
Every Ethereum transaction from a wallet uses a number called a nonce, which ensures transactions are processed in sequence. That sequential enforcement is not an implementation quirk — it is load-bearing infrastructure for the entire account model.
Think about what the nonce prevents. Without a sequential ordering rule, an observer who captures the cryptographic signature on a valid transaction could replay it later: broadcasting it again to drain the same funds a second time. The nonce closes that door. Ethereum does not let you send the second transaction until the first is mined to make sure a malicious third party doesn't flood the network with one of your transactions, emptying your wallet.
A nonce is a sequential number attached to each transaction from a given address, enforcing an order. If a transaction with nonce 5 is broadcast before nonce 4 arrives, the entire sequence stalls until nonce 4 is confirmed.
This is the rule that creates stuck payments.
Where transactions wait: the mempool
Before understanding how a nonce causes a blockage, it helps to understand where transactions spend their time before they confirm.
In Ethereum, users send their transactions to the blockchain network, where they are propagated to reach validator nodes. On every blockchain node, unconfirmed transactions are buffered in the mempool before they are included in the next block or evicted by another transaction.
The mempool is not a single queue. It is more like a waiting room that every node on the network maintains independently. The "pending" view is a per-node thing. Different nodes can disagree on what's in the mempool. Some transactions haven't propagated yet, some have expired, some came in through private routes that bypass the public mempool entirely.
Once a transaction reaches the mempool, inclusion in a block is not guaranteed — and it is not instantaneous. Block producers select which transactions to include, and their primary criterion is the fee the sender is willing to pay.
When more transactions enter the mempool than a single block can hold, block producers prioritize by fee. Since EIP-1559, Ethereum uses a dual-fee mechanism: a base fee set by the protocol and a priority fee set by the user. The priority fee, or tip, goes directly to the validator. Higher tips mean higher priority. Validators maximize revenue by selecting transactions with the highest priority fees.
When network demand surges, the base fee ramps up automatically, pricing out lower-value transactions.
This means that at any moment, the mempool contains two types of waiting transactions: those that are genuinely competitive with current network conditions, and those that are not — because the fee they offered has been overtaken by the current market.
Transactions in the second group sit. And when a sitting transaction carries the lowest pending nonce for an account, every subsequent transaction from that same account sits with it.
The cascade: why one nonce blocks the whole queue
Ethereum numbers every transaction an account sends, and that counter is the nonce. Transactions confirm strictly in nonce order, so number 12 cannot go through before number 11.
This is the rule in its simplest form. Its consequences in practice are severe.
Imagine your wallet has already confirmed transactions up to nonce 11. You send a swap with nonce 12, but the gas is too low. Then you send another transfer with nonce 13. Even if nonce 13 offers a better fee, it cannot confirm before nonce 12. The chain expects nonce 12 first. Until nonce 12 confirms, gets canceled, or gets replaced, later transactions from the same account stay blocked.
The mempool handles this by sorting transactions into two sub-pools per account. Ethereum transactions must execute in strict nonce order per account. If your account's next expected nonce is 5 and you submit nonce 7, that transaction enters the queued pool. It cannot execute until nonces 5 and 6 are filled. Pending transactions have contiguous nonces starting from the account's current on-chain nonce and are eligible for immediate inclusion.
The practical result: any transaction that would follow a stuck nonce is not competing for block inclusion at all. It is sitting in the queued sub-pool, invisible to block producers, regardless of how generous its fee is.
Ethereum assigns a unique number, called a nonce, to each transaction from an address. If a transaction with a lower nonce is pending, subsequent transactions will also be delayed until the pending one is processed.
The three causes of a stuck nonce
Understanding why the nonce gets stuck — rather than simply that it does — matters for anyone who needs to prevent or resolve the problem quickly.
Cause one: an underprice at submission time. The most frequent reason for a transaction stuck on pending is insufficient gas. Ethereum uses a bidding system where users pay a base fee plus a priority fee, or tip. If the tip offered is below what validators are currently accepting, the transaction sits at the front of the queue without being picked up. Every transaction behind it queues.
Cause two: a sudden congestion spike after submission. Global events, such as the launch of a popular decentralized application or a sudden market crash, lead to network congestion. When thousands of users attempt to move assets simultaneously, the minimum gas price required for entry into the next block rises sharply. A transaction submitted during a quiet moment with a perfectly reasonable fee can become uncompetitive within seconds if demand spikes while it is still pending.
Cause three: a nonce gap created by parallel submissions. Two workers submitting in parallel will read the same pending nonce and sign transactions with the same slot. One will be accepted; the other will either fail with "replacement transaction underpriced" or silently overwrite the first, depending on fee levels. This is particularly relevant for operations teams or automated systems that submit multiple transactions from the same account, or for scenarios where a user retries from a different device or wallet interface. If your last confirmed transaction has nonce 20, but a wallet shows a pending transaction with nonce 22, then nonce 21 is missing from the blockchain. That missing transaction is blocking nonce 22 and everything after it.
The panic trap: why resending makes things worse
There is a deeply human response to a stuck payment: send it again.
One cheap, stuck transaction at nonce 11 holds up everything behind it, however generous the later fees are, and people who panic and send again just end up with four stuck transactions queued instead of one. The extra sends push nothing through — they just make the queue longer.
This is why people get trapped after clicking several times. They think sending another transaction will push the first one through. In reality, they create a longer queue.
This is one of the sharpest differences between onchain payments and traditional wire transfers. In traditional banking, a failed payment attempt simply does not go anywhere — the funds return or the instruction is rejected cleanly. In an Ethereum account, every broadcast creates a queued nonce slot. Each additional broadcast without addressing the original stuck nonce adds another dependent transaction to the waiting chain.
How to resolve a stuck nonce
There are two viable paths, and both require acting on the specific stuck nonce — not submitting a fresh transaction with the next nonce in sequence.
Speed-up: replace the stuck transaction with a higher fee. Use your wallet's speed-up option. It re-broadcasts the same nonce with a higher fee, and block producers take the better-paying version. Under the hood, this is called a replacement transaction: same nonce, same recipient, same data, but higher fee parameters. Resend with the same nonce and both maxFeePerGas and maxPriorityFeePerGas raised by at least 10%. Raising only one of the two fee fields gets rejected with "replacement transaction underpriced," and the original stays stuck.
Cancel: overwrite the stuck transaction with a no-op. A cancel is a zero-value transaction sent to your own address with the same nonce and a higher fee. It replaces the stuck transaction with one that does nothing, and you pay a small fee for it. This clears the nonce slot without executing the original intent, freeing all subsequent queued transactions to become eligible for inclusion.
Before taking either action, it is important to verify the transaction in a block explorer like Etherscan to confirm that it is pending. A transaction that has already dropped from the mempool does not need a replacement — it simply does not exist onchain, and a new submission with the correct nonce will go through normally.
Finality: the other side of the coin
The nonce creates the ordering guarantee that makes Ethereum's account model secure. But there is a complementary property that matters just as much for professionals who deal in high-value settlements: once a transaction confirms, it is final.
On a proof-of-stake network like Ethereum, a transaction becomes technically final when it is incorporated into a validated block and subsequently confirmed. Although consensus finality can be formally probabilistic depending on the consensus mechanism used, the economic cost of reversing even a handful of confirmations makes rollback practically impossible. To unwind a confirmed transaction on a major proof-of-stake chain, a malicious actor would need control of a supermajority of validators and would incur massive slashing penalties.
Billions in staked collateral would be automatically destroyed. This deterrent exceeds any comparable mechanism in traditional payment systems, where reversals can be initiated by a central operator, a court order, or a back-office correction.
This means the nonce creates a particular shape of risk: while a transaction is pending, it is uncertain. Once it confirms, it is certain in a way that few settlement mechanisms can match. The challenge for professionals is managing the window in between.
Instead of a network of banks, clearinghouses, and custodians confirming a trade over days, the transaction records the change of ownership and completes payment in a single step. Once the block is finalized, the transfer is done, and no separate reconciliation is required to prove who owns what.
What a multi-party deal looks like in practice
Consider a commercial real estate closing involving five parties: a buyer, a seller, a listing broker, a buyer's broker, and a title company. In a traditional wire-based close, each of those payments typically goes out as a separate instruction — sometimes hours apart, sometimes on different days, each carrying its own confirmation timeline and its own potential to go sideways.
Now translate that to an Ethereum-based close. If each payout is its own transaction from the same sending account, nonce sequencing applies to all of them. The seller proceeds, broker commissions, and title fees are queued in strict order. If the first transaction — say, the largest wire to the seller — stalls due to a gas underestimate at a moment when the network is busy, every subsequent disbursement waits behind it. The brokers' disbursements sit in the queued sub-pool. The title fee never moves. And the entire table — parties who have already signed, already handed over keys, already done their work — waits while someone troubleshoots a gas parameter.
This is not a hypothetical edge case. It is the structural consequence of routing multi-party deals as a sequence of separate transactions rather than as a single atomic settlement.
The alternative architecture — one inbound payment that distributes to all parties simultaneously, in preset shares, within a single transaction — eliminates the nonce cascade problem entirely for the payout leg. There is one transaction. It either confirms or it does not. If it confirms, every party receives simultaneously, from the same block, at the same timestamp, with the same transaction hash as the shared record of settlement.
This is the design that shaka.deal is built around. One incoming amount, preset split logic written at deal creation, and simultaneous distribution to every party in the deal — settlement agents, brokers, title companies, OTC counterparties — in a single onchain transaction. Non-custodial: the router never holds funds. It receives and distributes in the same movement. Because the split is a single outbound transaction rather than a sequence of them, the nonce cascade that plagues sequential multi-party disbursements simply does not arise on the distribution side.
For a USD 2,400,000 (AUD 3,700,000 at current rates) commercial close with five parties, that distinction is not marginal. It is the difference between a settlement that lands cleanly and one that requires a troubleshooting call at 5:45 pm.
Nonce awareness as professional practice
Settlement professionals who work with onchain payments regularly need a practical mental model for nonce management, just as they maintain a working knowledge of wire cut-off times and SWIFT messaging delays in traditional finance.
A few principles worth building into any onchain payment workflow:
Check the account's pending state before submitting. A block explorer search on the sending address will show whether any transactions are already pending. Submitting a new transaction from an account that already has a pending one simply adds to the queue rather than racing ahead of it.
Set gas parameters at current market rates, not at minimums. To avoid stuck transactions, always select an appropriate gas fee when initiating a transaction. Many wallets offer suggested gas fees based on current network activity, but you can opt for higher fees for time-sensitive transactions. For a high-value commercial settlement, the difference in gas cost between the minimum and a confident inclusion fee is almost always trivial relative to the deal size.
When a transaction is stuck, act on the stuck nonce, not on a new one. The correct fix is not to submit random new transactions. The correct fix is to replace the oldest pending nonce.
Treat the block confirmation as the receipt, not the broadcast confirmation. Many wallets show a confirmation screen immediately after broadcasting. That screen means the transaction has entered the mempool, not that it has confirmed. A pending transaction sits in the mempool waiting for a block producer to include it. Until that happens the network has not moved anything, and if the transaction eventually drops out, the balance never left your address. The actual settlement receipt is the block confirmation, available on any block explorer by transaction hash.
Structure eliminates the problem before it starts
The professionals who use onchain payment infrastructure at scale — OTC desks clearing USD 10,000,000+ (AUD 15,400,000+) in single transactions, escrow officers coordinating multi-party property closings, settlement agents distributing proceeds across broker syndicates — do not want to become nonce experts. They want payment infrastructure that is architected so that nonce problems cannot propagate to the multi-party distribution step.
The nonce problem is a sequencing problem. It is worst when a single sending account must produce a chain of sequential disbursements. The architectural answer is to collapse that chain: one inbound transaction triggers a single distribution event that reaches all parties atomically.
Onchain settlement is the process of transferring final ownership of an asset and its payment on a blockchain, where the ledger update itself is the settlement. When every party in a deal receives their share from the same ledger update — the same block, the same transaction — the question of which nonce comes next simply does not apply to the distribution. There is nothing to sequence. The split is simultaneous by design.
That is why deal structure matters as much as deal execution when working with onchain payment rails. A settlement designed to pay five parties in five sequential transactions carries five opportunities for a nonce to stall. A settlement designed as a single routed transaction carries one. And once that one transaction confirms, settlement plays a key role in reducing counterparty risk and ensuring payment finality. Once a transaction is settled, ownership is transferred, and the transaction is irreversible.
For the closing attorney waiting to release title, the broker waiting to close their books, the settlement agent who has already prepared the HUD-1, and the OTC counterparty managing overnight exposure — irreversible and simultaneous is the only acceptable outcome. The nonce is the mechanism that enforces order. Understanding it is how professionals stop fighting it.
Shaka.deal is a B2B onchain payment router on Ethereum. It takes one incoming payment, applies preset share logic, and distributes simultaneously to every party in a deal — in a single transaction, with finality. Non-custodial: it routes, it never holds. Learn more at shaka.deal.
