Why Can a Cancellation Return a Different Token From the One Submitted?

A source-side swap can convert the submitted token into the asset that the DLN order actually locks. Cancellation returns that order asset rather than undoing the earlier swap. In API-generated transactions, srcChainTokenOut identifies the refund asset when a pre-order swap occurs; otherwise, srcChainTokenIn identifies it. The refund should be reconciled against those order terms.

Are Unfulfilled Orders Cancelled Automatically?

Automatic cancellation applies only where the integration has enabled and received approval for that feature. It covers eligible market orders, not limit orders, and assigns cancellation authority to a protocol-controlled address. The integration must correctly configure the user-controlled refund beneficiary. An open order outside that arrangement should not be assumed to have an automatic refund timer.

Does Receiving Tokens Require destination-network Gas?

An ordinary DLN recipient does not need destination-network gas merely to receive the solver’s token transfer. Creating the order requires source-network gas. Sending the received tokens afterward is a separate transaction, and manual cancellation requires a destination-chain transaction with its applicable costs. Receiving funds and having the gas needed to use them are different conditions.

What Does a Token Approval Authorize?

A token approval permits the specified contract to spend the approved token amount from the wallet. It is separate from creating a DLN order and does not prove that a transfer has started. Where an approval is required, its spender and amount should correspond to the transaction being submitted, including any applicable operating-expense amount.

Can Someone Else See a cross-chain Order?

Cross-chain order records are publicly traceable through their order identifiers and transaction records. The order-tracking API supports lookups by wallet address, creation transaction hash, or order identifier and returns order status and fulfillment details. Sharing one of those identifiers can therefore expose the associated transfer information. Moving assets between chains does not make the order private.

De bridge

De bridge Cross-Chain Transfers and Settlement

Updated · September 10th, 2026

De bridge coordinates cross-chain transfers through orders that solvers fulfill using assets available on the destination network. A solver supplies the requested tokens, while the input funds remain locked on the source network until settlement. This order-based transfer model powers the Liquidity Network, or DLN. Successful on-chain creation establishes the order; destination fulfillment delivers its requested output. An unfulfilled order has a cancellation path, subject to its authority settings and cross-chain processing. Route availability, solver liquidity, fees, and the requested output affect execution. Understanding those boundaries helps distinguish a completed transfer from an open order or a refund still moving through settlement.

The short version: Destination delivery can finish before the solver claims the source funds, while cancellation remains limited to orders that have not been fulfilled.

Destination Delivery and the Unfulfilled-Order Exit

A normal DLN transfer ends with the solver supplying the requested destination asset to the specified recipient. The source contract holds the order’s input during this process. After fulfillment, a cross-chain message authorizes release of that input to the solver. The recipient’s delivery therefore precedes the solver’s final source-side claim.

An unfulfilled order follows a different branch when its authorized destination address requests cancellation. DLN cancellation begins on the destination chain and prevents subsequent fulfillment once the cancellation takes effect. A message then authorizes the refund on the source chain. Requesting cancellation does not itself establish that the refund has arrived. Fulfillment can also occur before a cancellation succeeds, so a pending cancellation transaction cannot promise recovery. The destination order state determines which branch remains available.

Cancellation cannot reverse a fulfilled order.

Transfer Terms That Determine Whether to Proceed

A usable transfer requires a supported route and an output that meets the intended destination task. The source token, destination token, recipient, and network identifiers define that request. Matching token symbols alone does not establish matching assets. The actual token identifiers and networks matter, particularly when an application expects a specific token representation.

For a first transfer, readiness includes both delivery and recovery. The destination recipient receives the output, while cancellation authority controls the unfulfilled-order exit. These addresses can have different roles. A transfer-path decision should account for who can request cancellation and which source address receives the refund. Contract integrations can restrict the cancellation beneficiary, so that address is part of the order’s conditions.

Transfer Terms That Determine Whether to Proceed: For a first transfer, readiness includes both delivery and recovery. The destination recipient receives the output, while cancellation authority controls the unfulfilled-order exit. These addresses can have different roles. A transfer-path decision should account for who can request cancellation and which source address receives the refund. Contract integrations can restrict the cancellation beneficiary, so that address is part of the order’s conditions.

View image file

Proceed only when the selected route accepts the source asset and provides the required destination asset.
Confirm that the recipient address belongs on the selected destination network.
Check that the requested output meets the receiving application’s requirements.
Keep enough source-network gas available for the required approval and submission transactions.
Before committing funds, confirm that you can use the cancellation authority or that the integration has enabled automatic cancellation, and verify the refund beneficiary and asset.

A token can be technically representable in an order without attracting a solver. Low liquidity or an unsuitable output requirement can leave the request unfulfilled. An unavailable quote provides no basis for assuming that a manually constructed order will execute.

What Determines How Long a Transfer Takes?

