A transaction replacement updates a pending payment by submitting a newly signed transaction with the same sender and nonce, so the network treats the new transaction as the old one’s successor and includes at most one.
A bridge deposit is sitting in the mempool, the destination chain is waiting, and the original fee has become uncompetitive. The useful question is not whether to “edit” that transaction—it cannot be edited—but which signed alternative will win the same nonce.
- Identity: same sender, same nonce.
- Replacement threshold: Geth’s default price bump is 10%; other clients and networks may enforce different rules.
- Maximum exposure: gas limit × max fee per gas, plus the payment value.
- Actual charge: gas used × the effective fee at inclusion, not necessarily the maximum fee.
What actually changes
The replacement is a complete transaction, not a fee-only patch. It can keep the same recipient, value, and calldata while raising maxPriorityFeePerGas and maxFeePerGas; it can also change the recipient, amount, or contract call. The signature changes because the transaction body changes, but the nonce stays fixed.
That fixed nonce creates the competition. A node will not normally keep two executable transactions from the same account with the same nonce as independent payments. It accepts one as the replacement candidate, usually only when its fee fields clear the node’s price-bump rule. If the original transaction lands first, the replacement is no longer an alternative; it becomes invalid because the nonce has already been consumed.
On an EIP-1559 chain, the fee has two economic destinations. The base fee is paid to the protocol and burned; the priority fee goes to the block proposer. The sender’s maxFeePerGas is a ceiling, not an automatic bill. A higher fee cap helps the replacement remain valid if the base fee rises, while a higher priority fee is what usually improves its position against competing transactions.
The boundary that matters for bridges
Cross-chain payment systems make the timing easy to misread. A replacement can change the source-chain transaction that will initiate a message or deposit, but it cannot rewrite a source transaction after it has been included. Once the source event is final, message delivery, relaying, and execution are separate stages.
Universal Bridge mechanics in practice sit on top of that source-side distinction.
The same separation applies when comparing Stargate Finance, Hyperlane Protocol, and IBC Protocol. The wallet can fee-bump the transaction that commits the action on the originating chain; it cannot fee-bump a packet or message that has already been committed and is merely waiting for a relayer or destination-chain execution.
Three cases where replacement earns its keep
- Speeding up a time-sensitive deposit. If a swap, liquidation, or bridge route depends on the next few blocks, raise the priority fee and, when needed, the fee cap. The payment data stays unchanged, but the proposer receives a stronger inclusion incentive.
- Canceling before inclusion. Send a zero-value transaction back to the same account with the same nonce and a sufficiently higher fee. It does not “undo” the old payment; it tries to occupy the nonce first. There is no safe cancellation once the original has confirmed.
- Correcting a pending call. If the recipient, token amount, or calldata is wrong, submit the corrected transaction under the same nonce. This is useful only while the original remains pending and only if the replacement satisfies the receiving nodes’ rules.
The practical verdict is simple: replacement is a race for one nonce, paid for through a stronger inclusion bid. Check the pending transaction’s nonce, fee fields, and chain status before signing; after confirmation, the economics and the remedy belong to the next transaction, not the old one.