Skip to main contentdeBridge uses a high-performance cross-chain trading infrastructure that consists of two layers:
- Protocol layer: on-chain smart contracts
- Infrastructure layer: solvers who perform off-chain matching and on-chain settlement of trades
The deBridge Liquidity Network Protocol is represented by a set of smart contracts that can be called by any on-chain
address to create limit orders for cross-chain trades. When an order is created, the Maker provides a specific amount
of an input token on the source chain and specifies the parameters of the order, such as the token address and the
amount he accepts to receive in the destination chain.
The given amount is then temporarily locked by the DLN smart contract on the source chain, and any on-chain address
(named a solver) with sufficient liquidity in the destination chain can attempt to fulfill the order by calling the
corresponding method of DLN smart contract and supplying the liquidity as requested by the maker in the DLN order
parameters. After the order is fulfilled, a solver initiates a cross-chain message to be sent by the DLN smart contract
to the source chain via the deBridge messaging protocol. When the message is delivered, it unlocks the funds on the
source chain to the solver’s address, effectively completing the order. Below is a graphic outlining the process:
Order Creation
Specifically, there are two contracts deployed per supported chain: the DlnSource and the DlnDestination contracts.
Whenever a maker decides to trade liquidity, it places an order by calling the DlnSource.createOrder() method on the
source chain, providing the typed structure with precise requirements, specifically: the destination chain id, the
address of a token, and the amount they expect to receive, the address of the receiver where the requested tokens
should be sent to on the destination chain, and other system parameters. The smart contract assigns a unique identifier
(hash) to the order, made of the values of its typed structure including the maker-specific determinants (address and
nonce). The given amount of input token is taken from the user by the DlnSource contract and locked until the order
is either unlocked or canceled, which can happen only through the DlnDestination smart contract on the destination chain.
Order fulfillment
Solvers perform off-chain tracking of all orders created through DlnSource smart contract, and whenever an order meets
the solver’s requirements (for example, the profitability, the margin, or even if the input token is whitelisted),
they can attempt to fulfill the order by calling the DlnDestination.fulfillOrder() on the destination chain, supplying
the amount of tokens requested in the order, and the typed structure representing the order placed on the source chain
and order Id. At this point, no cross-chain communication is performed. The DlnDestination contract relies on the fact
that the given order being placed on another chain can only be handled once on the destination chain, so it calculates
the order identifier (hash) using the values from the given structure. It then checks that it matches the order Id
passed by the solver and if the order status hasn’t been assigned as fulfilled or canceled. The smart contract processes
the order by pulling the necessary amount of requested tokens from the solver and sending it to the receiver address,
finally assigning ‘fulfilled status’ to the order.
If the order generates some profit for the one who fulfills it, then solvers will have fair competition for its fulfillment.
For example, an order to exchange 1000 USDC on BNB Chain for 990 USDC on Solana will bring 10 USDC profit to the solver that
is the first to fulfill the order. Solvers are free to set their own requirements for transaction finality on the source chain.
For example, solvers with an aggressive risk profile may decide to fulfill orders after one block confirmation and try to
replay the maker’s transaction in case a reorg of the source chain happens after the order is fulfilled on the destination chain.
Unlocking fulfilled orders
The first solver that manages to change the status of the order in the DlnDestination smart contract to Fulfilled, gets the
ability to call DlnDestination.sendUnlock() method which sends a cross-chain message through deBridge infrastructure to the
DlnSource smart contract on the source chain. This message encodes a command to unlock funds initially locked for the given
order identifier, and sends them to the address specified by the solver.
When the DlnSource smart contract receives a message, before executing the command, it checks the identity of the message sender
(address and chain id), to make sure it matches the identity of the DlnDestination smart contract stored in its state.
If a maker decides to cancel their order, it must use a similar flow, and call the DlnDestination.sendCancel() method which will succeed
only if the order is neither at the Fulfilled nor Cancelled status. This method makes the smart contract send a cross-chain message to
the DlnSource contract that encodes a command to unlock funds to the maker’s address and change the order status to Cancelled.
In this case, the DlnDestination contract on the destination chain acts as a source of trust for the propagation of the order status and
sending corresponding commands.
Note: In the lifecycle of an order, cross-chain communication (messaging) is only needed once the order has achieved its final status
on the destination chain. This is so the DlnDestination smart contract can send a command to the DlnSource to unlock the
order’s liquidity to the solver’s address (in case of fulfillment) or to the maker address (in case of cancellation).
When a cross-chain message is transferred through the deBridge infrastructure, strict finality requirements are applied before the
message is signed by validators. The number of required block confirmations needed for each chain can be found here.
Risk distribution
Since the protocol doesn’t have any continuously locked liquidity, all DLN participants bear risks asynchronously.
Makers bear the risk of cross-chain infrastructure only during the short time span from the moment an order has been created,
until the moment when the order is fulfilled on the destination chain, which is typically an extremely short time period of seconds.
Solvers bear risks only from the moment an order has been fulfilled, until the moment when the liquidity is unlocked on the source chain.
These risks consist of two components:
- The risk of order reversal due to source chain reorganization or fork. This risk is taken by solvers consciously, and is controlled by
setting requirements for transaction finality: they fulfill orders only after the number of block confirmations in the source chain aligns
with their risk profile. For example, a solver may execute small orders as soon as they appear on the source chain, but wait for extra
block confirmations in the case of an exceptionally large order; more complex rules can be applied to meet the needs of solvers.
This also creates the potential to compete for orders that are not yet broadcasted, fulfilling them even BEFORE they are included on the source
blockchain, which is a win-win case: users get to receive the exact amount of funds they have requested quickly, and professional market makers
take profits according to their risk profiles without affecting users.
- Risk of the cross-chain messaging infrastructure. The collusion of consensus participants is a trade-off that is born by all interoperability
solutions without exception. The deBridge messaging infrastructure has a delegated staking and slashing module as part of the protocol design which
prevents any theoretical collusion of validators.
