Debridge finance
Debridge finance separates source confirmation from destination delivery.
Last updated
Debridge finance confirms destination delivery through fulfillment of a matching order, rather than through the source transaction alone. For a straightforward token transfer, the destination record must match the intended chain, token, recipient, and amount. A successful order-creation operation establishes that the order exists. The solver’s later claim of the input funds completes a separate settlement obligation.
This distinction matters when a transfer appears successful in one view while the expected balance remains absent elsewhere. The original order connects those observations. Its terms identify the expected delivery, and its destination execution determines whether another transfer would duplicate an existing purchase.
Compare source receipts with destination records
A source receipt, an order tracker, and a destination transaction answer different questions about the same exchange. The receipt establishes what executed on the sending chain. The tracker associates an order with its reported lifecycle state. Destination execution supplies the evidence that the requested delivery occurred.
For direct contract inspection on EVM chains, the destination contract exposes order status through DlnDestination.takeOrders(). Its fulfillment event also identifies the affected order. These records provide more specific evidence than a successful transaction containing an unrelated operation. The inspection must use the intended destination chain and the applicable protocol contract.
Creation, fulfillment, and settlement occupy different stages
The deBridge Liquidity Network (DLN) separates the commitment of input assets from their exchange against destination liquidity. The solver supplies the destination assets, then claims the reserved input through the settlement process. The table describes an ordinary token-delivery order without an attached destination action.
| Stage | Observable evidence | Chain and asset scope |
|---|---|---|
| Order creation | The source contract records the order and reserves its input. | The order’s input asset on the source chain, after any source-side swap. |
| Destination fulfillment | The solver supplies the requested output and the destination contract records fulfillment. | The specified output asset and recipient on the destination chain. |
| Solver settlement | An unlock message enables the solver to claim the reserved input. | The order’s locked input asset on the source chain. |
| Delivery boundary | Matching destination fulfillment establishes the recipient’s delivery. | Source settlement concerns the solver’s input claim. |
The input debit associated with order creation belongs to the source-side record. Treating it as proof of destination receipt skips the transaction that performs the delivery.
Keep the committed order alongside the quote
The committed order provides a firmer comparison point than a quote that the interface can refresh. Before submission, check that the selected chains, tokens, amounts, and recipient match your intended transfer, and preserve those terms. After creation, retain the actual order data and its identifier, together with the creation transaction hash. The recorded recipient and destination asset define what successful delivery must satisfy.
A screenshot helps explain what the interface displayed, but the created order establishes what the contract accepted. Any difference between the intended terms and that record deserves attention before interpreting a later transfer. A solver can fulfill an order exactly as written even when the user intended another recipient. Contract-level success does not resolve that earlier selection error.
Does the received transfer match the order?
A received transfer matches only when its order association and effective delivery terms agree with the committed exchange.
Match the destination before comparing the amount
Chain identity belongs to the order, alongside the destination token address and receiver. Compare those fields with the fulfillment record. A matching display name or an incoming transfer near the expected time does not establish the relationship. Keep the original transaction and order identifier attached to the comparison.
The receiving account
Use the recipient recorded in the order. The sending wallet and receiving account can serve different roles, so inspecting the sender’s destination balance can answer the wrong question.
The token amount
Compare quantities in consistent token units. A rounded wallet display can conceal a small difference, while a raw integer requires the token’s decimal interpretation. Include any valid on-chain amendment that changed the required output.
Amount changes require an authorized on-chain amendment
An order’s original output amount does not always remain its effective fulfillment requirement. The EVM destination contract supports an authorized reduction through patchOrderTake(). The designated destination order authority can apply it while the order remains unfulfilled and uncancelled.
The contract records the reduction against the existing order identifier and checks fulfillment against the adjusted amount. Reconciliation must therefore account for that amendment instead of automatically treating every difference from the creation amount as underdelivery. Refreshing a quote is a different operation; it does not itself apply this contract change.
What does a successful source transaction prove?
A successful source transaction proves that its included operations executed on that chain, so its contents determine whether it created an order. In the EVM integration, successful order creation emits CreatedOrder with the order structure and identifier. A separate token approval does not supply that creation event.
Source confirmations also influence when a solver accepts the risk of acting. Solvers choose their own source-finality requirements before committing destination liquidity. Additional source confirmations can strengthen confidence in order creation without supplying the missing destination fulfillment record.
Wallet totals can hide an otherwise matching delivery
A wallet’s current total reflects more than one transaction. It can include earlier holdings, later spending, and unrelated receipts.
For reconciliation, the amount credited by the identified fulfillment transaction is more informative than the difference between two widely separated balance snapshots. That comparison isolates the order’s delivery without attributing every intervening movement to the bridge. A matching token quantity alone remains insufficient when the transfer belongs to another order.
A missing entry in the wallet interface and a missing transfer in destination execution are different observations. The first concerns presentation; the second concerns evidence of delivery. Preserve that distinction when deciding whether the discrepancy requires a display correction or further transaction investigation.
For integrations, the tracking response exposes the fulfillment transaction hash. That makes it possible to inspect the transaction associated with the order rather than selecting an incoming payment by appearance.
Unfilled orders need a confirmed exit before replacement
An unfilled order can remain available for a solver to execute. Solvers assess profitability and may reconsider an order after market conditions change. A delay therefore does not establish that the order has permanently failed. Time sensitivity changes the user’s decision, but elapsed time alone does not cancel the commitment.
Cancellation starts on the destination chain and must satisfy the order’s authorization and state requirements. The cancellation message then enables recovery of the reserved order input on the source chain. If a source-side swap converted the user’s original token into a reserve asset, cancellation returns that reserve asset; it does not reverse the swap. Initiating cancellation and receiving those funds are separate events. A replacement intended to reuse that input needs the completed return, not merely a cancellation request.
Read fulfillment separately from solver settlement
The status Fulfilled identifies completed destination fulfillment. SentUnlock indicates that the subsequent unlock procedure has started. ClaimedUnlock records the solver’s completed claim of the source input. These labels describe different obligations, even though order-tracking integrations treat all three as successful user-level completion states.
After successful fulfillment, the solver initiates a cross-chain message to unlock the reserved input assets on the source chain. The recipient does not need a second token delivery merely because that claim remains unfinished. For a straightforward transfer, matching destination receipt resolves the delivery question.
How do hooks change the evidence of completion?
Hooks add an attached destination action whose outcome needs inspection alongside order fulfillment. A token-delivery status alone does not describe every result of that action. Depending on the hook, the intended outcome may involve a contract interaction or distribution rather than an unchanged balance in one wallet.
The order API reports external-call state separately, including awaiting execution, completed, failed, and cancelled states. Those states belong to the attached operation. They must not be confused with cancellation or fulfillment of the underlying order. Reconciliation follows the actual action and its resulting transfers or contract state, without assuming that every hook uses identical failure handling.
Order identifiers prevent unrelated transfers from closing the record
The deterministic orderId derives from the order’s encoded properties. Both sides can reproduce that identity, allowing settlement to associate destination fulfillment with the original source commitment. A transfer involving similar assets does not satisfy that association merely because its amount looks familiar.
A mismatched recipient or token belongs in the unresolved record until the corresponding order and execution explain it. Creating another order does not repair that mismatch. The concrete completion evidence is the matching delivery, including any authorized amendment and attached action, or the completed return of the locked order input after cancellation.
Debridge finance - your questions answered
Can one creation transaction contain several DLN orders?
Yes, a creation transaction can contain multiple orders. The tracking API distinguishes a lookup that returns the first order from a lookup that retrieves all order identifiers associated with the transaction. An integration investigating delivery must select the intended order before interpreting its status. Otherwise, another order’s successful fulfillment can obscure the unresolved transfer.
Where does an integration find the destination fulfillment transaction hash?
The tracking response provides it in the order’s fulfilledDstEventMetadata.transactionHash field. Pair that hash with the recorded destination chain when inspecting execution. This associates the investigation with the fulfillment transaction for the selected order, rather than with the source creation transaction or a wallet transfer that happens to resemble the expected receipt.
Does polling an order’s status submit another swap?
Reading order status does not create another swap. A status query retrieves information about an existing identifier; order creation requires a separate transaction. Repeated reads can help track an unresolved order without creating another funding commitment, provided the application performs only the read operation. A wallet request to authorize a transaction is a different action.
Is a screenshot of the quote enough to reconstruct the order identifier?
A quote screenshot generally lacks the complete encoded properties needed to reconstruct the deterministic order identifier. Those properties extend beyond visible amounts to include the maker, chain identifiers, authority fields, and other order data. Preserve the actual identifier returned through order creation or tracking instead of attempting to infer it from the displayed quote.
What makes a pending order attractive to a solver later?
Changed market conditions can make an order profitable after a solver previously ignored it. Solvers evaluate whether the difference between the supplied input and requested output covers their costs. They may reassess pending orders as those conditions change. This explains why an unresolved order can execute later, even when an earlier status check showed no destination fulfillment.