Debridge swap
Debridge swap supports token conversion within and across supported chains
Debridge swap exchanges tokens on supported chains, using solvers to supply the requested tokens for cross-chain orders. Same-chain trades use a separate execution path. Availability depends on the selected assets and an executable route, while completion requires a successful transaction and the corresponding output at the intended recipient.
Same-chain conversion and cross-chain delivery
A same-chain swap changes the asset held on one network; a cross-chain exchange delivers the selected asset on another supported network. The same-chain service compares routes through trading aggregators and prepares a transaction for execution. It does not create the on-chain order that the cross-chain liquidity network uses. That distinction matters when interpreting a transaction history: similar-looking entries can represent different mechanisms.
Cross-chain trades use the liquidity network, known as DLN. Market orders use quoted terms intended to attract prompt fulfillment. Limit orders express a target exchange condition and require a willing solver, meaning a participant that supplies the destination liquidity. Available order controls depend on the product surface and selected assets. Neither a market quote nor a limit condition establishes that someone has already accepted the trade.
Route availability and asset identity
Support for a network does not establish that every token on it has an executable route for the requested amount. Liquidity and the selected assets determine whether the service can construct a suitable exchange. Asset identity includes its network and the applicable contract address, mint address or native-asset identifier, rather than its displayed symbol alone. The destination recipient must also be valid for the selected network. A route that returns a different token representation or delivers to a different address does not meet the original request, even if the symbols look familiar.
An unavailable route calls for a fresh quote or a deliberate change to the requested exchange. Changing the destination asset changes what the transaction accomplishes.
What does the quote commit you to?
A quote commits no funds by itself; it describes proposed exchange terms before the wallet authorizes and submits the relevant transaction. Review the input debit alongside the output asset, destination network and recipient. The executable transaction must correspond to those selections. A display estimate and a signed transaction are different objects, especially if the quote changes while authorization remains open.
For a same-chain swap, the expected output is an estimate, while the minimum acceptable output sets the execution threshold. The expected amount reflects the route estimate. The minimum encodes the permitted deterioration under the selected slippage tolerance. Cross-chain DLN orders specify the destination amount that fulfillment requires. This protects the order's delivery condition without compelling a solver to execute it.
Quotes reflect market conditions when generated. A delay can change route availability or operating expenses, so refreshed transaction terms need another review before signing.
Approval and transaction authority
When the selected token requires a spending allowance, the executing contract needs sufficient permission before it can transfer the input amount. On networks using the Ethereum Virtual Machine, ERC-20 approvals authorize a particular spender. The approval amount and spender therefore belong in the review, alongside the main transaction's destination and native-token value. An approval transaction grants permission; it does not establish that the exchange has happened. Native-asset transactions follow their own payment requirements and do not use an ERC-20 allowance for that native asset.
The wallet signature authorizes the transaction that it signs, including its contract calls and attached value. A refreshed quote can require a different input debit when operating expenses change. An allowance that covered the earlier estimate may then be insufficient. Cross-chain orders also carry authority addresses for order management. Control of the receiving address should not be assumed to grant cancellation rights when the order names a different destination authority.
Solver fulfillment and source settlement
Cross-chain fulfillment requires a solver to supply the requested destination tokens while the source contract holds the order's committed input. For an order without a hook, the destination contract transfers the solver-supplied tokens to the recipient when it fulfills the order. The solver can then initiate the cross-chain message that releases the committed source funds. Receipt by the user and settlement to the solver are separate events. A successfully confirmed source-side order-creation transaction proves that the order exists; it does not, by itself, prove delivery. The destination fulfillment record establishes which order received its output.
Receipt confirmation before another submission
Consider a hypothetical cross-chain exchange with an available quote, supported input and output tokens, and a recipient that the sender controls. Assume the sender accepts the quoted terms and the wallet has the required authorization and transaction funds. No particular token, chain, amount or completion time is assumed. The sender submits the order-creation transaction. Successful confirmation establishes that the input has been committed for fulfillment.
In the completed case, the destination transaction records fulfillment of that order and delivery of its specified output to the intended recipient. Matching the order identifier, token and recipient establishes the connection between the original commitment and the received funds. The sender can reconcile the exchange without submitting it again. A wallet display that has not refreshed does not overturn a matching on-chain transfer record.
If the record instead shows only source-side creation, the same conclusion does not follow. The sender keeps tracking the existing order rather than treating it as a failed submission and creating a duplicate. A prolonged unfulfilled order may require cancellation through its authorized destination address. A cancellation request changes the next action, but the sender must still distinguish that request from the eventual return of funds on the source chain.
What costs change the amount you receive?
The total cost depends on the execution path, protocol charges, network transactions and any additional fees included by the application offering the quote. Cross-chain DLN pricing accounts for the solver's operating expenses and margin as well as order-creation fees. The sender also pays the source transaction's network cost. These components need not all appear as separate wallet deductions: some affect the exchange terms, while others require native tokens alongside the input asset.
Same-chain estimates describe their own route and transaction costs, so cross-chain fee assumptions do not transfer automatically. An application may also include an affiliate fee. Compare quotes for identical input and output selections, using the final token amount and any separately payable costs. A refreshed estimate can change either side of that comparison. A single percentage cannot describe the total expense when network charges and route execution also contribute.
Cancellation and the limits of reversal
An unfulfilled cross-chain order has a cancellation path that differs from reversing a completed token exchange. The destination contract permits cancellation only while the order is neither fulfilled nor already cancelled. The designated destination authority initiates the cancellation transaction. Cross-chain messaging then enables the return of the locked funds on the source chain. The cancellation beneficiary and authority fields determine the relevant addresses, so the original sender and refund recipient should not be treated as interchangeable without examining the order.
The returned locked funds include the protocol and affiliate fees associated with the order. Cancellation nevertheless has execution costs. Its transaction can require destination gas, a messaging payment and funding for the source-side claim. Any swap performed before the order was created also matters: returning the locked order asset does not necessarily recreate the asset that the wallet originally supplied.
Fulfillment closes this cancellation path. Receiving a different asset afterward requires another exchange; cancellation cannot undo the completed delivery.
Debridge swap: what people ask
Are limit orders available for same-chain swaps?
Same-chain swaps do not support the cross-chain limit-order feature. Their execution uses a quoted transaction and slippage conditions on one network. A minimum output protects that transaction's acceptable result; it does not turn the swap into a resting order that waits for a future target price.
Do I need destination gas tokens to receive a cross-chain swap?
Ordinary cross-chain fulfillment does not require the recipient to fund the solver's destination transaction separately. The sender needs the funds required for source-side submission, and the quote accounts for solver expenses. A later transaction made by the recipient, including an authorized cancellation where applicable, has its own network payment requirements.
Which swap details are publicly visible?
On-chain order and transaction records expose addresses, asset movements and execution status. Cross-chain order tracking connects source creation with destination fulfillment, so using different addresses does not make that exchange private. Wallet addresses are public identifiers, even when the transaction record does not contain a person's name.
Does the swap require deposits into a shared bridging pool?
DLN cross-chain orders use liquidity supplied by solvers rather than a shared pool of user deposits. The source contract still holds each order's committed funds until settlement or cancellation releases them. The absence of pooled liquidity does not eliminate contract, network or cross-chain messaging risks.
Can an exchange trigger another contract action?
An integration can attach a hook that requests an additional on-chain action during or after fulfillment, depending on its configuration. That makes the requested outcome broader than a token transfer alone. A fulfilled order does not by itself prove that a deferred hook has executed. An optional-success hook can also fail and send the tokens to its configured fallback address. Confirm the requested action in its execution record; an ordinary transfer does not imply an additional deposit, trade or contract call.