Can Debridge deliver tokens to a different wallet address?

Yes, a Debridge order can name a destination recipient that differs from the source wallet. The recipient field becomes part of the signed order data and therefore part of its deterministic order ID. On EVM routes, enter a valid destination address for that chain; Solana routes require the corresponding Solana account form. Recheck the destination network and token contract together, because the same ticker can represent different assets across chains.

Do I need DBR to pay for a Debridge transfer?

No, DBR is not required to create an ordinary DLN trade. The source transaction pays a flat protocol component in the source chain’s native gas asset and a percentage component in the input token. The wallet also needs enough native currency for its own network fee. DBR serves governance functions, while solver operating expenses and margin appear inside the quoted economics. Holding DBR neither replaces source-chain gas nor changes the asset approval that an ERC-20 order needs. The quoted output remains independent of a DBR balance.

When does an ERC-20 approval remain necessary?

An ERC-20 approval is required when DlnSource lacks enough allowance to transfer the chosen input token from the user’s wallet. A compatible EIP-2612 permit can package signed approval data with order creation, removing the separate approval transaction. Native assets use the zero-address representation and need no ERC-20 allowance. Approval applies to the source token and spender, not to the destination asset, so switching either source token or contract can require a new authorization.

What happens if no solver fills a Debridge order?

An unfilled Debridge order remains locked on the source chain until market conditions attract a solver or the authorized party completes cancellation. Cancellation starts through DlnDestination on the destination chain, which records the order as cancelled and sends a DMP message back to DlnSource. After that message arrives, the allowed beneficiary claims the source funds. Protocol fee components return with a completed cancellation, while transaction fees already paid to the underlying chains remain spent. A fresh route can then be requested under current solver economics.

Does Debridge support destination-chain contract calls?

Yes, Debridge Hooks attach destination-chain instructions to a DLN order. The hook hash forms part of the deterministic order ID, binding the output and requested action together. EVM destinations support atomic or non-atomic execution with required or optional success behavior. Solana supports non-atomic, success-required hooks. A hook can deposit, swap or call another application, but its destination-specific data and fallback policy must be chosen before the order is signed.

Can a solver change the amount shown in my Debridge order?

No, a solver cannot alter the signed take amount and still fulfill the same order ID. DlnDestination recomputes the deterministic ID from the supplied fields, including both amounts, both chain identifiers, token addresses, recipient and hook hash. A mismatch refers to a different order. Pre-order and pre-fill swaps still contribute price impact to the quote before settlement, so the displayed output should be reviewed when the fresh transaction payload is created. The solver must match every field before source funds unlock.

Why do non-reserve tokens add another swap step?

Non-reserve tokens add a swap because DLN solvers concentrate inventory in a reserve set. The source-side router converts an input into a reserve asset, or a destination-side step converts reserve inventory into the requested output. USDC is the common reserve across routes, with ETH, wETH and USDT used on networks. Those surrounding swaps introduce liquidity and price impact into the quote even though the order’s take amount stays fixed.

Where should a developer track a Debridge order after submission?

A developer should track the deterministic order ID through the DLN order-status interface and relevant chain events. Created shows that DlnSource accepted the order, while Fulfilled confirms recipient payment on the destination. SentUnlock records the outbound unlock message and ClaimedUnlock marks the solver’s completed source claim. Cancellation has three separate states: OrderCancelled, SentOrderCancel and ClaimedOrderCancel. Application logic can treat the three successful states as delivery, while accounting systems may wait for ClaimedUnlock. That distinction separates recipient delivery from the solver’s later reimbursement.

Debridge is a Pool-Free Cross-Chain Trading Network Powered by Solvers

Debridge is a cross-chain trading network where independent market makers called solvers deliver the requested token on another blockchain. Its DLN system locks the user’s input on the source chain, pays the recipient from a solver’s destination inventory and later releases the locked input to that solver.

Moving USDC From Arbitrum to Solana

A USDC transfer from Arbitrum to Solana shows Debridge’s core use case: the user specifies a source asset, destination asset and recipient while a DLN solver supplies the Solana-side USDC. The Arbitrum input enters DlnSource, then DlnDestination on Solana verifies the matching order and pays the named recipient from the first valid solver fill.

