Search

Search for projects by name or address

deBridge DLN logo
deBridge DLN

About

Intent framework built on top of the deBridge messaging protocol. Maker funds are escrowed in the DlnSource contract on the source chain and released to takers on unlock messages attested by the deBridge validator set.


Last 24h volume
$15.06 M
Last 24h transfer count
2.59 K
Last 24h top path
arbitrumsolana$2.78 M

Last 24h avg. transfer time
26s
Last 24h avg. transfer value
$6.59 K
Tokens by volume
USDCETHBNB
+156

Transfer size
Under $100
$100-$1K
$1K-$10K
$10K-$100K
Over $100K

Transfer type distribution
Non-minting

About

Intent framework built on top of the deBridge messaging protocol. Maker funds are escrowed in the DlnSource contract on the source chain and released to takers on unlock messages attested by the deBridge validator set.

Top token

Volume
$12.41 M
Transaction count
1.41 K

Intent framework built on top of the deBridge messaging protocol. Maker funds are escrowed in the DlnSource contract on the source chain and released to takers on unlock messages attested by the deBridge validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set.

Architecture

The deBridge Liquidity NetworkA category of token bridge that makes use of liquidity providers on the destination chain to facilitate the transfer of tokens. (DLN) is an intent protocol built on top of the deBridge messaging protocol, sharing its validation layer and governance. Users (makers) create cross-chain orders by locking their give funds directly in the DlnSource contract on the source chain. On the destination chain, takers fulfill orders through the DlnDestination contract by paying the take amount, which is forwarded to the recipient within the same transaction, so DlnDestination holds no user funds. A protocol fee (currently 0.001 ETH flat plus 4 bps on Ethereum, refunded on cancellation) is deducted from the give amount at order creation.

Order lifecycle

Fulfillment is permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. — anyone can fill any order unless the maker restricted it — and the filler names an unlock authority for the order. Only that unlock authority can later trigger the unlock, which sends a message back to the source chain’s DlnSource through the DeBridgeGate. Once the deBridge validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier attest the message, the escrowed give funds are released to the taker’s chosen beneficiary.

Crosschain validation

DlnSource releases escrowed funds only to calls from the deBridge CallProxy whose authenticated original sender is the DlnDestination address configured for the order’s destination chain (an admin-set, event-tracked map currently routing to 21 chains). The authenticity of that claim rests entirely on the deBridge validator set: a quorum of validator signatures (currently 8 of 12 on Ethereum) attests each unlock or cancellation message. A compromised validator quorum, or an admin change of the per-chain routing addresses, allows draining all order funds escrowed in DlnSource.

User recovery

Unfilled orders can be cancelled from the destination chain by the maker-designated order authority, refunding the full escrow to the maker on the source chain. A GOVERNANCE_DELEGATED_ORDER_CANCEL_ROLE can force-cancel unfulfilled orders on behalf of makers, but refunds can only go to a maker-designated address, making it a livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. rather than a theft power. Fulfilled orders cannot be cancelled.

External calls

Orders can carry calldata to be executed on the destination chain after fulfillment. In that case the taker’s funds are routed to an ExternalCallAdapter escrow, which releases them when the registered executor contract runs the calldata or refunds the order authority on cancellation. The adapter is admin-replaceable in DlnDestination, so a malicious adapter could steal the funds of every order carrying calldata.

Intents

A newer intent-manager stack automates order creation: users sign an EIP-712 intent offchain — the signature covers only an opaque 32-byte intent hashA fixed-length fingerprint of variable-size input, produced by a hash function., so wallets cannot display the actual constraints — and permissionless fillers turn intents into DLN orders through the DeBridgeIntentManager. There is no signature nonce; an intent is multi-fill until its budget is exhausted, expired, cancelled or nullified. Input tokens are pulled through the DeBridgeAllowanceHolder, the single immutable contract holding all user approvals of the intent system: its transfer functions carry no intent-level checks, so any holder of its ALLOWED_SPENDER_ROLE can move any approved token from any approver to any recipient. All user protection lives in the constraints of the signed intent itself (price bounds, allowed senders, receivers, budgets); the fill fee is not part of the signed intent and is set by the intent manager admin.

UpgradeabilityThe ability for rollup smart contracts and parameters used in a rollup to be updated by holders of an admin key. Upgradeability represents a vector of risk for users, and should be decentralized and combined with time delays for greater security guarantees. and governance

