Hop exchange

Hop exchange first-use checks, completion proof, and fallback paths

A first Hop exchange can stop at the quote or wallet prompt before funds leave the source chain. Confirm the chosen asset, source and destination networks, recipient, amount, minimum output, and live route costs, then read the wallet request before signing. Once the source transaction confirms, it can't be edited or canceled through the interface. Keep its hash and follow the corresponding destination record. Source confirmation proves that the bridge action executed on the source chain, not that the recipient received the output. Completion needs a destination transaction or withdrawal record that names the intended recipient and output. If a bonder doesn't deliver promptly, the transfer can later be withdrawn manually after its Transfer Root reaches the destination, though an L2 fallback may leave hTokens that require a separate conversion.

In short: A first Hop exchange should end with destination-chain evidence, while an unbonded transfer stays recoverable after its Transfer Root arrives.

Set route boundaries before the wallet prompt

The route becomes reviewable only after the source network, destination network, asset, amount, and recipient all describe the intended transfer. Confirm that the live interface produces a quote for that exact combination. A route available in one direction may not be available in reverse, and a familiar token symbol doesn't establish that the selected contracts represent the intended asset on both networks. The connected wallet also needs the source network's gas asset before any approval or transfer can confirm.

Read the expected output beside the minimum output, not as a substitute for it. The estimate reflects the quoted route at that moment, while the minimum sets a lower condition for an automated market maker (AMM) conversion when one applies. Reported costs may reflect pool conversion, bonder compensation, and destination execution. Source-chain gas remains a separate wallet expense. If the amount, recipient, network, or asset changes, discard the old quote and review the replacement from the beginning.

Where does each action stop being reversible?

Reversibility narrows as the transfer moves from editable route fields to confirmed on-chain records. The following stages separate a rejected request from an action that now needs reconciliation or recovery.

Open full-size image

Approval and transfer are separate actions. A confirmed approval authorizes the wallet-displayed spender to transfer up to the approved amount of an ERC-20 token, but it doesn't show that a cross-chain transfer began. The source bridge receipt marks the stronger boundary. After that point, changing a route field creates a new transfer rather than editing the confirmed one.

Review the quote, approval, and transfer separately

Keep one route and recipient unchanged between the final quote and wallet confirmation so the first attempt remains easy to verify. Review any wallet-displayed contract, amount, and network against the quote. If one input changes, request a new quote because the expected output, minimum output, route costs, or available liquidity may also change. Don't carry an earlier estimate into the revised request.

An ERC-20 approval deserves its own review. Check the spender and authorized amount shown by the wallet, then retain the approval receipt if the transaction confirms. The following bridge request is a second on-chain action with different consequences. Rejecting that second request leaves the approval in place but sends nothing across networks; revoking the allowance later doesn't reverse a transfer that already confirmed.

What proves that the exchange finished?

A finished transfer has a confirmed source bridge transaction and a successful destination delivery record for the same transfer.

A bonded transfer-status record includes a destination bond transaction hash as evidence that the transfer was received on the destination. Match that record to the source hash, destination network, recipient, and asset rather than relying on a progress message alone.

On the destination, inspect the successful transaction receipt and the token movement to the recorded recipient. A wallet balance can include older holdings or unrelated deposits, so its total isn't a precise bridge receipt by itself.

Keep the source and destination hashes together. The first proves that the bridge action entered the source chain; the second proves that destination execution occurred. If fallback withdrawal replaces bonding, its successful receipt becomes the destination evidence, followed by any separate hToken conversion that the intended output requires.

Read a stalled transfer before acting

A missing destination receipt doesn't reveal the cause by itself. Start with the source record. A pending source transaction hasn't established a confirmed bridge action, while a reverted one didn't complete that action. If the source bridge transaction succeeded, use its hash to locate the transfer status and preserve the original route details before considering another send.

Open full-size image

An unbonded status can describe a transfer that is still pending or one that can't be bonded. Low destination liquidity, an unavailable bonder, or an incorrectly supplied bonder fee can delay or prevent the fast path, but the status alone doesn't distinguish those causes. Broadcasting another transfer at this stage creates a separate obligation and may duplicate the intended movement. Continue tracking the confirmed transfer until it bonds or becomes eligible for manual withdrawal.

When is manual withdrawal available?

Manual withdrawal becomes available only after the Transfer Root containing the transfer has been set on the destination chain. Root propagation may take hours or days, depending on the route and asset. A confirmed source transaction therefore doesn't make the fallback immediately usable.

Use the original source transaction hash to locate the transfer and its proof. If the destination hasn't received the root, waiting preserves the existing claim; changing the old transaction isn't possible. Once the proof is available, a user or relayer can submit the destination withdrawal. The submitting wallet needs that network's gas asset, while the transfer data fixes the recorded recipient and amount.

The withdrawal receipt then replaces the absent bond transaction as completion evidence. This path trades the bonder's faster delivery for a proof-based exit from the same confirmed transfer.

Reconcile hTokens with the intended output

On an L2 destination, manual withdrawal can produce the corresponding hToken before the usual conversion into the canonical token. A successful withdrawal receipt and the corresponding hToken balance change prove that the withdrawal succeeded, but it may not be the token representation expected for later use. Converting it through the relevant Hop AMM is another destination-chain transaction with its own quoted output, minimum output, and gas requirement.

A manual withdrawal to Ethereum doesn't need that additional hToken conversion because the withdrawal returns the underlying token directly. In either case, compare the received token contract and balance change with the intended output. A matching ticker alone can't settle the distinction between an hToken and its canonical counterpart.

Match the next action to the last confirmed state

The latest successful receipt determines the smallest recovery step. A quote with no signature can simply be replaced. A confirmed approval with no bridge transaction leaves an allowance but no cross-chain transfer. A reverted bridge send needs a fresh quote before another attempt. A confirmed source send with no destination receipt should remain tied to its existing hash until bonding completes or the Transfer Root enables withdrawal.

Open full-size image

Once destination bonding or withdrawal confirms, reconcile the recipient, asset representation, and credited amount, then stop tracking the transfer as pending. If manual withdrawal delivered an hToken and the intended result is the canonical token, perform only that conversion. Recovering the confirmed transfer through its proof preserves one transfer history; sending again creates a second, unrelated transfer with its own costs and outcome.

Things people ask about Hop exchange