If a bridge deposit is stuck, replacing its source-chain transaction can get it confirmed, but only if the replacement still performs the deposit. A same-nonce “cancel” consumes the pending nonce with a different action; it does not rescue funds into the bridge. For treasury transfers, the key distinction is whether the replacement preserves the bridge call and its parameters.
A replacement competes for the same nonce
On an EVM chain, a sender’s nonce identifies one position in that account’s transaction sequence. A replacement uses the same sender and nonce, so at most one version can execute. Nodes typically require a fee increase; for example, Geth’s default transaction-pool price bump is 10%, though the receiving node’s policy and transaction type determine what it accepts.
When the original is a bridge deposit, preserve its destination contract, value, calldata, token amount, recipient and any route or minimum-output parameters. A cross-chain relay bridge depends on the source-chain action actually executing so its event or other deposit evidence can be observed before the transfer proceeds. A replacement that sends native coin back to the treasury wallet may clear the nonce, but it abandons that deposit.
Rebroadcast the deposit call when its terms are still right
Suppose a treasury wallet submits a 20 ETH deposit into a cross-chain swap and the transaction remains pending during a fee spike. If the quote, recipient and destination are still acceptable, the operator can sign a same-nonce transaction with the same call data and a higher fee cap and priority fee. The replacement has a new transaction hash; after it confirms, reconcile against the included transaction and its emitted deposit event, not the stale hash alone.
Before signing, compare the full decoded transaction with the original, including chain ID and contract address. Check the current base fee, the account’s confirmed and pending nonces, and queued transactions after the stuck nonce. Fee caps should leave headroom above the expected base fee, while the priority fee should be competitive for inclusion; raising only one field may fail a node’s replacement rule. Leave enough native asset for the fee, and account for the possibility that an already broadcast original lands before peers accept the replacement.
Know what the bridge and destination chain will observe
A bridge service generally needs a confirmed source-chain deposit and enough source-chain finality before it can validate or relay the transfer. Replacing a pending transaction before inclusion changes which candidate can produce that deposit; it does not create a second deposit if both versions share the same EVM nonce. Once one version is included, the bridge’s monitoring process may still take time to index it, wait for confirmations, verify the event and complete destination execution.
Do not assume every status tracker follows a replacement hash automatically. If the source explorer shows the replacement as successful but the bridge remains pending, reconcile the confirmed transaction hash, block, emitting contract, event parameters and destination recipient. Give the bridge process its normal confirmation and indexing window before starting a duplicate transfer; a second deposit is a new transfer with separate capital and execution risk.
Bitcoin replacements need output-level checks
For a Bitcoin deposit, fee replacement works through conflicting UTXO spends rather than an account nonce. The replacement must spend the same input, and its outputs determine whether the bridge still receives the intended amount at its deposit address. Bitcoin Core’s current replacement policy requires at least the original absolute fee plus an incremental relay fee; the default incremental rate is 0.1 sat/vB, but node policy can vary.
Inspect the replacement’s outputs, destination script and net deposit amount before broadcasting. Wallets can reduce change or alter outputs while bumping fees, and a bridge may require a particular amount or script plus a confirmation threshold. The transaction ID can change, so use the confirmed output and bridge-specific deposit evidence to reconcile it.
For routine treasury operations, I would rebroadcast the identical deposit action with a deliberate fee bump when its terms remain valid. I would cancel only when the business decision is to abandon that transfer, then create a fresh deposit after confirming the nonce is clear. Treat a relay bridge status as a separate reconciliation signal from the source-chain transaction: success on one side does not prove completion on the other.
- Confirm the original is pending and identify its sender, nonce or UTXO inputs.
- Preserve the deposit action, amount, recipient and route when bumping fees.
- Verify the confirmed replacement and its deposit evidence on the source chain.
- Wait for bridge processing, then reconcile destination completion before retrying.