The Hydranet DEX combines different Layer 2 off-chain solutions to facilitate fast and cheap cross-chain trading. If you are interested in learning more about blockchain layers, you can find more information here.

The basics of Layer 2 off-chain trading

Before we delve into how the Hydranet DEX works, we need to understand the basics of off-chain trading. Off-chain trading makes it possible to cluster dozens of trades into only a few on-chain transactions. The Bitcoin and Ethereum blockchains both have their own off-chain technologies being worked on by several different actors. The fundamentals of both technologies are however principally the same.

To trade off-chain, there must exist a payment channel (state channel for Ethereum) between two transacting parties. This payment channel is created by the two parties depositing funds into a multi-signature contract. Since the contract runs entirely on the blockchain there is a network fee associated with this operation, but the two parties will always remain in custody of their funds.

With an open payment channel, the two parties trade by sending signed instructions on how to claim the funds (all, or parts of it) locked in the multi-signature contract. The instructions require no confirmation by the blockchain and are therefore virtually instant and feeless. 

If any of the two transacting parties run out of funds but want to trade more, the trader can simply increase the capacity of the payment channel by locking more funds in the multi-signature contract. When either party is done transacting, the payment channel is closed and settled on-chain. The latest state/balance of the payment channel is then sent to the multi-signature contract to unlock each party’s rightful share of the total funds locked in the contract.

The Lightning and Connext networks will avoid opening unnecessary payment channels as long as there are routing alternatives, which makes it possible to reach virtually anyone in the network, as long as you have your receiver’s payment channel information. Consider the example in which both Alice and Bob have open payment channels with Charlie. Alice owes Bob 1 BTC and figures she could use the Lightning Network to wire Bob his funds. Alice and Bob do not have a payment channel open between them, but because both of them have open payment channels with Charlie, they can use Charlie to route their payment. Alice will send 1 BTC to Charlie, and Charlie will send 1 BTC to Bob. Charlie will not have to do anything, and will probably not be aware that Alice sent BTC to Bob via him. 

So, in short, what are the benefits with off-chain transactions?

• Off-chain trades require no confirmation on the blockchain, which paves for fast and cheap trading while mitigating on-chain congestion. 
• The transaction history of the payment channel will only be known to the transacting parties for increased privacy. Only on-chain activities are publicly visible.

The Hydranet DEX solution

The Hydranet DEX consists of two types of communicating nodes; HUBs and Clients. While the Clients are what the traders interact with, the HUBs are the vital elements that enable Clients to trade.

The HUB is a complex piece of technology, but is essentially nothing more than a matchmaker. A HUB includes the following main components:

• Lightning Network node
• Connext Network node
• Orderbook engine 
• Matchmaking engine
• Channel rental engine

The Lightning and Connext nodes are the HUB’s gateway into the Bitcoin and Ethereum Layer 2 off-chain networks. Without the nodes, it would not be possible to open payment channels to/from other traders in the off-chain networks. The orderbook engine track and control the trade orders instantiated by the Clients in the Hydranet DEX. It stores and runs the Hydranet DEX orderbook locally, and forwards the information to the Clients in the Network. The Matchmaking engine is the functionality that matches two transacting Clients. When a Client creates a trade order, the Matchmaking engine scans the local database for a match. If a match is found, the Matchmaking engine connects the two transacting Clients, if not, the order is stored locally in the HUB’s Orderbook engine and will be displayed on the Clients’ orderbooks. Lastly, the Channel rental engine is used by Clients to open payment channels for the currency they want to receive. Remember, to open a payment channel, the user must deposit funds into a multi-signature contract. If the user lacks these funds (which is probably the case when the user wants to buy a specific currency for the first time), the user will not be able to open the payment channel. To solve this, the Clients in the Hydranet DEX can rent liquidity from the HUB to open a payment channel with which the Client can receive funds. 