Arbitrum uses chain ID 42161, while the DLN API identifies Solana as 7565164. USDC follows 6-decimal accounting, so 1,000,000 atomic units represent one USDC; SOL uses 9 decimals, making 1,000,000,000 lamports one SOL. Contracts process these integer units rather than wallet-display labels. The recipient receives the order’s take amount, while the solver later claims the locked reserve. ETH, wETH and USDT also serve reserve routes. The remaining detail is recorded in Debridge choosing networks breakdown.

The same structure serves treasury rebalancing, wallet onboarding and payments where the destination asset must arrive at a predetermined address.

How Does Debridge Differ From Pool Bridges?

Debridge differs from pool bridges because DLN leaves no continuously locked shared reserve for cross-chain trades; destination liquidity comes from competing solvers after each order appears. Across uses a relayer-based intent model, Stargate V2 uses omnichain pools with Taxi and Bus modes, Wormhole Wrapped Token Transfers uses Guardian-attested messages and OP Stack Standard Bridge exits follow the rollup challenge period.

How Does Debridge Differ From Pool Bridges? in brief
Protocol Path	Fixed Structure or Duration
Debridge DLN	3 solver transactions: fulfill, send unlock and claim
Stargate V2	2 transfer modes: Taxi and Bus
Wormhole Wrapped Token Transfers	13-of-19 Guardian signatures per VAA
OP Stack Standard Bridge	7-day minimum withdrawal wait from L2 to Ethereum

These figures describe structure, not a speed ranking. Across is the closest alternative because its relayers also front destination liquidity for intent-based transfers. Stargate V2 suits same-asset pool routes through 2 modes. Wormhole Wrapped Token Transfers uses a 13-of-19 Guardian attestation. The OP Stack Standard Bridge inherits Ethereum-linked rollup security, with the 7-day exit delay deciding withdrawal timing. Route choice turns on asset form, destination coverage, time tolerance and the accepted security model.

Cartoon monkey in banana hat holding a large rifle

The DLN Order Lifecycle

The DLN order lifecycle uses 2 core contracts per supported chain and 1 cross-chain message after the destination order reaches a final state, coordinating payment without maintaining a pooled bridge reserve. DlnSource holds the maker’s input; DlnDestination records fulfillment or cancellation.

Creation and Fulfillment

Source Contract

DlnSource receives the give token and amount, destination chain, take token and amount, receiver and authority fields. Both chains reproduce its returned order ID. The deterministic keccak256 digest is 32 bytes, or 256 bits, and begins with an 8-byte salt. Give chain, give amount, take chain and take amount each occupy 32 bytes. A different amount, recipient or hook yields a different ID.

Destination Contract

DlnDestination accepts the exact order data and the solver’s requested output tokens. The first successful fulfillment changes the destination record and transfers the take amount to the recipient. Because settlement is an order rather than an automated market maker swap, no pool curve recalculates the signed output during that fill.

Unlock and Claim

After fulfillment, the solver sends an unlock instruction through the Debridge Messaging Protocol, then claims the source asset after that message reaches DlnSource. A solver completes three on-chain transactions across fulfillment, sending the unlock message and claiming the locked input. The tracking API exposes 7 named states: Created, Fulfilled, SentUnlock, ClaimedUnlock, OrderCancelled, SentOrderCancel and ClaimedOrderCancel. User interfaces commonly treat Fulfilled, SentUnlock and ClaimedUnlock as successful completion states, although only the last marks the solver’s final source claim.

Recipient delivery comes first; the next decision is whether that delivery also needs a destination-chain hook.

Fees, Quotes and the Amount Received

On the same footing, Debridge trading cost combines a source-chain flat charge, a protocol percentage taken from the input token and solver expenses embedded in the quoted spread, rather than one universal bridge toll. The interface calculates the combined output before signing.

