Hop exchange
Hop exchange quote checks and reversible exit points
A Hop exchange quote lets you test a cross-chain route against your required outcome before committing the transfer. Check the route, expected destination amount, minimum output, and reported costs together. Before the bridge send is broadcast, declining its wallet request stops that attempt; after broadcast, the source transaction hash anchors status, and confirmation ends simple cancellation.
Key takeaway: A quote is acceptable only when its minimum output meets your floor. You can still stop after approval, provided you haven't broadcast the bridge send.
Route fit and proof of the quoted state
Route fit applies to the exact combination of source asset, source network, destination network, amount, and intended output. A quote for one direction doesn't establish that the reverse direction has the same liquidity or costs. Likewise, a familiar ticker doesn't establish that two token contracts represent the same asset. The transaction assembled from the quote should preserve the selected contracts, recipient, and direction.
A live quote shows that the interface found a route under the conditions it evaluated at that moment. It doesn't promise that every amount will remain available. Pool balances, bonding liquidity, network costs, and route configuration can change before signing. If no usable quote appears, the exchange hasn't reached a sendable state. Changing a material input or waiting for conditions to change requires a fresh quote rather than an assumption about the missing route.
The minimum output as the binding constraint
The expected destination amount describes an estimate, while the minimum output sets a transaction condition. If you have a firm acceptance floor, compare it with the final minimum, not merely the larger estimate. If the minimum falls below the required amount, the reversible choice is to stop before broadcast. A deadline adds another boundary because an AMM conversion can't rely indefinitely on the pool state that produced an earlier quote.
Which quote fields change the received amount?
AMM conversion, slippage protection, bonding costs, and destination execution costs can all change the quoted destination result. Their roles aren't interchangeable. The estimated output describes the likely result under the quoted state, while minimum-output fields define how much deterioration the submitted transaction can accept.
Pool conversion and price impact
An AMM prices the conversion between a canonical token and its Hop bridge representation where that conversion forms part of the route. The unadjusted amount out reflects the pool calculation. Slippage protection then derives a lower acceptable amount, so increasing tolerance doesn't improve the pool price. It widens the range in which the swap may execute.
The origin-side conversion
On a v1 route that starts on a Layer 2 network, the origin may convert the canonical token into its corresponding hToken before the bridge movement. Pool imbalance can change that conversion result. The relevant minimum must account for the conversion and the route's other deductions instead of copying the input amount as though no exchange occurred.
The destination-side conversion
A Layer 2 destination may convert the hToken back into the destination's canonical token. A v1 transfer ending on Ethereum doesn't use a destination AMM, so destination AMM parameters don't belong to that route. This distinction matters when reading two minimum-output values: they can protect separate conversions rather than duplicate the same check.
Bonding and destination execution
The v1 SDK defines the total fee as the bonder fee plus the destination transaction fee. The bonder fee compensates the liquidity provider that fronts value on the destination, while the destination transaction component covers that on-chain action. Source-network gas remains a separate wallet cost. Comparing only the output estimate can therefore hide a meaningful difference between the amount deducted from the route and the gas paid outside it.
Authorization before commitment
An ERC-20 approval and a bridge send are separate permissions. Approval gives a specified spender an allowance; it doesn't itself initiate the cross-chain transfer. If approval confirms and you stop there, the approved tokens remain in your wallet. The allowance remains on-chain until it is used, reduced, or changed through another token transaction.
Approval creates a pause point. Before approving, you can reject the wallet request without changing on-chain state. After approval, you can still decline the bridge transaction, although changing the remaining allowance requires another source-chain transaction and its gas. A native-asset route doesn't use an ERC-20 allowance, so its wallet request should instead show the asset value attached to the bridge call. In either case, broadcasting the bridge send begins the cross-chain attempt; confirmation is the point after which the transfer can't be cancelled.
Rejecting a quote and reviewing a retry
A hypothetical minimum-output retry
All figures and quote states in this example are hypothetical. Suppose you plan to exchange 73 units of a supported source asset. You require at least 71.50 units of the intended output token at the destination, so you compare every quote with that same floor.
The first quote estimates 71.83 units but sets the final minimum at 71.34 units. The minimum misses the 71.50-unit floor by 0.16 units, so the higher estimate doesn't make the quote acceptable. You reject the unsigned request. Because you broadcast neither an approval nor a bridge transaction, there is no new on-chain exchange state to recover.
A later quote uses the same hypothetical 73-unit input, asset contracts, network direction, recipient, and slippage setting. It estimates 72.09 units and sets the minimum at 71.67 units, which clears the acceptance floor by 0.17 units. The first quote is rejected, while the second qualifies for wallet review. Any changed transaction amount, recipient, or contract would require another comparison before signing.
Evidence after submission
The source transaction hash becomes the durable starting point after broadcast. It identifies whether the source call remains pending, reverted, or confirmed. A successful source receipt proves that the source network accepted the call, but it doesn't by itself prove that the intended output reached the destination address.
The source-chain record
The confirmed receipt should correspond to the selected bridge call and sender. Its event data can identify the destination, recipient, amount, and transfer identifier used by the protocol. A reverted receipt means the bridge action didn't commit, although a separate approval transaction may still remain valid. A pending transaction sits between those states and may still be replaced if the source network and wallet support same-nonce replacement.
The destination-chain record
Completion needs destination evidence. A bonded transfer can expose a destination transaction hash, while the recipient's balance and the relevant contract events show what arrived. A status service that can't find a fresh transfer isn't equivalent to an on-chain failure; indexing and remote procedure call access can lag. The source hash, transfer identifier, and destination transaction hash form a stronger chain of evidence than an interface message alone.
What remains reversible after the source transaction confirms?
Once the source send confirms, the transfer itself can't be cancelled like an unsigned wallet request. Refreshing the interface, disconnecting the wallet, or revoking a token allowance won't pull value back from that confirmed call. At this stage, the confirmed transfer can't be backed out; recovery means following the protocol's settlement or withdrawal path. A pending status calls for evidence checks, while a reverted source receipt ends the attempted exchange before destination settlement.
Manual withdrawal when bonding doesn't finish
Bonding is the faster destination path, but an unbonded v1 transfer has a fallback. An unbonded v1 transfer can be withdrawn only after its transfer root has been set on the destination chain. The delay before that condition is met can vary with the route and chain. Repeatedly resubmitting the original send doesn't create the missing proof and may create a separate transfer.
For a Layer 2 destination, a manual withdrawal can produce the relevant hToken rather than the canonical token expected from the normal completed route. Converting that representation through the applicable AMM is a separate action with its own pool result and gas. A withdrawal to Ethereum doesn't require that destination conversion because v1 has no Ethereum-side AMM. The destination wallet also needs enough native gas for any manual claim or conversion transaction it must submit.
Exit options by transaction state
The available exit depends on the latest committed state. Before approval, every route input remains editable. After approval alone, you can stop without starting the exchange and may later alter the allowance. Once the bridge send confirms, cancellation gives way to status tracking, destination verification, or the manual withdrawal condition. After destination settlement, the relevant question is whether the actual token, recipient, and amount match the accepted transaction.
This boundary keeps the quote decision separate from recovery. Expected output helps with planning, minimum output controls acceptance, and transaction records establish what happened. A lower displayed fee doesn't compensate for the wrong token contract or an unacceptable minimum. In the worked comparison, the decisive figure remains the hypothetical 71.50-unit acceptance floor.
Before you start with Hop exchange
Can a pending source transaction be replaced to stop the send?
A pending source transaction may be replaceable before confirmation if the wallet and source network support same-nonce replacement. The replacement must reach validators before the original transaction confirms, so a wallet's cancel action isn't certain to win. Once the original bridge call confirms, another transaction can't reverse it. Check the final receipt instead of assuming that submitting a replacement completed the cancellation.
Does lowering slippage tolerance improve the AMM rate?
Lowering slippage tolerance doesn't change the rate calculated from the pool state. It raises the minimum acceptable output relative to the estimate, which can make execution fail when the price moves beyond that smaller margin. A tighter setting limits acceptable deterioration; it doesn't create a better price. Compare the resulting minimum with the amount you require before authorizing the transaction.
Are approval gas and bridge gas paid separately?
Approval gas and bridge-send gas are normally paid through separate source-chain transactions when an ERC-20 allowance is required. An existing sufficient allowance can remove the new approval step, while a native-asset send doesn't use ERC-20 approval. The quoted destination transaction component serves a different purpose because it compensates destination execution. Wallet gas estimates should therefore be read separately from the quoted destination output.
Which amount belongs in a completion record?
The actual destination amount belongs in a completion record, not the pre-submission estimate. The estimate describes the quote state, and the minimum defines an execution boundary, but neither proves the final balance change. Match the destination transaction or contract event to the intended recipient and token representation. Keep the quoted figures as decision context while recording the settled amount as the outcome.
Is a bonder delay proof that the minimum output failed?
A bonder delay doesn't by itself prove that an AMM minimum failed. Bonding can be delayed by unavailable bonding liquidity, missed events, or infrastructure problems, while a minimum-output failure normally appears through transaction execution evidence. Start with the successful source receipt and transfer status. If the transfer remains unbonded, manual withdrawal eligibility depends on the transfer root reaching the destination.
Can an old quote be reused after the amount or recipient changes?
An old quote shouldn't be treated as valid after a material transaction input changes. A different amount can alter pool output, fees, liquidity requirements, and the minimum received, while a different recipient changes the transaction that the wallet will sign. Generate and review the transaction from the revised inputs. The new wallet request should match the intended asset contracts, network direction, amount, and recipient.