DlnSource (which escrows all in-flight maker funds), DlnDestination and the ExternalCallAdapter are upgradeable by the same 5/8 deBridge multisig that governs the messaging protocol, with no timelock or exit windowThe amount of time that users have to exit a system before an unwanted upgrade. It takes into account upgrade delays, forced transaction delays and other time factors. To be considered Stage 1, a rollup needs to have an exit window of at least 7d if upgrades are initiated by a permissioned actor less decentralized than a Security Council. For Stage 2, a rollup needs at least 30d in all cases outside of onchain provable bugs.. The multisig also holds the DEFAULT_ADMIN_ROLE on both DLN contracts, controlling the trusted cross-chain routing addresses, fees, the external call adapter, and unpausing. The intent-manager stack has a weaker setup: on Ethereum, a single EOA is simultaneously the admin of DeBridgeIntentManager and DeBridgeAllowanceHolder and the owner of the ProxyAdmin that can upgrade the intent manager — an upgrade there could abuse the allowance holder’s spender role to drain all outstanding user approvals. Several satellite contracts have unverified source code.

Monitoring

Order creation, fulfillment, unlock and cancellation all emit events, and the per-chain routing configuration is event-tracked. deBridge provides an explorer (DLN trades are labeled as such) for tracking order flow.

Symbol
Last 24h Volume
Last 24h transfer count
Last 24h avg. transfer time
Last 24h avg. transfer value
From
To
Timestamp
Tokens
Value
Bridge
Transfer time
Chains

Ethereum

Actors:

Admin Multisig0x6bec…92D5

A Multisig with 5/8 threshold.

  • Can upgrade with no delay
    • DeBridgeGate
    • ExternalCallAdapter
    • DeBridgeRouter
    • DeBridgeTokenDeployer
    • CallProxy
    • SignatureVerifier
    • SimpleFeeProxy
    • DlnDestination
    • DlnSource
  • Can interact with DeBridgeGate
    • pause the DeBridgeGate, stopping all sends, claims and deToken deployments on this chain (only the admin can unpause)
    • replace the SignatureVerifier (and with it the entire validation layer of the deBridge messaging protocol), the CallProxy and the deToken deployer, censor individual submissions (blockSubmission), toggle supported chains, set all fees and per-address fee discounts, designate the fee withdrawal contract, unpause the gate, and grant/revoke all roles. Most of these setters emit no events
  • Can interact with ExternalCallAdapter
    • replace the executor contract that handles external calldata of DLN orders and pause the adapter
  • Can interact with DeBridgeRouter
    • manage the whitelist of swap routers and forwarding targets this contract may call with arbitrary calldata (and grant infinite token approvals to), set the service fee and fee treasury, and sweep any funds held by the router
  • Can interact with DeBridgeTokenDeployer
    • administer all deployed deTokens: pause their transfers and grant/revoke minter rights, including the ability to grant itself the right to mint unbacked deTokens
    • replace the implementation of all deTokens at once (this contract acts as their beacon), change the admin assigned to newly deployed deTokens, and override deToken names/symbols. None of these setters emit events
  • Can interact with CallProxy
    • grant and revoke the DEBRIDGE_GATE_ROLE that authorizes contracts to execute arbitrary external calls through the CallProxy
  • Can interact with SignatureVerifier
    • add and remove deBridge validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier (oracles), change all signature thresholds (quorum must remain a majority of the oracle set), and re-point the gate contract allowed to request verification. Threshold changes emit no events
  • Can interact with SimpleFeeProxy
    • grant/revoke the FEE_COLLECTOR_ROLE that receives all deBridge protocol fees, pause fee withdrawals, and change the referenced gate contract
  • Can interact with DlnDestination
    • set the trusted DlnSource address (message receiver) for each supported chain, replace the external call adapter that custodies funds of orders with attached calldata, unpause the contract, and grant/revoke all roles
  • Can interact with DlnSource
    • set the trusted DlnDestination address for each supported chain (a malicious address there can drain all escrowed order funds via forged unlock messages), change DLN fees without upper bound, unpause the contract, and grant/revoke all roles
DeBridgeIntentManager_v0_8_00xd2a4…4F07

Fills signed user intents through DLN orders or same-chain swaps. It pulls approved tokens through its configurable allowance holder. Fees, the DLN source and the fee recipient are configurable independently of user signatures.

  • Can interact with DeBridgeAllowanceHolder_v0_1_4
    • transfer approved tokens from any user to any recipient through direct allowances or Permit2
DeBridgeIntentManager0xDDDD…9708