The published DLN variable protocol parameter is 4 basis points, equal to 0.04% of the input amount. One basis point equals 1/10,000 and 100 basis points equal 1%. Governance can change the parameter, so integrations read percentFeeBps from DlnSource at quote time. The flat component comes from globalFixedNativeFee and uses the source chain’s native gas asset. Solver operating expenses cover the three fulfillment transactions, while a solver margin compensates destination inventory. A pre-order or pre-fill swap adds venue slippage when the chosen token is not already a reserve asset.

A completed cancellation refunds both protocol fee components. Transaction fees already spent on order creation and cancellation remain paid, and ERC-20 approval gas is separate.

Quote age is the immediate decision point. The API pairs estimation and transaction construction and recommends broadcast within about 30 seconds. Past that window, gas and inventory costs can overtake the solver spread, leaving the order unattractive. Requesting a new pair preserves market-order logic; replaying both fixed amounts turns the request into a limit-order style quote. That order remains open until a solver accepts it or the authority cancels it.

From Wallet Connection to Final Status

A Debridge trade starts with a supported wallet, source-chain gas and a fresh quote that identifies both token contracts, both chains and the destination recipient. Native assets need one source-chain transaction; an ERC-20 normally needs approval first unless its EIP-2612 permit flow is supported.

Select the source chain and token, then reserve enough native currency for gas.
Choose the destination chain, output token and recipient address.
Review the input, exact output, flat charge, percentage fee and solver expenses.
Approve the ERC-20 when prompted, refresh an old quote and sign the paired transaction.
Track the order ID through Fulfilled, SentUnlock or ClaimedUnlock.

Network identifiers deserve particular attention in custom integrations. Ethereum uses chain ID 1, BNB Chain 56, Polygon 137 and Arbitrum 42161; the DLN API uses 7565164 for Solana. An EVM native coin appears as the 20-byte zero address, written with 40 hexadecimal zeros after its prefix. ERC-20 assets use contract addresses, while native SOL uses a dedicated 32-character identifier and wrapped SOL uses a separate SPL mint. Mixing those forms changes the asset despite similar ticker text.

Choose the route only after the recipient, token contract and displayed output all match the intended destination.

deBridge bridging at lightspeed banner on a dark background

What Risks Remain When Solvers Supply Liquidity?

Solver-supplied liquidity leaves 4 main Debridge risks: quote freshness, solver profitability, chain finality and the messaging layer that releases source funds after fulfillment rather than pooled reserve depth. An unattractive order waits until economics improve or the order authority cancels it (more on this in Debridge choosing eligibility ).

A signed take amount does not move during the DLN fill, yet swaps around the reserve leg still create price impact before order creation or fulfillment. The quote includes those effects. Solvers choose their own source-chain confirmation policy, so fill speed reflects order size, profitability and perceived finality. After a fill, DMP carries the unlock message under its validator-signature threshold; the EVM verifier accepts at least a 2/3 quorum. The maker’s funds stay in DlnSource until fulfillment or the cancellation message completes.

Hooks add another execution decision. EVM routes offer 2 atomicity modes - atomic and non-atomic - and 2 success policies - required or optional. Solana hooks support only the non-atomic, success-required combination. An atomic required hook that reverts prevents fulfillment, while a non-atomic hook can remain pending. Use a plain transfer when no destination call is needed; otherwise, match the hook policy to acceptable fallback behavior.

If an order stays open, cancellation begins on the destination chain and returns source funds after the cross-chain cancel message completes. Route liquidity is the next check before signing.

From Messaging Mainnet to DLN and DBR

Either way, Debridge’s present solver model follows 2 earlier milestones: messaging mainnet launched on February 17, 2022 and DLN went live on June 15, 2023 for public cross-chain trading. DLN succeeded the pool-based deSwap V1 design.

The initial mainnet centered on cross-chain messaging, asset transfer and a lock-and-mint model for deAssets. DLN moved from persistent shared pools to orders filled from solver inventory. The protocol now separates 2 jobs: DMP validates cross-chain instructions and DLN matches value-transfer intents. A recipient therefore receives native destination inventory while the solver waits for an authenticated source unlock.

