When to Rebroadcast a Stuck Crypto Transaction, and When to Replace It

A hot-wallet payout left twenty minutes ago, the user has opened a ticket, and the explorer still shows it unconfirmed. The on-call engineer can resend the signed bytes, sign a replacement, or wait, and each choice does something different to the account's nonce sequence.

On EVM chains, rebroadcast a stuck crypto transaction only after nodes drop it. A pending EVM transaction whose max fee trails the base fee can wait; a low tip, or a payout that cannot wait, needs a same-nonce replacement that clears geth's default 10% price bump on both fee fields. On TRON and Solana, resend the transaction while it is live; after expiry, sign a new one.

The five causes of a stuck crypto withdrawal explain why payouts stall. For the person holding the pager, rebroadcast, replacement and expiry are three separate actions with separate preconditions, and mixing them up is how one stuck payout turns into a stuck queue.

Where Does a Stuck Transaction Sit in Its Lifecycle?

A stuck transaction is in one of a handful of states: signed, broadcast, waiting in a pool, then included, dropped or expired. Every recovery action assumes one of those states.

On EVM chains, the nonce decides most of this. Ethereum.org's transactions documentation (last updated October 7, 2026) defines the nonce as "a sequentially incrementing counter which indicates the transaction number from the account". A hot wallet that sends payouts in sequence has every later payout waiting on the earliest unconfirmed one, so a single underpriced withdrawal quietly becomes a queue of them.

The pool has its own clock. In geth's command-line options (geth 1.15.11 docs, last edited May 16, 2025), the txpool.lifetime setting defaults to three hours, the "Maximum amount of time non-executable transaction are queued". That limit covers queued transactions, the ones stuck behind a nonce gap; pending transactions with no gap fall outside it. Other clients and operators set their own values, so the diagnosis asks more than one node before declaring a transaction gone.

Fee price and gas limit are separate dials; for gas units, see how Ethereum gas limits work.

When Does It Help to Rebroadcast a Stuck Crypto Transaction?

On EVM chains, rebroadcasting a stuck crypto transaction helps in one state: the network has lost the transaction, and its fee is still competitive (on TRON and Solana, resending also works while the transaction is still live). A rebroadcast sends the identical signed bytes again. The hash stays the same and the payout record needs no edit.

Rebroadcasting is also safe. Ethereum.org's accounts documentation (last updated August 6, 2026) states: "Only one transaction with a given nonce can be executed for each account, protecting against replay attacks where signed transactions are repeatedly broadcast and re-executed." A resend can never pay the user twice, so an exchange can resend from a script through several RPC providers.

Rebroadcasting an underpriced transaction does nothing useful, because the nodes already hold a copy at that price. Resending without a fee change is the missing fee-bump and rebroadcast strategy that keeps withdrawals stuck.

Two error strings tell the operator to stop resending. Geth's core error definitions (geth master, checked November 3, 2026) return "nonce too low" when the nonce of a transaction "is lower than the one present in the local chain". The nonce is already used, by the original or by another transaction from the same account. Look it up on chain before touching anything. The sibling error, "nonce too high", means the nonce is higher than the next one the node expects. An earlier nonce is missing, and the fix is that missing transaction.

My rule: automate rebroadcasting because it is cheap and harmless, and never let it stand in for a fee decision.

When Does a Stuck Transaction Need a Same-Nonce Replacement?

A stuck EVM transaction needs a same-nonce replacement when it is still valid, still in the pool, and either tipping too little for current demand or priced under the base fee on a payout that cannot wait. EIP-1559 (Final status, created April 13, 2019) gives each transaction two fee fields: a max priority fee per gas, which is the tip, and a max fee per gas that covers the tip plus the base fee. If the max fee sits below the current base fee, the transaction waits until the base fee falls back under it. Waiting is a legitimate call there, and a same-nonce replacement is the move when the payout cannot wait. A tip too low for current demand calls for replacement.

A replacement is a new transaction signed from the same account at the same nonce with higher fee fields. The replacement carries a new hash, and the one-transaction-per-nonce rule above means only one of the two hashes can ever confirm. The payout record has to track both until one lands.

