Debridge is a Cross-Chain Interface That Checks the Wallet Network Before a DLN Order
Debridge is a cross-chain trading interface that requires the connected wallet to match the selected source network before it can submit a DLN order. Select the source chain, switch the wallet to that network, review the recipient and quote, then sign and save the resulting order ID.
Fixing a Wallet - Source Network Mismatch
A wallet - source network mismatch is the setup error that leaves a valid route selected in Debridge while the connected wallet still points to a different chain.
EVM Wallets
When the source selector says Ethereum, chain ID 1, while MetaMask or Rabby reports Arbitrum, chain ID 42161, the wallet is not ready for that transaction. Change the network inside the wallet to the route’s source chain. Do not change the destination merely to clear the prompt. Base, for example, has chain ID 8453 and must appear in the wallet only when Base is the selected source.
Solana Wallets
Solana uses Debridge internal chain ID 7565164 rather than an EVM chain ID. A Solana-source order therefore needs a Solana account exposed through Phantom or Solflare. Selecting Solana as the destination does not require the source wallet to switch there; the destination recipient simply needs to be a valid Solana public key for the chosen SPL token.
The mismatch blocks creation before funds move. If no source-chain transaction was broadcast and confirmed, there is no DLN order, no order ID and no input locked by DlnSource.
Source-Chain Prerequisites
Source-chain prerequisites are the wallet account, input balance, native gas balance and destination recipient that must be ready before Debridge builds a signable transaction payload. An EVM address contains 20 bytes and displays as 40 hexadecimal characters after 0x, making 42 characters in total. A Solana public key contains 32 bytes and uses Base58; an SPL or ERC-20 balance still needs native gas for its source-chain transaction.
Review Fields That Define the Order
The DLN order review is the final specification of direction, assets, amounts, recipient, authorities and costs that the source-chain transaction will commit on-chain after signing. The follow-on topic is treated in Debridge choosing eligibility.
Direction and Assets
Read the route from source to destination: source network, input token, input amount, destination network and output token. Token symbols alone do not identify an asset across chains, so the selected network and token contract belong together. On standard 6-decimal USDC deployments, 1 USDC equals 1,000,000 atomic units. ETH uses 18 decimals, making 1 ETH equal to 1,000,000,000,000,000,000 wei.
Recipient and Authorities
The destination recipient receives the output when a solver fulfills the order. The destination order authority controls destination-side cancellation, while the source authority receives returned input after a completed cancellation flow. For a self-transfer, these fields normally point to accounts that the same user controls. An EVM address and a Solana public key are different formats, even when one wallet application exposes both ecosystems. These roles may use the same 20-byte EVM address, yet Debridge records them as distinct fields because receipt and cancellation have different effects.
Quote and Fees
DLN applies two mandatory creation-fee components: a flat source-chain native fee and a 4-basis-point variable fee, equal to 0.04% of the input token. The flat value comes from the source-chain contract at quote time, so the displayed transaction value is the relevant figure. The review also reflects solver operating expenses, source gas and any swaps needed around the cross-chain order.
Accept or reject the route from its displayed input, expected output, recipient and fee breakdown as one package. Changing the wallet account, source chain or amount requires a new review.
What Happens When You Confirm a DLN Order?
A confirmed DLN order is an on-chain source-chain transaction that transfers the specified input to DlnSource, records fixed terms and emits the identifier used downstream.
With a native input asset, the EVM flow proceeds directly to order creation and includes the required native transaction value. An ERC-20 route commonly needs two on-chain actions: approval for the spender returned in the transaction payload and then order creation. The spender is not something to infer from the token symbol. MetaMask or Rabby must show the chosen source network for both actions. On Solana, Phantom or Solflare signs a serialized VersionedTransaction rather than an EVM approval call. A rejected approval does not create an order, and an approved allowance alone produces no order ID.
Once creation confirms, DlnSource holds the input under the order’s terms and the tracker reports Created. A solver then supplies the requested asset through DlnDestination on the destination chain. Fulfillment transfers that asset to the recorded recipient and changes the destination-side status to Fulfilled. The order’s amount, receiver and chain choices are part of its fixed structure rather than editable interface preferences. After fulfillment, the Debridge Messaging Protocol carries one unlock instruction back to the source chain. That later message releases the locked source asset to the solver and completes the liquidity settlement.
Order ID Anatomy and Verification
The DLN order ID is a deterministic hash that binds the source terms, destination terms, maker, receiver and authorities into one cross-chain identifier for tracking.
A DLN order ID is a 32-byte Keccak-256 digest, normally displayed as 0x followed by 64 hexadecimal characters for 66 characters in total. Its encoded input starts with an 8-byte, 64-bit salt and includes the maker, both chain identifiers, token addresses, amounts, receiver and authority fields. Each chain identifier and amount occupies 32 bytes, or 256 bits, before Keccak-256 reduces the full structure to the final digest.
Save the order ID shown after source confirmation. A transaction hash identifies one blockchain transaction, while the order ID identifies the cross-chain instruction reproduced by DlnSource, DlnDestination and the tracking service. Matching the ID across the confirmation view and tracker ties those records to the same terms.
Read the Order States in Sequence
The DLN order state is a protocol status that shows whether the source order awaits a solver, has paid the recipient or has entered cancellation.
The DLN tracking API exposes eight order states: None, Created, Fulfilled, SentUnlock, OrderCancelled, SentOrderCancel, ClaimedUnlock and ClaimedOrderCancel. Application logic treats three fulfillment-side states - Fulfilled, SentUnlock and ClaimedUnlock - as successful completion for the recipient, because payment occurs at Fulfilled.
Fulfillment Path
Created means the source-chain order exists and awaits fulfillment. Fulfilled means a solver transferred the complete requested output to the destination recipient. SentUnlock records that the solver started the cross-chain unlock message. ClaimedUnlock closes the solver’s source-side claim. A recipient checking whether the output arrived should focus first on Fulfilled and the destination transaction, not wait for the solver’s later accounting step.
Cancellation Path
OrderCancelled means the destination authority started cancellation before fulfillment. SentOrderCancel records the cross-chain cancellation message and ClaimedOrderCancel means the source beneficiary recovered the input. Cancellation begins on the destination chain, so its authority account needs that network’s native gas. The input, protocol fee and affiliate fee return through the completed cancellation path, while the separate cancellation transaction carries its own messaging and gas value.
Network Recovery Without Rebuilding the Route
Network recovery is the short reset sequence that realigns the connected account, wallet chain and refreshed quote before a new source-chain signature is requested again.
Open MetaMask or Rabby, select the exact EVM source network and return to Debridge. If Solana is the source, reconnect Phantom or Solflare with the intended account. Then confirm that the interface shows the same address and source chain. This preserves the destination selection while correcting the signer context that the transaction requires.
Refresh the quote if about 30 seconds passed during the switch because the paired estimate and transaction reflect short-lived gas and market inputs. If an ERC-20 approval confirmed but order creation was rejected, the approval remains separate and no order exists yet. Recheck the approved amount, load a fresh transaction and sign only after the wallet again displays the correct source network. Only a confirmed creation transaction produces the order ID. Before that point, the recovery task concerns wallet state and quote freshness rather than order cancellation.
Worked Example: Balance and Network Check
This worked DLN example uses these changing hypothetical inputs: 250 USDC sold on Arbitrum, 249.70 USDC quoted on Base, a 0.001 ETH flat fee and 0.00015 ETH estimated gas.
The wallet must display Arbitrum and chain ID 42161 before either signature; Base and chain ID 8453 remain the destination. The fixed 4-basis-point protocol component equals 250 × 0.0004, producing 0.10 USDC within the route economics. Add a 30% allowance buffer to a 0.02 USDC operating-expense estimate: 0.02 × 1.30 equals 0.026 USDC. The ERC-20 approval target becomes 250.026 USDC, while the displayed native costs require 0.001 + 0.00015, or 0.00115 ETH.
The concrete pre-sign result is an Arbitrum wallet with the stated USDC allowance and at least 0.00115 ETH for the displayed flat fee plus gas. The quoted 249.70 USDC remains the destination-side accept-or-reject figure. After confirmation, save the new order ID rather than repeating the calculation from a later quote.
Where the Wallet-First Workflow Fits
A wallet-first DLN workflow is a strong fit for transfers where the signer controls the source account, understands the destination recipient and preserves the order ID.
EVM-to-EVM routes work cleanly when MetaMask or Rabby exposes the source account and the recipient belongs to Ethereum, Arbitrum, Base, Polygon or BNB Chain as selected. EVM-to-Solana routes add a format boundary: the source signer remains in the EVM wallet while Phantom or Solflare supplies the Solana recipient. A Ledger account connected through a wallet interface adds device confirmations for approval and creation, making quote refresh more likely before the second signature.
The workflow stays clearest when one person can distinguish the source signer, destination recipient, token contract and native gas asset. That separation turns the confirmation screen into a precise execution decision.
Things people ask about Debridge
Does Debridge show a route before I connect a wallet?
A DLN estimate may appear before wallet connection; a signable transaction arrives only after sender, recipient and authority addresses are known. The estimate describes a route, while the transaction payload binds that route to actual accounts. After connection, compare refreshed input, output and fees with the earlier preview. If the account or source chain changes, treat the connected-wallet response as operative because it contains the data that the wallet will sign.
Does an ERC-20 approval authorize anything on the destination chain?
An ERC-20 approval authorizes only the source-chain spender and amount for the input token. It does not approve the output token, grant destination authority or move input by itself. Debridge still needs a separate order-creation transaction. Check that both prompts use the intended source account and network. If approval confirms while creation is rejected, the allowance remains, but no order ID exists because no DLN order was successfully created.
Why does an ERC-20 order include a native-token value?
The native-token value funds DLN’s flat source-chain protocol fee even when the input asset follows ERC-20. Source gas is a separate native-token cost for approval and order creation. The wallet therefore shows the ERC-20 amount alongside an ETH, BNB, POL or AVAX value where the selected chain uses that gas asset. Debridge reads the flat component from the source contract at quote time, so use the fresh transaction review.
When can I reject a wallet prompt without creating an order?
Rejecting the order-creation prompt before broadcast leaves no DLN order on-chain. A wallet signature is only one stage; the source network must accept and confirm the transaction before DlnSource records the terms and produces the trackable order ID. Rejecting an earlier ERC-20 approval also stops that approval. If the approval already confirmed and the later creation prompt is rejected, only the allowance changed. Reopen a fresh quote, verify the source network and decide whether to reuse or change that allowance before retrying the complete source-chain flow.
Can one transaction hash map to multiple DLN order IDs?
One creation transaction can map to multiple DLN order IDs when an integration batches order calls. Each order still receives its own deterministic identifier because its terms differ. A normal Debridge interface flow presents the identifier for the submitted order, so save that ID. If a transaction tracker reports several IDs, inspect each order’s source token, destination token, amount and receiver instead of assuming the transaction hash represents one cross-chain instruction.
Must I keep Debridge open after the source transaction confirms?
A confirmed DLN order continues on-chain after the browser tab closes. Solvers monitor Created orders independently, and DlnDestination handles fulfillment on the selected destination network. Save the order ID before leaving because it remains the key for reopening status. Fulfilled means the recorded recipient received the requested output; SentUnlock and ClaimedUnlock describe later settlement for the solver. If the order stays unfilled, cancellation still requires the destination authority and a separate destination-chain transaction, not an open browser session. Closing the interface therefore does not pause protocol execution or tracking.