DBR arrived later as the governance token. Its fixed supply is 10,000,000,000 units, initially issued under Solana’s SPL token standard; protocol trades still charge the source native asset and the order’s input token rather than requiring DBR. Governance covers ecosystem parameters, while the transfer path continues through DlnSource, DlnDestination and DMP. Readers choosing Debridge should judge the quoted route, settlement model and application-call requirements separately from the governance asset.

The final choice is operational: use the web interface, embed the Debridge Widget, call the API or integrate the two DLN contracts directly.

Useful questions about Debridge

Can Debridge deliver tokens to a different wallet address?: Yes, a Debridge order can name a destination recipient that differs from the source wallet. The recipient field becomes part of the signed order data and therefore part of its deterministic order ID. On EVM routes, enter a valid destination address for that chain; Solana routes require the corresponding Solana account form. Recheck the destination network and token contract together, because the same ticker can represent different assets across chains.
Do I need DBR to pay for a Debridge transfer?: No, DBR is not required to create an ordinary DLN trade. The source transaction pays a flat protocol component in the source chain’s native gas asset and a percentage component in the input token. The wallet also needs enough native currency for its own network fee. DBR serves governance functions, while solver operating expenses and margin appear inside the quoted economics. Holding DBR neither replaces source-chain gas nor changes the asset approval that an ERC-20 order needs. The quoted output remains independent of a DBR balance.
When does an ERC-20 approval remain necessary?: An ERC-20 approval is required when DlnSource lacks enough allowance to transfer the chosen input token from the user’s wallet. A compatible EIP-2612 permit can package signed approval data with order creation, removing the separate approval transaction. Native assets use the zero-address representation and need no ERC-20 allowance. Approval applies to the source token and spender, not to the destination asset, so switching either source token or contract can require a new authorization.
What happens if no solver fills a Debridge order?: An unfilled Debridge order remains locked on the source chain until market conditions attract a solver or the authorized party completes cancellation. Cancellation starts through DlnDestination on the destination chain, which records the order as cancelled and sends a DMP message back to DlnSource. After that message arrives, the allowed beneficiary claims the source funds. Protocol fee components return with a completed cancellation, while transaction fees already paid to the underlying chains remain spent. A fresh route can then be requested under current solver economics.
Does Debridge support destination-chain contract calls?: Yes, Debridge Hooks attach destination-chain instructions to a DLN order. The hook hash forms part of the deterministic order ID, binding the output and requested action together. EVM destinations support atomic or non-atomic execution with required or optional success behavior. Solana supports non-atomic, success-required hooks. A hook can deposit, swap or call another application, but its destination-specific data and fallback policy must be chosen before the order is signed.
Can a solver change the amount shown in my Debridge order?: No, a solver cannot alter the signed take amount and still fulfill the same order ID. DlnDestination recomputes the deterministic ID from the supplied fields, including both amounts, both chain identifiers, token addresses, recipient and hook hash. A mismatch refers to a different order. Pre-order and pre-fill swaps still contribute price impact to the quote before settlement, so the displayed output should be reviewed when the fresh transaction payload is created. The solver must match every field before source funds unlock.
Why do non-reserve tokens add another swap step?: Non-reserve tokens add a swap because DLN solvers concentrate inventory in a reserve set. The source-side router converts an input into a reserve asset, or a destination-side step converts reserve inventory into the requested output. USDC is the common reserve across routes, with ETH, wETH and USDT used on networks. Those surrounding swaps introduce liquidity and price impact into the quote even though the order’s take amount stays fixed.
Where should a developer track a Debridge order after submission?: A developer should track the deterministic order ID through the DLN order-status interface and relevant chain events. Created shows that DlnSource accepted the order, while Fulfilled confirms recipient payment on the destination. SentUnlock records the outbound unlock message and ClaimedUnlock marks the solver’s completed source claim. Cancellation has three separate states: OrderCancelled, SentOrderCancel and ClaimedOrderCancel. Application logic can treat the three successful states as delivery, while accounting systems may wait for ClaimedUnlock. That distinction separates recipient delivery from the solver’s later reimbursement.