Geth's default txpool.pricebump is 10, the "Price bump percentage to replace an already existing transaction", and geth's pool applies it to both the max fee and the priority fee (geth master, checked November 3, 2026). A replacement that raises one field and leaves the other gets rejected with "replacement transaction underpriced". Geth's txpool errors (geth master, checked November 3, 2026) return that error when a transaction "is attempted to be replaced with a different one without the required price bump." A replacement that raises both fields by at least 10% clears geth's price-bump check. Other clients can configure a different bump, so build margin into the rule.

A generous max fee costs less than its number suggests. EIP-1559 says "Senders will always pay the base fee per gas of the block their transaction was included in", so the max fee is a ceiling. The tip is the field that buys priority.

For the queue side of a fee spike, see gas spikes, fee thresholds and the withdrawal queue.

Which Action Fits Each Stuck Withdrawal State?

Each stuck withdrawal state maps to one action. The wrong action at the earliest unconfirmed nonce leaves a stale nonce blocking the whole withdrawal queue.

No resend should go out until the diagnosis establishes whether nodes still hold the transaction, which nonce the chain expects next, and whether the fee or the expiry window has run out:

• Query the hash on at least two nodes from different providers.
• Read the account's next nonce from chain state and compare it with the stuck transaction's nonce.
• Compare the max fee per gas with the current base fee.
• On TRON, compare raw_data.expiration with the head block's timestamp.
• On Solana, check whether the blockhash is no more than 151 blocks old.
• Record every hash signed for the payout, original and replacements.

How Should an Exchange Rebroadcast a Stuck Crypto Transaction on TRON and Solana?

TRON and Solana put expiry inside the transaction, which gives an exchange's runbook a clean third option: let the transaction expire, then know it will never land.

TRON's transaction documentation (updated October 2026) defines raw_data.expiration as a Unix timestamp in milliseconds after which "the transaction is dropped instead of included." The default is 60 seconds past the head block's timestamp, and the maximum is 24 hours. A TRON transaction that passes its expiration timestamp is dropped, and resending the same signed bytes cannot revive it. Expiration sits inside raw_data, the signed payload, so a later expiration needs a new signature. Inside the window a rebroadcast works; past it, recovery is a newly signed transaction.

The expiration setting is a judgment call, and I'd keep it short for payouts. A 60-second window answers the dead-or-alive question in a minute. A 24-hour window leaves an unconfirmed payout ambiguous for a day. TRON fee pricing runs on energy and bandwidth, covered in TRC20 fees for USDT transfers and staking versus burning TRX for energy.

Solana's confirmation and expiration docs (checked November 3, 2026) say a transaction expires when its recent blockhash is no longer recent enough, with a max processing age of 150 that counts from zero, so a blockhash stays valid while it is no more than 151 blocks old, and "a given blockhash can only be used by transactions for about 60 to 90 seconds". Solana tells clients they "should keep resending a transaction to a RPC node on a frequent interval" while it is live. On Solana, rebroadcasting is the normal mode inside the window and expiry is the stop condition. After expiry, users "can try again knowing that their previous transaction will NOT ever be processed". Every payout reconciliation wants that sentence.

Durable nonces (Solana guide, checked November 3, 2026) are "used in place of recent blockhashes" and remove "the mortality on the unexecuted transaction", and the first instruction must advance the nonce. For a payout retry loop, I'd keep the recent blockhash. Mortality is what lets the runbook declare the old transaction dead and sign a new one without a double-payment question hanging over it.

How Does an Exchange's On-Call Night Change When Fees Are Priced by Rule?

An exchange's on-call night depends on where the fee decision lives when gas price spikes hit the withdrawal queue.

Without fee rules: at 02:10 a base fee spike leaves an ERC-20 payout from the hot wallet pending. The on-call engineer resends it through two RPC providers, and nothing moves, because both pools already hold it. A replacement with a 5% bump comes back "replacement transaction underpriced". The second attempt raises the tip and forgets the max fee. By the time a replacement lands, the payouts queued behind it have produced a page of tickets, and the morning reconciliation has three hashes for one withdrawal.

