Debridge finance
Debridge finance connects cross-chain swaps through solver-funded liquidity.
Last updated
Debridge finance enables cross-chain token exchanges through solvers, which supply the requested assets on the destination blockchain. Its deBridge Liquidity Network, or DLN, temporarily holds an order’s input funds until fulfillment and settlement or cancellation. The wider infrastructure also supports messages between smart contracts and wrapped-token transfers through dePort. These functions have different dependencies: a swap needs willing liquidity, a message needs validation, and a wrapped asset depends on its backing.
Swaps, messages, and token representations serve different purposes
The intended destination result determines which function applies: receiving an existing token, exchanging assets within one network, executing a remote instruction, or creating a backed representation. DLN handles liquidity exchange. The deBridge Messaging Protocol, or DMP, carries authenticated messages between supported blockchains. dePort uses that messaging infrastructure for its lock-and-mint bridge.
| Function | Asset or execution scope |
|---|---|
| DLN cross-chain exchange | Input assets on one supported chain exchange for the requested assets on another, subject to solver fulfillment. |
| Same-chain swap | Token conversion stays on one network and uses available swap routes. |
| DMP messaging | Messages and contract instructions pass between supported chains. |
| dePort bridging | Locked native-chain tokens back synthetic deAssets on secondary chains. |
| Selection criterion | Match the function to the required destination asset or contract action. |
A dePort representation carries a different dependency from an asset supplied through a DLN swap. Its backing remains locked on the native chain. That distinction matters when assessing redemption and whether the receiving application accepts the resulting token.
Wallet funding and authorization come before order creation
A token balance alone does not cover every prerequisite for creating an order. The source wallet also needs the native currency required by the transaction, including network gas and applicable protocol charges. The destination recipient must match the intended account and chain.
Balances and transaction value
The transaction that the application prepares specifies its required native-currency value. This requirement can remain positive even when the input asset is a separate token. Insufficient native currency can prevent submission despite an adequate trading balance. The requested input amount and transaction value therefore describe different funding requirements.
Approval and the commitment boundary
For an ERC-20 input, the spending contract needs sufficient token allowance before it can transfer the funds. Approval grants spending permission; the separate order-creation transaction commits assets to the exchange. Its parameters identify the output asset, destination, recipient, and required amount. Any attached hook also belongs to the authorization being signed.
Destination delivery precedes the solver’s final settlement
Successful source-chain order creation establishes a pending exchange. It does not establish destination receipt.
DLN assigns an order identifier that connects its records across chains. A solver can fulfill the order by supplying the specified destination assets. For a plain DLN transfer without a hook, fulfillment transfers the requested output amount to the designated destination recipient. The destination transaction provides the relevant delivery record.
The solver subsequently requests release of the source funds through a cross-chain message. The tracking states distinguish fulfillment, an unlock request, and a completed unlock. A recipient may already have the output while the solver’s reimbursement remains unfinished.
Reconciliation links the order identifier to the source transaction and destination transfer. The asset identifier, recipient, and transferred quantity establish whether the requested delivery occurred. A wallet’s aggregate balance alone can obscure unrelated activity. Orders with hooks also require inspection of the attached action’s outcome because fulfillment can precede that action.
What costs enter a cross-chain quote?
A cross-chain quote reflects protocol charges, solver economics, and any swaps or additional actions needed to deliver the requested asset. Source-chain gas can require a separate wallet payment. Comparing offers therefore requires the same input, output, recipient, and route conditions.
Protocol charges
DLN order creation includes a flat charge in the source chain’s native currency and a variable charge in the input token. These parameters can change. The transaction estimate and contract configuration determine the applicable amounts, rather than a permanent fee percentage.
Solver expenses and conversion costs
Solvers need compensation for destination delivery and subsequent settlement transactions. Their margin and operating expenses affect the exchange terms. A route involving additional token conversions also introduces swap costs and slippage considerations. These components explain why the quoted output can change without a change in the protocol fee.
Integration and hook charges
An integration can include an affiliate fee. An attached hook can require an execution reward or other execution expenses. Comparing only the input and output quantities misses native-currency payments outside that pair. Conversely, adding a cost already reflected in the quote would count it twice.
Token availability depends on liquidity and the requested amount
Support for a blockchain does not establish an executable trade for every token on it. Available liquidity, route construction, and solver willingness determine whether a requested exchange can proceed. A token appearing in a selection interface does not commit anyone to filling an order.
DLN routing can use reserve assets that solvers hold for settlement. A non-reserve input may require a source-chain conversion before order creation. The destination side may also need a conversion into the requested output. These swaps introduce their own liquidity constraints. Increasing the input amount can change the available route and output relationship; it does not simply multiply a smaller quote.
Market and limit orders share a fulfillment condition
A solver must find an order acceptable before supplying its destination assets. Market-oriented quotes account for operating expenses and an incentive to fulfill. A limit order specifies exchange terms that may remain unattractive until market conditions change.
Neither an order’s existence nor its requested output forces execution. Solvers also assess chain conditions and settlement risk. They may wait for additional source-chain confirmation or decline an order altogether. A fixed output requirement protects the order’s terms when it fills; it does not promise a fixed waiting time. Revising an estimate before submission and changing an already funded order are separate operations.
When can an unfilled order be cancelled?
An unfulfilled DLN order can enter cancellation through its authorized destination-chain account, provided fulfillment has not already occurred. The resulting cross-chain message enables release of the locked source funds to the permitted cancellation beneficiary.
Cancellation requires its own transaction and funding. Besides destination gas, the transaction can include messaging charges and funds for executing the source-chain claim. Access to the sending wallet alone does not establish cancellation authority when an integration assigned that authority elsewhere.
The refund includes the funds locked for the order and its refundable protocol and affiliate fees. It does not reverse gas already spent or necessarily restore an asset converted before order creation. A cancellation request also differs from a completed refund. The source-chain claim and beneficiary transfer establish completion; a cancellation status on the destination chain establishes only that part of the process.
Hooks add destination actions with separate failure conditions
A hook attaches a destination action to a DLN order, allowing the output to enter another contract operation. The destination chain and hook configuration determine whether the action must succeed alongside fulfillment or can execute later. EVM chains support atomic and non-atomic hooks with required or optional success; Solana supports only non-atomic, success-required hooks. This distinction changes what a completed swap means for the intended application task.
An atomic, success-required hook must succeed within the fulfillment transaction. Failure reverts that transaction, leaving the order unfilled. An optional-success configuration can instead direct the output to its specified fallback address if the action fails. Those outcomes represent different authorization choices.
A non-atomic hook can remain pending after the order fills, with its output held in an intermediary contract. The authorized account may cancel that pending hook to recover the destination output. This recovery concerns the hook’s funds on the destination chain; it does not cancel an already fulfilled cross-chain exchange or return the original source asset.
Contract exposure and message validation remain relevant
DLN’s absence of a continuously funded shared liquidity pool changes how funds enter the system. Individual orders still place assets in contracts temporarily. Calling this a zero-TVL design does not mean an order avoids contract exposure or that all deBridge products use the same custody model.
DMP relies on validator signatures and source-chain finality to authenticate cross-chain messages. Unlocking and cancellation depend on that infrastructure. A messaging interruption can delay settlement or fund recovery. dePort additionally depends on the custody of backing assets, while hooks introduce the receiving contract’s behavior and permissions. A successful token delivery does not prove that an attached application action succeeded.
Applications and chain integrations expose different entry paths
Access can come through the swap application, an embedded widget, an API integration, or direct contract interaction. These entry paths can present different choices and additional fees while using the underlying infrastructure. Same-chain swaps also have their own routing and execution process, without a cross-chain unlock stage.
At the blockchain level, deBridge IaaS connects an ecosystem to liquidity exchange, messaging, and asset custody. Infrastructure integration and inclusion in the main application’s chain selector are separate decisions. A connected chain can remain accessible through an integration even when the main application does not list it. This access depends on continued IaaS service and message validation; an unpaid subscription can eventually halt validation. For token issuance across those environments, dePort provides the distinct lock-and-mint mechanism.
FAQ
Do I need to grant an unlimited token allowance?
An unlimited allowance is not required when a finite allowance covers the transaction’s required token amount. The amount that the spending contract needs can include more than the amount initially entered, depending on how the integration handles expenses. A refreshed quote can change that requirement. Existing permission should match the actual token, spending contract, and transaction amount.
Does an identical token symbol identify the same asset on both chains?
An identical symbol does not establish that two tokens have the same issuer, backing, or redemption mechanism. Asset identity also depends on the blockchain and token contract or mint address. This matters when choosing between an existing destination token and a bridged representation. The receiving application must accept the specific asset that the order delivers.
Will receiving tokens also provide gas for later transactions?
Receiving a token does not automatically provide the destination chain’s native currency for later transactions. A route or attached action must explicitly deliver that currency for a gas top-up to occur. A solver paying for fulfillment covers its own transaction; it does not establish that the recipient can subsequently transfer tokens or interact with another contract.
Is a connected wallet required to preview a quote?
The DLN API can return an estimate without all the wallet information needed to construct an executable transaction. A preview therefore does not establish that the account has sufficient funds or spending permission. Providing the required wallet details allows the integration to build the transaction, whose amounts and terms still need to match the intended exchange.
How does a contract authenticate the sender of a hook?
A hook does not authenticate its original sender merely because a DLN contract forwards the call. A receiving contract that needs user authentication must verify an appropriate signature within the supplied data. Authenticating a remote smart contract requires the messaging mechanism. Granting permissions solely because the immediate caller is a DLN intermediary would confuse delivery with authorization.
Can dePort representations move between secondary chains?
dePort supports transfers of its representations between supported secondary chains without requiring a return through the native chain. The underlying backing remains on the native chain under the lock-and-mint model. This movement does not turn the representation into a separately issued native asset, and destination applications still need to support the specific representation.