DLN transfer time depends on source confirmation, solver acceptance, and destination transaction inclusion. Solvers choose their own source-finality requirements and evaluate whether fulfillment is profitable. A market order seeks execution using quoted conditions; a limit order can remain open while its conditions are unattractive. Neither an accepted submission nor an elapsed estimate proves delivery. Cross-chain messaging adds a separate timing dependency when the solver claims source funds or a cancellation returns them. Network congestion and changing execution costs can affect those operations independently.

View image file

Order Records Separate Delivery From Settlement

The order identifier connects the source creation record with destination fulfillment and later settlement records. A wallet signature alone does not establish that the source transaction succeeded. For a created order, the source record identifies the committed input and requested destination terms. Those terms provide the basis for interpreting later events. The destination contract tracks fulfillment and cancellation, so examining only the source transaction leaves the transfer’s delivery state unresolved.

For an ordinary DLN token transfer, the Fulfilled state means the requested funds have been sent to the specified recipient. Match the fulfillment transaction to the order identifier, then inspect its recipient and token transfer. A wallet balance display can omit an unfamiliar token, while an unrelated deposit can increase the same balance. The transaction record ties the delivery to the particular request.

SentUnlock and ClaimedUnlock describe later settlement progress. They follow destination fulfillment and concern release of the source funds. A transfer can therefore be complete for its recipient while the solver’s source-side settlement continues. Treating every intermediate settlement state as missing delivery can lead to an unnecessary duplicate order.

A cancellation request is not a completed refund.

Refund reconciliation requires the source-side cancellation claim and the resulting credit to the designated beneficiary. The tracking data distinguishes destination cancellation, the cancellation message, and the source refund claim. Before another submission, unresolved status warrants inspection of the existing order. Waiting for a confirmed delivery or confirmed refund avoids treating the same committed funds as available twice.

Which Costs Affect the Amount Received?

A DLN quote reflects protocol fees, solver margin, operating expenses, and any swaps required by the route. Source-network gas remains relevant, including token approvals when required. Affiliate charges and hook execution rewards can add costs in integrations that use them. DLN protocol fees are configurable and must be read from the applicable contract state rather than treated as permanent constants. Source or destination swaps introduce their own slippage conditions. Refreshing a stale quote before submission can change the estimated output. After creation, market changes can make the order unattractive to solvers without automatically changing its requested output.

View image file

Completion Conditions for Messaging, Hooks, Same-Chain Swaps, and Asset Porting

Cross-chain messaging supports authenticated data and remote contract calls beyond token transfers. The Messaging Protocol, or DMP, supplies this infrastructure beneath the transfer products. Validators wait for the applicable finality conditions before signing messages. Receiving contracts must handle those messages correctly, including origin authentication where their logic requires it. A delivered message establishes a different outcome from a token order fulfilled by a solver.

DLN integrations can attach hooks that perform destination contract actions. Their execution conditions matter when the intended result includes a deposit or another application operation. Token delivery alone does not establish that every attached action succeeded. The hook’s configuration and execution record determine that additional result. Same-chain swaps are also supported, although they do not involve a source-to-destination network transfer.

dePort uses a separate lock-and-mint mechanism to create synthetic asset representations on supported destination chains. The original asset remains collateral on its native chain, while the destination receives a corresponding representation. That asset model differs from receiving solver-supplied liquidity through DLN. The receiving application must accept the representation delivered by the chosen mechanism; successful bridging alone does not establish that compatibility.

Still have questions?

Why Can a Cancellation Return a Different Token From the One Submitted?: A source-side swap can convert the submitted token into the asset that the DLN order actually locks. Cancellation returns that order asset rather than undoing the earlier swap. In API-generated transactions, srcChainTokenOut identifies the refund asset when a pre-order swap occurs; otherwise, srcChainTokenIn identifies it. The refund should be reconciled against those order terms.
Are Unfulfilled Orders Cancelled Automatically?: Automatic cancellation applies only where the integration has enabled and received approval for that feature. It covers eligible market orders, not limit orders, and assigns cancellation authority to a protocol-controlled address. The integration must correctly configure the user-controlled refund beneficiary. An open order outside that arrangement should not be assumed to have an automatic refund timer.
Does Receiving Tokens Require destination-network Gas?: An ordinary DLN recipient does not need destination-network gas merely to receive the solver’s token transfer. Creating the order requires source-network gas. Sending the received tokens afterward is a separate transaction, and manual cancellation requires a destination-chain transaction with its applicable costs. Receiving funds and having the gas needed to use them are different conditions.
What Does a Token Approval Authorize?: A token approval permits the specified contract to spend the approved token amount from the wallet. It is separate from creating a DLN order and does not prove that a transfer has started. Where an approval is required, its spender and amount should correspond to the transaction being submitted, including any applicable operating-expense amount.
Can Someone Else See a cross-chain Order?: Cross-chain order records are publicly traceable through their order identifiers and transaction records. The order-tracking API supports lookups by wallet address, creation transaction hash, or order identifier and returns order status and fulfillment details. Sharing one of those identifiers can therefore expose the associated transfer information. Moving assets between chains does not make the order private.