free web page hit counter
Ethereum cross-chain DEX

Ethereum cross-chain DEX

Etherum Reddit

Reddit / Etherum Reddit 53 Views

TLDR : I want to build a cross-chain DEX on Ethereum. What do you guys think?

Cross-chain DEXs are difficult to build due to the varying consensus algorithms and security requirements of each blockchain. Blockchains can’t communicate with other blockchains and for a cross-chain DEX to be feasible, both transactions need to reach irreversible state at the same time.

I suggest a minimal architecture allowing cryptocurrencies to be exchanged without funds going through any third party by utilizing a light-weight system of collaterals smart contracts.

By requiring the market maker, the Maker, to lock collaterals in a smart contract, the second trader whose role is to create a limit order, the Taker, can fulfill the order securely (sending payments first) without risk of payment reversal or double-spending.

Collaterals are secured by oracles. Trades happen on-chain without requiring extra protocol support for them resulting in compatibility with most blockchains. As there is no third party receiving payments on traders’ behalf, there’s no trading fees for traders. There are transaction fees for running the collaterals smart contracts.

The minimal architecture is ideal for low latency, high volume trades. To use the exchange, both traders will need ETH for smart contract fees and the tokens they are exchanging. The Maker will need ETH for collaterals. This DEX is good for decentralized OTC trading and if multiple of these DEXs are set up, can be used as alternatives to large centralized exchanges.

  1. Scalability. It is impossible to process a large number of trade transactions with the current capacity of the Ethereum network (7-15 TPS);
  2. Costs. The estimated costs per trade for MVP implementation are fixed at $2 - Not really efficient for small trades but extremely cost efficient for large trades.

DoS. The current implementation of the Ethereum network has a preemptive model of transaction settlement. It means that a hypothetical project can allocate the full network capacity for its needs and, as a result, other projects refuse to serve their clients, which is unacceptable for real-time services such as DEX.

A typical scenario which consists of three following steps:

  1. Anyone matches demand/offer and sends transactions to the blockchain (it can be optimized by gas through sending a batch of pairs).
  2. Oracles get the event from the EVM and send their decisions about transfer events.
  3. If no transfer succeeds, a compensation is sent to the refund account.

The oracle smart contract is not specified, as it depends on the oracle type and does not affect the collateral smart contract code. End users from both sides choose the list of approved oracles to verify the transfer.

Smart contract interface



  • address _collateral_token.

event NewMarket(bytes32 indexed id)

New market params are added to the registry.

event TradeStart(uint256 indexed id)

The event is emitted when a trade enters its start state in a contract. (the states are described in A2)

event TradePartial(uint256 indexed id)

The event is emitted when a trade moves to its partial state in a contract. (the states are described in A2)

event TradeFinish(uint256 indexed id)

The event is emitted for the finish state of a trade in a contract. (the states are described in A2)

event TakerTransferConfirmation(uint256 indexed id, address indexed oracle)

The event is emitted with each confirmation of the Taker’s transfer by the oracle.

event TakerTransferConfirmed(uint256 indexed id)

The event notifies about the confirmed Taker’s transfer.

event MakerTransferConfirmation(uint256 indexed id, address indexed oracle)

The event is emitted with each confirmation of the Maker’s transfer by the oracle.

event MakerTransferConfirmed(uint256 indexed id)

The event notifies about the confirmed Maker’s transfer.

function getTrade(…) external view returns (…)

Fetch trade information by its id.


  • uint256 _id - trade identifier.


  • bytes32 market - market parameters hash;
  • bytes32 deal - deal parameters hash;
  • address Maker - Maker’s address;
  • address Taker - Taker’s address;
  • uint256 collateral - Maker’s collateral value;
  • uint256 MakerTransferConfirmations - count of Maker’s transfer confirmations;
  • uint256 TakerTransferConfirmations - count of Taker’s transfer confirmations;
  • uint256 startBlock - start state blockstamp of a trade;
  • uint256 partialBlock - Taker’s partial state blockstamp;
  • uint256 finishBlock - finish state blockstamp of a trade;
  • bytes memory MakerExtra - Maker’s transfer parameters (IPFS hash of JSON);
  • bytes memory TakerExtra - Taker’s transfer parameters (IPFS hash of JSON).

function addMarket(…) external returns (…)

Register new market params. The market params are the same for the Maker and Taker. They are set in the Taker’s and Maker’s signed messages as hashes to fix in specified common trade parameters. This function returns the hash, as markets in this term are not enumerable, this is just a registry of parameters - anyone can add a new item to the set.


  • uint256 _MakerTimeout - Maker’s timeout in blocks;
  • uint256 _TakerTimeout - Taker’s timeout in blocks;
  • address[] _oracles - trade oracle list;
  • uint256 _minimalConfirmations - minimal confirmation for a trade.


  • bytes32 id - market hash.

