When a Replaced Transaction Breaks a Bridge Quote

Replacing a pending source-chain transaction can change whether a bridge receives the deposit described by its quote. On Ethereum-style accounts, a transaction’s nonce identifies its position in the sender’s sequence; two valid transactions from that account with the same nonce are alternatives, and at most one can be included in the canonical chain. The mechanics behind Biswap’s cross-chain swaps show why the quoted route and the source-chain call need to be considered together. A replacement changes the transaction the chain may execute, while the bridge’s application decides how to recognize and process that execution.

What does replacing a pending transaction change?

On Ethereum, a replacement is a newly signed transaction from the same account with the same nonce. Nodes may accept it into their transaction pools under local replacement policies, commonly requiring a higher fee bid. That policy helps nodes decide which candidate to keep; it is not a consensus rule that changes the transaction already recorded on-chain.

With an EIP-1559 type-2 transaction, the signed fields include the nonce, destination, value, calldata, gas limit, max fee per gas and max priority fee per gas. A speed-up usually changes the fee fields while keeping the call’s destination, value and calldata. The transaction hash changes because the signed transaction changed, but its intended contract call remains the same. A cancellation usually submits a zero-value transaction to the sender’s own address with that nonce. If it is included first, the original transaction can no longer execute with that nonce.

A replacement can also change the destination, value or calldata. In that case, it is not merely a faster version of the bridge call: it is a different call competing for the same nonce. If that replacement is included first, the bridge deposit encoded by the original call does not happen. A transaction in a wallet’s “pending” view is only a candidate; until inclusion, the eventual call is unresolved.

How can that disrupt a bridge quote?

A bridge quote describes an intended transfer under a particular set of parameters, but the quote’s expiry and enforcement depend on the route. A user interface may show a time limit, while the transaction may separately encode a deadline or minimum output that a contract checks. Some routes use off-chain quotes or solver terms that are checked during execution. There is no single bridge-wide quote rule.

The risk appears when the bridge’s quote, the signed source transaction and the bridge’s tracking record stop referring to the same action. For example, an app may associate a quote with the original transaction hash. A fee-only replacement has a new hash even if it still calls the same bridge contract with the same calldata. If the app or relayer does not discover the new hash, its status display may remain stale. If the replacement changes calldata, it may no longer emit the source event or satisfy the route’s expected parameters at all.

There is a second timing edge. A fee-only replacement can help a transaction get included sooner, but it does not renew an expired quote or extend a deadline encoded in the call. If execution checks a deadline and the replacement lands after it, the call may revert. If the quote was only an interface timer and the contract has no corresponding deadline, expiry may instead affect the application or solver’s willingness to process the order. The exact failure depends on where the route enforces validity.

What should users and bridge interfaces verify?

Before replacing a bridge transaction, compare the replacement’s call data and value with the transaction you intend to complete, then check whether the quote or on-chain deadline remains valid. A speed-up that preserves the bridge call is materially different from a cancellation or an edited transaction, even though each may use the same nonce.

• Confirm the sender and nonce match the pending transaction; otherwise, the new transaction does not replace it.
• For a speed-up, check the destination, value and calldata as well as the fee fields. Matching the hash is impossible because the replacement has a different hash.
• After submission, track the replacement hash and verify the source-chain receipt and bridge event. A wallet’s pending indicator is not proof that the bridge deposit occurred.
• If a cancellation or edited replacement is mined, do not assume the original quote still represents an active transfer. Recheck the bridge’s status and obtain a fresh quote before submitting another deposit.

Once a source transaction is included, its nonce is consumed on that chain. A later transaction using the same nonce cannot simply undo the included deposit; a chain reorganisation is a separate event that can remove an inclusion from the canonical history. For a confirmed deposit, follow the bridge’s recovery or settlement process rather than trying to replace the source transaction.

For most users, a fee-only speed-up is the appropriate replacement when the goal is to preserve a bridge deposit and the quote remains valid. Cancellation is a different decision: it abandons that nonce’s original call if the cancellation wins. The practical check is simple—verify which transaction was included, whether it emitted the expected bridge event, and whether the route’s validity conditions still hold.