In this article
A deal is closing in four hours. The buyer's stablecoin transfer is sitting in the mempool, unconfirmed, with a gas fee that made sense when it was submitted but is now well below what validators are prioritizing. The title company is watching a block explorer refresh. The seller's attorney has questions. Everyone is waiting on a transaction that the network has, for the moment, simply deprioritized.
This situation is not exotic. It is a routine operational risk for any professional who handles onchain payments at the moment of settlement — closing attorneys, escrow officers, OTC desks, settlement agents, brokers running multi-party distributions. The good news is that pending transactions can almost always be resolved. The better news is that the whole category of risk can be engineered out of the workflow before it arrives. This article covers both: how to fix a stalled transaction, and how to structure payments so that a stuck mempool entry never becomes a closing-day crisis.
Why onchain payments go pending in the first place
Understanding the mechanics is not optional for professionals who are accountable for settlement. On Bitcoin, stuck transactions often result from low fees or network congestion in the mempool. Bitcoin transactions can be slow because of limited block space, a ten-minute block time, and fee-based prioritization. Fees are based on transaction size in bytes, not the value being sent — sending $1,000 and sending $1 million can cost the same fee if the transactions are the same size. That asymmetry matters for high-value commercial deals. The network does not award priority to your $2.5 million (AUD ~3.8 million) settlement over someone else's $50 test transfer. Both compete on the same fee-per-byte basis.
On Ethereum, the mechanics differ but the failure mode is the same. EIP-1559 restructured how transaction fees work on Ethereum, replacing the first-price auction model — where users guessed a gas price and miners picked the highest bidders — with a protocol-set base fee plus an optional priority fee. The base fee is determined algorithmically by the network based on demand and adjusts dynamically to ensure efficient use of block space. When network usage exceeds 50% of block capacity, the base fee increases, while it decreases slightly when usage falls below 50%.
The critical detail for professionals: users who set their maxFeePerGas at the morning's level may find their transactions stuck because the base fee has since exceeded their cap. A payment submitted at 9 a.m. with a gas cap appropriate for a quiet network can be completely stranded by an afternoon spike caused by an NFT launch, a major liquidation event, or a token claim that has nothing to do with your deal. Average priority fees during normal traffic sit around 1–2 gwei. During congestion, large NFT mints, liquidations, and airdrop claims can cause priority fees to spike to 50+ gwei.
There is also a sequencing problem unique to Ethereum that professionals need to understand. Every Ethereum transaction from a wallet uses a number called a nonce, which ensures transactions are processed in sequence. If an earlier transaction remains pending, later transactions may also remain unprocessed. In a closing scenario where a buyer's wallet has submitted multiple transactions that day, a single stuck payment early in the sequence can block every subsequent transaction — including the ones your deal depends on.
The three technical states you will encounter
When a professional is monitoring a payment and something goes wrong, they will typically see one of three states on a block explorer like Etherscan. Knowing what each state means determines what action is appropriate.
Pending / unconfirmed. The transaction has been broadcast and is sitting in the mempool, but no block has included it yet. This is the recoverable state. It means either the gas fee is too low relative to current demand, or a nonce gap is blocking it. Nothing is lost; the funds have not moved, and the transaction can still be resolved.
Failed. A transaction ends in a failed state when it encounters an error. Common causes include insufficient gas to complete execution, errors in smart contract logic, or invalid instructions. Failed transactions are recorded on the blockchain but do not execute their intended function. The funds did not move, but gas was consumed. This can happen when a gas limit — not the gas price — is set too low, causing the execution to run out of computation mid-way.
Replaced / cancelled. This state indicates the transaction has been modified rather than nullified. A replacement is used to speed up processing or to change specific values and data in the original request. A replacement transaction can be either a speed-up (same destination and amount, higher fee) or a cancellation (same nonce, zero value sent to the sender's own address).
Understanding the distinction between pending and failed matters enormously for settlement professionals. A pending payment should never be assumed lost. Calling a deal dead because a block explorer shows "pending" for two hours is a premature conclusion that can cause unnecessary disruption to every party in the room.
Method one: Speed up on Ethereum (same-nonce replacement)
For Ethereum and all EVM-compatible chains, the standard recovery method for a stuck transaction is to resubmit it with the same nonce and a higher gas fee. You can speed up or replace a stuck transaction by broadcasting a new one with a higher priority fee, using the same nonce as the original. This method works with ETH and ERC-20 tokens on any Ethereum-compatible wallet.
Most non-technical professionals will handle this through a wallet's built-in interface rather than manually. In MetaMask, you can find the "Speed up" option on your pending transaction. This feature lets you resubmit the same transaction with a higher gas fee, which increases the likelihood of validators processing it faster. Monitoring network congestion and using tools like Etherscan Gas Tracker to set optimal gas fees allows for smoother transaction management.
For technical users or teams managing settlement infrastructure, manual nonce replacement offers the most control but requires a deeper understanding of blockchain mechanics to avoid further errors. The general rule is straightforward: match the nonce of the stuck transaction exactly, then set a maxFeePerGas and maxPriorityFeePerGas meaningfully higher than the current network rate shown in a gas tracker.
Timing: Once a replacement transaction is broadcast with a sufficiently higher fee, confirmation typically follows within the next one to several blocks, which on Ethereum means under two minutes under normal conditions. During severe congestion, it may take several more blocks, but a well-priced replacement will always clear before a low-fee original.
Method two: Replace-By-Fee on Bitcoin (RBF)
On Bitcoin, the equivalent mechanism is Replace-By-Fee. Replace-By-Fee is a technical mechanism that allows a sender to replace a pending transaction with a new version that includes a higher fee. For this to work, the original transaction must have been flagged as "RBF-replaceable" when it was first broadcast.
The protocol rules are specific. RBF lets the sender broadcast a replacement transaction that spends the same inputs but pays a higher fee. Under BIP 125, the original transaction signals replaceability by setting at least one input's nSequence value below a certain threshold. Nodes accept the replacement if it meets several rules: it must spend at least one of the same inputs, pay a strictly higher absolute fee, cover the minimum relay fee for its own size, and not evict more than 100 transactions from the mempool.
An important protocol change for professionals to note: Bitcoin Core changed the default to mempoolfullrbf=1 in late 2024, and subsequently removed the option entirely, making full RBF mandatory and non-configurable. This means any Bitcoin transaction — even one not originally flagged as replaceable — can now be replaced by a higher-fee version from the sender. For settlement agents, this is a meaningful change: it reinforces that a pending Bitcoin transaction should not be treated as final until it has at least one block confirmation.
The main risk with RBF is potential confusion if the recipient sees pending payments that seem to appear and disappear in their wallet. Extra diligence is needed when leveraging RBF. For multi-party deals where multiple professionals are monitoring the same transaction hash, communicate clearly before submitting a replacement. If the attorney or settlement agent is watching the original transaction ID, they will see it disappear from their tracker when the replacement is broadcast. Brief all parties before executing.
Method three: Child-Pays-For-Parent (CPFP) on Bitcoin
When a Bitcoin transaction was not flagged as RBF-replaceable and full RBF has not been relied upon, a secondary option available to recipients is Child-Pays-For-Parent. The user creates a new "child" transaction using the unconfirmed funds from the "parent" transaction. You create a second transaction with a higher fee, which incentivizes miners to confirm both transactions together.
The practical value of CPFP in professional settlement contexts is that it can be initiated by the recipient — the party waiting to receive the funds — rather than the sender. This method can be initiated by either the sender (using the change output) or the recipient. If you are a settlement agent or closing attorney who has already received an unconfirmed incoming payment and you need it to clear urgently, CPFP gives you an action you can take independently, without going back to the payer.
If the fee for the new child transaction is high enough, the miners will confirm the stuck transaction to get to the transaction sent with high fees, as that transaction is more profitable for the miners. This will confirm the stuck transaction faster.
Third-party accelerators: when they help and when they don't
External accelerator services can push a transaction ID to mining pools for prioritization. These services are legitimate tools, but they require careful vetting. According to industry safety reports, many fraudulent websites claim to offer "acceleration" but are actually phishing for private keys.
Settlement professionals should vet any third-party tool with the same diligence they apply to any service provider in a closing.
Accelerators are most useful when a transaction is stuck without RBF capability and the recipient does not control the change output needed for CPFP. They are less useful for Ethereum, where in-wallet speed-up tooling is mature and widely available.
The professional risk that fee mechanics don't capture
The technical methods above address fee mechanics. But for settlement agents, escrow officers, and closing attorneys, there is a separate layer of risk that no fee-bumping technique resolves: the risk of a multi-party distribution where one leg settles and another does not.
Consider a commercial property closing at $4.2 million USD (approximately AUD 6.3 million). The distribution at settlement involves the seller, two commission parties, a referring party, and a title services provider — five separate payees in different proportions. In a traditional multi-step onchain disbursement, the closing agent would send individual transactions to each party in sequence. If the first transaction to the seller goes pending and stalls, the agent may not know whether to proceed with the commission payments or wait. If they proceed and the first transaction is eventually replaced with a cancelled version, the bookkeeping is a mess. If they wait, the closing drags past the agreed cutoff.
This is the specific operational problem that a payment router solves — and that pure fee mechanics cannot.
How routing eliminates the pending-payment problem structurally
The cleanest solution to a stalled distribution is not to recover from it after the fact — it is to structure the payment so that there is only one transaction to monitor, one nonce to manage, and one block confirmation that settles everything simultaneously.
This is precisely what shaka.deal is built for. Rather than requiring a closing agent to fire five sequential transactions to five payees, shaka.deal accepts the total incoming amount and routes it instantly to every party at their preset shares, in a single transaction, with finality. One block. One confirmation. Every party paid.
The operational implications for professionals are significant:
One gas decision, not many. When a settlement agent submits a single routing transaction, they set the gas fee once. There is no risk of the third or fourth payment in a sequence arriving under-gassed because conditions changed during the time it took to submit the first two.
One nonce, no sequencing risk. The nonce fragility problem — where a stuck early transaction blocks everything that follows — disappears entirely. There is one transaction in the mempool. If it needs a speed-up, there is one transaction to replace.
Simultaneous settlement for all parties. Every payee receives their share at the same block height. There is no interval between the seller's receipt and the agent's commission, no window during which the deal is partially settled and partially open. Blockchain-based settlement provides an immutable record of each transaction — and when that record shows a single routing event with every payee addressed simultaneously, the audit trail is clean and unambiguous.
Finality that closes the loop. Onchain payments are not reversible once confirmed. A settled routing transaction does not bounce, does not reverse, and does not generate a dispute the way a wire transfer can. Settlement agents who have managed the anxiety of a late-arriving wire will recognize this as a structural improvement, not merely a convenience.
shaka.deal is non-custodial by design. It routes the funds; it never holds them. The moment the single inbound transaction is confirmed on Ethereum, every preset share moves directly to every designated address. No pooling, no float, no intermediate custody window. This is a meaningful distinction for regulated professionals whose obligations require them to know exactly where client funds are at every moment.
A scenario comparison: sequential disbursement versus single routing
Scenario A — sequential disbursement. A commercial lease deposit of $500,000 USD (approximately AUD 755,000) is being distributed to three parties at close: the property owner (80%), the managing agent (12%), and the legal services provider (8%). The settlement officer submits three consecutive Ethereum transactions during a period of moderate congestion. The first transaction clears in under a minute. The second was submitted with a slightly lower gas setting and is now sitting in the mempool as the base fee has ticked up. The third was never broadcast because the officer was waiting to confirm the second. Twenty-five minutes into the wait, the officer submits a speed-up for the second transaction, adds a higher fee, and it clears. The third transaction is then broadcast.
Scenario B — single routing transaction. The same $500,000 USD distribution is handled through shaka.deal. The settlement officer configures the preset shares (80/12/8) once. At closing, a single transaction is submitted with an appropriate gas fee checked against the current Etherscan Gas Tracker. All three parties receive their shares at the same block confirmation, within seconds of the transaction landing.
| Outcome | Scenario A: sequential | Scenario B: single routing |
|---|---|---|
| Total elapsed time | 40 minutes | Within seconds of the transaction landing |
| Transaction hashes to document | Three | One |
| Gas | One gas cost raised by the speed-up | One gas payment |
| Phone calls about missing distributions | One anxious call from the managing agent's office, wondering why their share has not arrived | Zero |
The difference is not just speed. It is operational certainty — the quality that every professional in a closing room is ultimately being paid to deliver.
Practical gas hygiene for settlement professionals
Whether a payment is being sent directly or routed, good gas discipline reduces the probability of a pending payment arising in the first place. The following practices apply to any professional regularly executing onchain settlements on Ethereum.
Check a gas tracker immediately before submitting. Check a gas tracker like Etherscan Gas Tracker before confirming any transaction. Gas conditions can change in minutes. A setting that was appropriate at 10 a.m. may be inadequate by 10:15 a.m. if a major DeFi event hits the mempool.
Set maxFeePerGas with a meaningful buffer above the current base fee. EIP-1559 prevents users from overpaying gas fees by enabling them to set a max fee per gas, which covers both the base and priority fees. If the base fee rises while the transaction is pending, the max fee ensures the transaction remains valid without exceeding the user's budget, and any unused fee is refunded. Setting the max fee cap with a generous buffer above the current base fee means the transaction will survive a moderate base-fee increase without getting stuck.
Do not try to save money on gas for high-value settlements. On a $2 million USD (AUD ~3 million) closing, the gas cost for a single Ethereum transaction is negligible. Average transaction fees on Ethereum dropped to approximately $0.31 in late 2025, narrowing the cost gap with competitors. Even in periods of moderate congestion, an ERC-20 transfer might cost a few dollars. Submitting at a low-fee setting to save $3 on a seven-figure distribution is a false economy that risks a 30-minute delay and an anxious closing room.
Keep wallets clear of unrelated pending transactions before a closing. The nonce sequencing problem means that any existing stuck transaction in a wallet will block a new settlement transaction. Before a scheduled closing, confirm that the sending wallet has no pending activity. If there is a stuck transaction from an earlier, unrelated operation, resolve it first.
Have the replacement flow documented in advance. Every settlement team that handles onchain payments should have a written internal procedure for replacing a stuck transaction — including who has authority to submit the replacement, which gas tracker to use, and what the minimum acceptable fee multiple is. Do not draft this procedure at 3:58 p.m. on a closing that is supposed to complete at 4 p.m.
When Bitcoin settlement is in scope
Some OTC desks and cross-border transactions still settle in Bitcoin, particularly for large-value deals where the payer's wealth is denominated in BTC. For professionals in these workflows, two additional points apply.
First, transactions often involve incredibly large sums, making payments in volatile currencies like Bitcoin risky due to potential slippage. Stablecoins make big payments predictable, allowing businesses that accept digital assets to attract tech-savvy and high-net-worth investors who own them. Where possible, converting to a stablecoin before the settlement leg reduces price-exposure risk during the pendency window.
Second, Bitcoin's block time — approximately ten minutes per block, with confirmation typically required for finality — means that a pending Bitcoin payment will always introduce more elapsed time than an Ethereum stablecoin payment, even when everything is working correctly. For closings with hard deadlines, settlement agents should build this into their timeline and avoid scheduling a Bitcoin-denominated closing with less than 90 minutes of buffer before any deadline.
The relationship between pending risk and settlement certainty
Every technique in this article — RBF, CPFP, speed-up tooling, gas hygiene — is a recovery method. Recovery methods exist because the base transaction model, when used naively, creates uncertainty. A single-payment routing approach through a tool like shaka.deal reframes the question entirely: instead of "how do we recover when a payment stalls," the question becomes "how do we ensure that one well-priced transaction covers every party simultaneously."
That reframe matters for the professionals in the room. Settlement agents, title companies, and closing attorneys are trusted because they provide certainty. Their clients — buyers, sellers, lenders, commission parties — do not need to understand mempools or EIP-1559 fee dynamics. They need to know the deal closed, the money moved, and everyone received what they were owed. When onchain payment infrastructure is structured so that settlement happens in one atomic action, the professional's job is easier to do and easier to prove.
Stablecoin settlements completed within minutes, independent of banking hours or international clearing cycles, reduce the risk of deals collapsing due to payment delays and improve confidence among all parties. That confidence is not a byproduct of good technology — it is the product that settlement professionals are ultimately selling. The right infrastructure makes it deliverable.
Summary
A pending onchain payment is recoverable in almost every case. On Ethereum, the nonce-based speed-up method — resubmitting the same transaction with a higher maxFeePerGas — is reliable and supported natively by major wallets. On Bitcoin, RBF and CPFP cover the two main recovery scenarios, with the caveat that full RBF is now the network default and recipients must be briefed before a replacement is broadcast. Third-party accelerators are a legitimate last resort when neither protocol-level method applies, but require careful vetting for security.
Beyond recovery, the deeper strategic point for professionals is structural: routing the full settlement amount through a single-transaction payment router eliminates the nonce sequencing risk, reduces the number of gas decisions to one, and delivers simultaneous finality to every party in a distribution. For professionals whose value proposition is certainty — and whose clients are measuring them by whether the deal closed cleanly and on time — that structural advantage is not a minor convenience. It is the outcome they were hired to deliver.