The Client is the trader’s gateway into the Hydranet DEX. It is a downloadable desktop application that runs its own Lightning and Connext nodes for access to the Bitcoin and Ethereum Layer 2 off-chain networks. The Client mainly consists of a Multi-Currency Light Wallet (MCLW) and a classical orderbook. In the MCLW, traders can store their funds and control the on- and off-boarding of funds to the Lightning and Connext networks (opening and closing of payment channels). With funds on the off-chain networks, the trader can use the orderbook to trade with other clients in the Hydranet DEX. 

A trade executed on the Hydranet DEX is essentially the same thing as a transaction made on a payment channel, but with some help from the HUB. When two Clients match for a trade, the HUB connects these Clients and assures that both of them receive all necessary information about the other Client and about the trade order (Lightning channel ID, Connext channel ID, Client ID, order ID). When the Clients are connected, the HUB is not needed anymore, the Clients will manage the remaining steps of the trade by themselves. Safety and protection from malicious acts becomes a relevant topic at this instance. Neither Client wants to end up in a situation in which they have sent funds to the other Client but not received any funds back. To ensure that this does not happen, the Hydranet DEX uses hashed time-lock contracts (HTLC) for the trade between Clients. A HTLC is a type of smart contract used for trading in decentralized payment systems. The two trading Clients will send their funds to the HTLC. The HTLC contains all the details about the trade and will only release the funds if the conditions for the trade are met. If either Client fails to meet the conditions, either by not sending the agreed upon funds to the HTLC or simply taking too long to send thet agreed upon funds, the funds in the HTLC will be returned to its proprietors. This solution provides security for both Clients in the trade and enables trustless trading between them. 

To get a better understanding of what happens when a trade is performed using the Hydranet DEX, you can study this fictive trading scenario:

Alice wants to trade her 1 BTC for 1 ETH. She is a long-time user of the Hydranet DEX and already has open payment channels with the HUB in the Hydranet DEX. Conveniently the states of her payment channels allow her to send 1 BTC and also receive 1 ETH. She is in no hurry with her trade and decides to place a limit order on the Hydranet DEX. When she places the order, her Client sends the information to the HUB. The HUB Matchmaking engine scans its local database for matching orders, but cannot find one. The information about Alice’s order is therefore stored in the HUB’s local database and is also forwarded to the Orderbook engine, which displays her order on the orderbook. 

Bob, a Bitcoin fanatic, has miraculously found 1 ETH laying around in his wallet. He wants to trade this 1 ETH for 1 BTC and decides to try the Hydranet DEX for this operation. He downloads the Hydranet Client, deposits his 1 ETH to the Client, and is now ready to begin his trade. Bob starts by opening a Connext state channel, which will allow him to send his 1 ETH. Since he wants to receive 1 BTC, he rents liquidity from the HUB and opens a Lightning payment channel. He navigates to the order book and finds the limit order placed by Alice. He decides to place a market order and completely fill Alice’s order. 

As Bob presses buy on his Client, the information is sent to the HUB. The Matchmaking engine in the HUB scans its local database and finds Alice’s order. It’s a match! The Matchmaking engine sends Alice’s information to Bob and Bob’s information to Alice (Lightning channel ID, Connext channel ID, Client ID, order ID), which allows their Clients to connect. Before the trade is executed, Alice’s and Bob’s Clients validate that the trade is correct (currency and amount). If nothing malicious with the trade is found, the Lightning and Connext transactions take place. 

The trade is finished! Alice and Bob can now decide if they want to continue their trading journey on the Hydranet DEX or if they want to close their respective payment channels and unlock their funds from the multi-signature contracts. 

The difference from an ordinary CEX

What is the technical difference between the Hydranet DEX and other exchanges? The main difference is the transaction handling. At other exchanges, all the computationally intensive operations are typically done at a single centralized place. Although the HUB in the Hydranet DEX is important for transaction handling, its main task is to be a mediator between the different Clients that exist in the Hydranet DEX. When two Clients are connected for a trade, the HUB is in fact not involved anymore. The trade validation and execution are done entirely by the Clients. Since a Client will most likely not do more than a few transactions per second, combined with the Layer 2 off-chain solutions, the Hydranet DEX can theoretically scale indefinitely.