With fee rules: the same spike arrives. The dispatch layer holds payouts while the fee sits above the limit the team set, so nothing underpriced goes out. When the fee falls below the limit, the held payouts go out. One payout broadcast just before the spike does stall; the table says pending and underpriced, so the engineer signs one replacement that raises both fields by at least 10%, and the record keeps both hashes. An approved record that waited past its expiry is cancelled automatically. The engineer is back asleep by 02:30.

That fee limit is what CoinSend's gas fee controls are built for: "CoinSend allows you to pause the dispatch of assets until the gas fee falls below the set limit."

How Do Fee Thresholds and Approval Expiry Shrink the Decision Table?

A fee threshold means fewer transactions ever reach the replacement row of the decision table. A payout held until the fee falls below the set limit is never broadcast into the spike, so the pending-and-underpriced rows fire less often.

CoinSend is where those rules sit for an exchange's payouts. CoinSend runs 24/7 automated withdrawals, with fee thresholds that gate each dispatch.

CoinSend execution approvals carry configurable expiry times, visible per dispatch record. The execution approval expiry docs state: "If a transfer record is not broadcasted within the expiration time, it will be automatically cancelled." That auto-cancel keeps reconciliation clean: an approved record that never went out cannot later surface as an extra hash against the payout.

For high-value payouts, CoinSend's approval flow lets a team self-define the flow and set the approval limit of each approver. CoinSend's API plugs directly into an exchange's existing systems and workflows, so the lifecycle checks above can stay in the exchange's own monitoring. A transaction already in the pool still goes through the runbook, which now rarely runs. For the setup itself, see how to automate user withdrawals in CoinSend.

What Do Operators Ask about Rebroadcasting Stuck Transactions?

Is It Safe to Rebroadcast the Same Signed Transaction Twice?

Yes. Rebroadcasting the same signed transaction on an EVM chain is safe because the protocol lets only one transaction per nonce go through for each account. The identical bytes keep the same hash, so a resend through several RPC providers can never pay the recipient twice.

What Does "Replacement Transaction Underpriced" Mean on an EVM Chain?

Geth returns "replacement transaction underpriced" when a same-nonce replacement lacks the required price bump. Geth's default bump is 10%, applied to both the max fee per gas and the max priority fee per gas. A replacement that raises both fields by at least 10% clears geth's price-bump check.

Why Does My Rebroadcast Return "Nonce Too Low"?

A "nonce too low" error means the nonce is lower than the next nonce in the node's local chain state. The slot is already used, by the original transaction or by another one from the same account. Check the chain for which hash used that nonce, then stop resending.

Can a TRON Withdrawal Be Rebroadcast After It Expires?

No. A TRON withdrawal past its raw_data.expiration timestamp is dropped and cannot be included. Expiration sits inside the signed payload, so recovery needs a new transaction with a new expiration and a new signature. Inside the window, which defaults to 60 seconds and caps at 24 hours, rebroadcasting works.

Should a Solana Payout Use a Durable Nonce for Retries?

For payout retries, a recent blockhash is the better choice. A recent blockhash expires once it is more than 151 blocks old, and an expired transaction will never be processed. Durable nonces remove that mortality, which leaves an unconfirmed payout valid and makes a clean re-sign harder to reason about.

Should Your Team Rebroadcast, Replace, or Let a Stuck Transaction Expire?

On EVM chains, automate rebroadcasting, because it is harmless and only useful for transactions that nodes have dropped. On TRON and Solana, resending inside the expiry window is the normal mode. Make replacement a rule: same nonce, both fee fields raised at least 10%, every hash recorded. On TRON and Solana, keep the expiry short and treat expiry as the signal to sign again. On every chain, diagnose the state first, then pick rebroadcast, replace or expire, and the on-call engineer stops guessing at 02:10.

Talk to a CoinSend expert about setting fee thresholds and approval expiry for your payout flow.