Fills user-signed intents by creating DLN orders on their behalf: it pulls input tokens from users through the DeBridgeAllowanceHolder and forwards them into DlnSource in the same transaction, charging a variable fee that is not part of the user-signed intent.

  • Can interact with DeBridgeAllowanceHolder
    • unconditionally transfer any amount of any token from any user who approved the DeBridgeAllowanceHolder (directly or via Permit2) to any recipient, and make arbitrary calls from its address
  • Can interact with DlnDestination
    • force-cancel any not-yet-fulfilled order that has a cancel beneficiary set by its maker (refunds can only go to that maker-designated address)
  • Can interact with SignatureVerifier
    • sign cross-chain submissions as a deBridge validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier. A quorum of these signers can authorize arbitrary messages, mint deTokens and unlock collateral from the deBridge gate on this chain
  • Can interact with SimpleFeeProxy
    • withdraw all protocol fees accrued in the DeBridgeGate to itself
  • Can interact with DlnSource
    • withdraw accumulated DLN protocol fees (not user principal) to itself
  • Can interact with DeBridgeAllowanceHolder_v0_1_4
    • authorize spenders of all user approvals, replace Permit2 and rescue held funds
  • Can interact with DeBridgeIntentManager_v0_8_0
    • change the allowance holder, DLN source, fee recipient and intent fees, rescue held funds, and grant or revoke roles
  • Can upgrade with no delay
    • FeeTreasury
    • DeBridgeIntentManager
  • Can interact with FeeTreasury
    • grant and revoke fee withdrawal permissions
  • Can interact with DeBridgeAllowanceHolder
    • grant and revoke the ALLOWED_SPENDER_ROLE, i.e. authorize any address (including itself) to spend all outstanding user approvals of the deBridge intent system
  • Can interact with DeBridgeIntentManager
    • set intent fill fees up to 100% with immediate effect (fees are not part of the user-signed intent), manage the trusted solver set, sweep funds held by the contract, and grant/revoke all roles
  • Can interact with IntentManagerValidator
    • grant and revoke the INTENT_MANAGER_ROLE that allows creating DLN orders with custom or zero protocol fees
  • Can upgrade with no delay
    • DeBridgeAllowanceHolder_v0_1_4
    • DeBridgeIntentManager_v0_8_0

Ethereum

Central hub of the deBridge messaging protocol on this chain: it emits cross-chain submissions (asset transfers and/or arbitrary messages), locks and releases native assets, mints and burns deBridge-wrapped assets (deTokens), and executes claimed submissions after their validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier signatures are checked by the SignatureVerifier. Claiming is permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants.: anyone can execute a submission that carries enough validator signatures.

  • Roles:
    • admin: ProxyAdmin; ultimately Admin Multisig
    • defaultAdmin: Admin Multisig
    • govMonitoring: Admin Multisig
Can be upgraded by:

Deploys deBridge-wrapped token (deToken) contracts when an asset is bridged to this chain for the first time (callable only by the DeBridgeGate). All deTokens are beacon proxies whose beacon is this contract itself, so its tokenImplementation applies to every deToken on this chain at once.

  • Roles:
    • admin: ProxyAdmin; ultimately Admin Multisig
    • deBridgeTokenAdmin: Admin Multisig
    • defaultAdmin: Admin Multisig
Can be upgraded by:

Sandbox that executes arbitrary calldata attached to claimed cross-chain submissions on behalf of the DeBridgeGate. Calls are performed from this contract’s address with attacker-choosable target and data, so external contracts must never trust it as a caller; it isolates such calls from the gate’s balances.

  • Roles:
    • admin: ProxyAdmin; ultimately Admin Multisig
    • defaultAdmin: Admin Multisig
Can be upgraded by:

Validation layer of the deBridge messaging protocol on this chain: it accepts a cross-chain submission if at least minConfirmations of the registered validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier (oracles) have signed its submission ID with a plain ECDSA signature, and every validator flagged as ‘required’ has signed. There is no other proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

  • Roles:
    • admin: ProxyAdmin; ultimately Admin Multisig
    • defaultAdmin: Admin Multisig
    • oracleAddresses: EOA 10, EOA 11, EOA 12, EOA 13, EOA 14, EOA 2, EOA 4, EOA 5, EOA 6, EOA 7, EOA 8, EOA 9
Can be upgraded by:

Destination side of the deBridge Liquidity NetworkA category of token bridge that makes use of liquidity providers on the destination chain to facilitate the transfer of tokens. (DLN) intent protocol: takers fulfill orders here permissionlessly by paying the ‘take’ amount, which is forwarded to the order recipient in the same transaction (this contract holds no user funds). The taker then sends an unlock message back to the source chain’s DlnSource through the deBridge messaging protocol to claim the escrowed maker funds.

  • Roles:
    • admin: ProxyAdmin; ultimately Admin Multisig
    • defaultAdmin: Admin Multisig
    • govCancel: EOA 1
Can be upgraded by:

Source-side escrow of the deBridge Liquidity NetworkA category of token bridge that makes use of liquidity providers on the destination chain to facilitate the transfer of tokens. (DLN) intent protocol: users lock the ‘give’ funds of a cross-chain order directly in this contract. Funds are released to the taker (claimUnlock) or refunded to the maker (claimCancel) only on a message from the DlnDestination configured for the order’s destination chain, authenticated via the CallProxy of the deBridge messaging protocol (i.e. ultimately by deBridge validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier signatures).

  • Roles:
    • admin: ProxyAdmin; ultimately Admin Multisig
    • defaultAdmin: Admin Multisig
    • feeCollector: EOA 3
Can be upgraded by:
ProxyAdmin
2 instances
0x368F…C4A30xaBAc…283F
  • Roles:
    • owner: EOA 16
IntentManagerValidator0x4247…CD4b

Immutable allowlist contract referenced by DlnSource: addresses holding the INTENT_MANAGER_ROLE can create DLN orders with custom or zero protocol fees. It grants no access to existing funds.

  • Roles:
    • defaultAdmin: EOA 17

Escrow and dispatcher for external calls attached to DLN orders: it receives the taker’s funds of orders that carry calldata and releases them when the calldata is executed by the registered executor, or refunds the order authority on cancellation.

  • Roles:
    • admin: ProxyAdmin; ultimately Admin Multisig
    • defaultAdmin: Admin Multisig
Can be upgraded by:

Optional periphery router that can swap input tokens via whitelisted DEX routers and forward the proceeds into the DLN contracts (order creation, or order fulfillment on the hardcoded DlnDestination via fillCrossChain) in a single transaction. It does not custody funds across transactions and is not part of the DLN critical path.

  • Roles:
    • admin: ProxyAdmin; ultimately Admin Multisig
    • defaultAdmin: Admin Multisig
Can be upgraded by:
DeBridgeAllowanceHolder_v0_1_40x6A4C…C25AImplementation (Upgradable)Admin

Upgradeable approval holder for deBridge intents. Authorized spenders can transfer any approved token from any user to any recipient, through direct allowances or Permit2. Transfers carry no intent-level checks.

  • Roles:
    • admin: ProxyAdmin; ultimately EOA 18
    • allowedSpender: DeBridgeIntentManager_v0_8_0
    • defaultAdmin: EOA 15
Can be upgraded by:

Holds fees collected by deBridge intent contracts. Authorized collectors can withdraw native tokens and ERC20 tokens to any recipient.

  • Roles:
    • admin: ProxyAdmin; ultimately EOA 16
    • defaultAdmin: EOA 16
Can be upgraded by:
  • Roles:
    • owner: Admin Multisig
ProxyAdmin
2 instances
0xA813…714e0xb54C…8816
  • Roles:
    • owner: EOA 18
ExternalCallExecutor0xAE03…7974

The default executor in the ExternalCallAdapter: it executes external calldata attached to DLN orders.

The only contract allowed to withdraw protocol fees accrued in the DeBridgeGate. Fees are paid out directly to the caller of withdrawFees(), so the effective fee destination is whoever holds the FEE_COLLECTOR_ROLE.

  • Roles:
    • admin: ProxyAdmin; ultimately Admin Multisig
    • defaultAdmin: Admin Multisig
    • feeCollector: EOA 3
Can be upgraded by:
DeBridgeToken0xCAce…A98B

Implementation contract for deBridge-wrapped tokens (deTokens). Minting and burning of deTokens is restricted to the MINTER_ROLE, which is held by the DeBridgeGate.

DeBridgeAllowanceHolder0xdddd…23d0

Immutable allowance sink of the deBridge intent system: users approve this contract (directly or as Permit2 spender) so that the upgradeable executor contracts never hold approvals themselves. Its transfer functions carry no intent-level checks: any ALLOWED_SPENDER_ROLE holder can move any approved token from any approver to any recipient.

  • Roles:
    • allowedSpender: DeBridgeIntentManager
    • defaultAdmin: EOA 16

The current deployment carries some associated risks:

  • Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).