Replacing a stuck source transaction means submitting a competing transaction from the same account with the same nonce, so at most one version can be included on the canonical chain. The critical condition is whether the original has already been included: a confirmed deposit cannot be undone by a replacement, and sending a fresh deposit can create a second transfer.
What does replacing a source transaction change?
On an EVM chain such as Ethereum or Base, the account nonce orders transactions from a sender. If a deposit is still pending, a wallet can rebroadcast it with higher fee parameters and the same nonce; once one version is included, that nonce is consumed and the other version cannot execute on the canonical chain.
A speed-up should preserve the original transaction’s destination, value and calldata. For a bridge deposit, that keeps the contract call and deposit parameters the same while raising the fee bid. A cancellation instead uses the same nonce for a self-send, commonly with zero token value and empty calldata; if it lands first, it prevents the pending deposit from landing.
This is a source-chain transaction operation, not an Across refund or intent edit. Before inclusion, the SpokePool has not escrowed the deposit’s input tokens or emitted its deposit event. After inclusion, the deposit may be waiting for a relayer, but it already exists: replacing its transaction is no longer the remedy.
How should treasury speed up or cancel it?
First identify the sender, chain, nonce and transaction hash from the original signed transaction. Check the source-chain explorer or a reliable RPC for a receipt and inspect the sender’s confirmed and pending nonces; a wallet’s “pending” label alone can be stale, especially when RPC providers have different mempool views.
If no receipt exists and the deposit is still wanted, choose “speed up” in the signing wallet so it reuses the original nonce and calldata. For an EIP-1559 transaction, increase both maxPriorityFeePerGas and maxFeePerGas; many nodes commonly require a bump of about 10% or more on both, though wallet and node policies vary. Set the cap against treasury policy, since the cap is not the amount automatically charged.
For example, suppose a pending deposit has a 20 gwei max fee and a 1 gwei priority fee. A replacement at, say, 25 gwei and 1.5 gwei raises both fields enough to meet a common replacement threshold, while the eventual charge still depends on the base fee, priority fee and gas used. If the network’s base fee rises above the replacement’s cap, it can remain stuck too.
If the transfer should not happen, submit a cancellation using the same nonce and a competitive fee. The cancellation still costs gas, and it only wins if miners or validators include it before the original; until one is confirmed, treat both as live alternatives. Do not send a separate deposit from the same account at the next nonce as a “retry”: it may queue behind the stuck transaction and later execute as an additional bridge transfer.
For recurring payouts, have the operator record the original hash, replacement hash, nonce, chain and decision in the treasury log. A second signer or automated payout worker must not independently allocate that nonce. If the case depends on the balance between transfer speed and cost, how acrossbridge balances cost, speed and risk is relevant to that policy decision; nonce replacement itself does not change Across’s quoted output or bridge fee.
What should the team verify after replacement?
Track the nonce’s canonical outcome, not only the old hash. If the speed-up is mined, its receipt should show the expected call and successful execution; if the cancellation is mined, confirm the self-send receipt and verify that the original hash did not land in the same canonical history. A replacement can be accepted by one RPC and absent from another, so broadcast acceptance is not confirmation.
Once a deposit succeeds, track that included transaction or its deposit identifier through Across’s deposit-status tools. Across relayers fill the destination-side intent after observing the source deposit; a delay in that fill is a separate state from a pending source transaction. Do not submit another source deposit merely because a dashboard has not yet updated or the destination asset has not arrived.
There is one operational edge case: the original can be included while an attempted speed-up or cancellation is propagating. The sender’s nonce resolves the race, but internal records may briefly show both transactions as pending or one as replaced. Reconcile against canonical block data before releasing a payout or asking a recipient to retry.
FAQ
Can both transactions deposit funds?
On the same EVM account and chain, two valid transactions with the same nonce are competing alternatives; only one can consume that nonce in the canonical chain. A separate retry with a different nonce can execute later and create a second deposit, so treasury systems should prevent a new nonce from being allocated until the first attempt is resolved.
What if the original transaction already has a receipt?
Once the deposit transaction is included, a same-nonce replacement cannot reverse it. Check whether execution succeeded and whether the deposit event was emitted, then track the resulting intent. If execution reverted, the transaction still consumed gas and nonce, but it did not create the intended successful deposit.
Does replacing the transaction change the Across quote?
A fee-only speed-up preserves the original calldata, so it does not recalculate the deposit’s quoted output amount or relayer fee. If the quote or fill deadline is no longer acceptable, do not silently edit calldata and assume the same intent; confirm the original outcome and create a new transfer only after reconciling the first attempt.
For treasury transfers, reuse the same nonce to resolve a pending source transaction, and create a new deposit only after the original’s canonical outcome is clear.