- Protocol layer: on-chain smart contracts
- Infrastructure layer: solvers who perform off-chain matching and on-chain settlement of trades
Order Creation
Specifically, there are two contracts deployed per supported chain: theDlnSource 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 theDlnDestination.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.
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 callDlnDestination.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.
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.