function startTrade(…) external returns (…)

A smart contract cannot match sets of orders, but can and should verify matching engine results.


  • bytes calldata _MakerOrder - ABI-encoded Maker’s order;
  • bytes calldata _MakerSignature - Ethereum signature of Maker’s order;
  • bytes calldata _TakerOrder - ABI-encoded Taker’s order;
  • bytes calldata _TakerSignature - Ethereum signature of Taker’s order.


  • uint256 id - trade identifier.

A Maker’s order is an ABI-encoded tuple of:

  • bytes32 marketId - market hash of this order;
  • bytes32 dealId - deal hash of this order;
  • uint256 collateral - collateral value;
  • uint256 deadline - deadline block;
  • bytes extra - extra data (IPFS hash of JSON encoded extra data).

A Taker’s order is an ABI-encoded tuple of:

  • bytes32 marketId - market hash of this order;
  • bytes32 dealId - deal hash of this order;
  • uint256 deadline - deadline block;
  • bytes extra - extra data (IPFS hash of JSON encoded extra data).

Extra data is a JSON-encoded byte string, example:


“account”: “16gSwn7dXbbWWCzC5UfsL2MTn9NctYpb2z”,

“nonce”: 1


Notice: extra data also depends on the used oracle and may contain oracle’s specific tags.

Deal id is a Solidity sha3 hash of:

  • uint256 sell - value to sell;
  • uint256 buy - value to buy.

Notice: the use of the trade value hash opens a perspective for private trades. In this case, a traded value is hidden (due to the publication of only hashed values), but verifiable when the value is known.

function finishTrade(…) external returns (…)

Finishes the trade and pays a refund, if any timeout is reached.


  • uint256 _id.


  • bool success.

Improved Collateral based Exchange algorithms (ICE)

ICE algorithm is designed to reduce expenses for traders and improve scalability.

Minimal scenario:

  1. A Maker places offer to the order book;
  2. A Taker accepts the offer from the order book;
  3. The Taker sends an open trade transaction;
  4. Maker’s collateral is locked by the opened trade;
  5. The Taker sends a payment to the Maker’s address;
  6. The Maker waits for the Taker’s payment confirmation (by the oracle);
  7. The Maker sends a payment to the Taker’s address;
  8. The Maker waits for the payment confirmation (by the oracle);
  9. The Maker closes the trade and releases the collateral.


FSM diagram

Limitation: it is possible to lock Maker’s collateral fund by creating fake trades. In the minimal scenario, the trade open transaction is so cheap for a Taker that it could be used as DoS attacks against Makers. Using fees will help to prevent spam attacks.

MVP gas expenses

Order book architecture

Federated order book

Solutions provided by 0xProject : Special nodes - relayers, where one relayer is one order book. The relayer provides a matching engine and an API to open and close a trade position [3].

Problems of this case:

  • Relayer is a point of failure: relayer has an opportunity to manipulate the order book
  • There is no way to exchange the orders between the relayers.

Broadcast message based order book

A bit more decentralized way to implement an order book is to send signed messages to some kind of public channels, such as IPFS PubSub. Any node can collect these messages, match them and provide a demand/offer pair for the trading pipeline.

Problems of this case:

  • Multiple instances of one order book. Therefore there should be as many matcher nodes as many versions of the order book. As the order books are not synchronized, a couple of issues on the matcher node could be tracking of used order messages, mismatch published but not received messages, etc.

Distributed database based order book

An order book can be stored distributed but off-chain with the help of such projects as OrbitDB. In this case, there are many independent matching engines that have access to the synchronized order book. Any actor is identified as an order book keeper and can store his values in the synchronized store.

Problems of this case:

  • access rights cannot be changed after a database has been created. In the future we will support the read access control and dynamic access control in such a way that the access rights can be added and removed to the database at any time without changing the database’s address.
  • OrbitDB is still an R&D project, which means that it is not production-ready now.

Establishing the chain requirements

Let us imagine that we already have a demand/offer pair. In this case, the algorithm from the scheme 1 is very close to the bi-directional cryptocurrency bridge[6][7][8]: on one side there is a request (demand), on the other side - response (offer), and also we have the third party who controls the collateral smart contract. There is one big difference: the smart contract support is not required for the trading chain, just for transferring transactions.

Requirements for the chains:

  • trading chains should have the currency transfer call only;
  • collateral chain should have the currency transfer call;
  • collateral chain should have the right to lock accounts’ balances;
  • collateral chain should have the implementation of the oracles algorithm.

Problems of this case:

  • how to estimate the collateral minimum?
  • how to manage collateral oracles?
submitted by /u/kola401
[link] [comments]