Arbitrum bridge reversal limits and stopping points

Destination compatibility before commitment

A usable transfer path must deliver the intended asset to an address that you can access on the destination network. For transfers between Ethereum and Arbitrum One, Ethereum is the parent chain and Arbitrum One is the child chain. Confirm the selected chain and recipient before authorizing movement. For tokens, the gateway's paired contract determines the destination representation; matching ticker text does not establish compatibility. Contract accounts also require attention because some parent-to-child calls apply address aliasing. Stop while the request remains unsigned if the receiving account or destination asset does not meet your intended use.

Different ways to stop, with different effects

Rejecting an unsigned request prevents that request from creating an onchain transfer. Editing its amount or destination also remains possible before authorization. These choices preserve the source balance associated with that transfer, although earlier transactions may already have incurred costs or granted permissions.

After authorization, first establish what the wallet actually submitted. A token approval, a deposit, and a withdrawal change different states. The available action follows that state, not the wording of a button or notification.

Revocation concerns permission, while ticket cancellation concerns an existing destination message. Neither provides a general refund mechanism for every bridge transfer.

Can a pending bridge transaction still be cancelled?

A cancellation attempt can work while the source transaction remains pending, if the wallet and network support replacement. For an ordinary account transaction on Ethereum, replacement uses the same nonce, the account's transaction sequence number. The cancellation replacement must come from the same account, omit the bridge call, and use acceptable fee settings. Clicking cancel alone does not establish which transaction the network will include.

A wallet cannot reverse a confirmed source transaction through pending-transaction replacement. Check the source-chain receipt to confirm that the cancellation replacement was included instead of the original bridge transaction. A bridge interface may continue showing a pending transfer after the source transaction has succeeded, because destination processing remains incomplete. That condition no longer presents the same opportunity to replace the source transaction.

Approval cleanup after abandoning a deposit

Disconnecting the wallet leaves existing token allowances in place. An allowance gives a specified spender permission to move tokens within its authorized amount. If you abandon a token deposit after approving it, inspect the remaining allowance and revoke it if you no longer want that permission. Revocation requires its own onchain transaction and takes effect through execution. It cannot recover tokens that the spender already transferred. Native ETH transfers do not use ERC-20 allowances.

Withdrawal waiting time is not a cancellation window

An executed native withdrawal starts a settlement process that the sender cannot cancel through the bridge's ordinary withdrawal flow. For ETH, the withdrawal burns the amount on the child chain and creates a message for the parent chain. Leaving that message unclaimed does not restore the original child-chain balance.

Open full-size image

The Outbox requires confirmation of the assertion containing a withdrawal before it can execute that withdrawal. This rule differs from the estimated time remaining. Assertion publication, the applicable dispute period, confirmation, and any dispute affect readiness. A countdown does not itself authorize execution, and extra gas cannot replace the required confirmation.

If retaining immediate access to the source balance matters, defer the withdrawal before submission. An alternative bridge may offer different settlement conditions, but its available route and terms need separate assessment. Starting another transfer does not cancel an existing canonical withdrawal or make its committed funds available elsewhere.

Retryable cancellation has a narrower meaning

A retryable ticket represents a destination call that can outlive a failed execution attempt. Its cancellation function concerns that ticket and its escrowed call value. It does not reverse the parent-chain transaction that created it, and its existence does not mean every deposited asset qualifies for a refund.

Execution and cancellation authority

Retrying the intended call

Anyone can attempt redemption of an existing redeemable ticket. Redemption retries the original destination call with gas supplied for the attempt. It does not provide an opportunity to replace the recipient or rewrite the transfer. Investigate the failure before paying for another attempt that encounters the same underlying problem.

Cancelling through the beneficiary

The ticket's beneficiary alone can call its cancellation function. Successful cancellation refunds the ticket's call value to that beneficiary on the child chain. The beneficiary address forms part of the ticket's existing configuration; reconnecting a different wallet does not grant that wallet cancellation authority.

Expiry and token deposits

For a standard ERC-20 gateway deposit, the parent gateway holds the tokens while the destination call mints their paired representation. Cancelling the retryable does not instruct that parent gateway to release its tokens. A refund of call value therefore does not establish recovery of the deposited token amount. Resolve the gateway-specific consequences before deliberately cancelling or allowing expiry.

A ticket also has an expiry timestamp, which an eligible keepalive transaction can extend. Treat that timestamp as the deadline for the particular ticket rather than calculating it from a remembered default. The ArbRetryableTx methods getTimeout and getBeneficiary expose its timeout and beneficiary. A simple Inbox.depositEth deposit follows a separate native-deposit mechanism and does not create a retryable ticket.

Records that survive leaving the bridge

The initiating transaction hash remains the starting point for reconciling a transfer after leaving the interface. Keep its network, sender, recipient, asset, and amount with the hash. Source success establishes that the source operation executed; the corresponding destination record establishes what happened afterward. An empty activity panel does not replace either record.

Open full-size image

Retryable creation and successful redemption have distinct records. A withdrawal likewise has its initiating child-chain transaction and its later parent-chain execution. Compare the relevant message and destination execution before submitting another transfer. Repeating a deposit creates another request rather than repairing the first one. For a simple ETH deposit, the associated child-chain transaction identifies the credit on Arbitrum One.