2019: Year of the DEX

Is the winter of cryptocurrency prices the golden age of blockchain technology? Welcome 2019, the year of Decentralized Exchanges (DEX)

From the CMC editorial team: We’ve heard lots of hype around DEXes billing 2019 as the year that they might take off. Why and how could that be? Find out more in this article!


  • Centralized Exchanges vs. Decentralized Exchanges: Benefits and downsides.
  • Implementation approaches for Decentralized Exchanges.
  • New wave of blockchain innovations Decentralized Exchanges will benefit from.

Everyone that is or has been involved with cryptocurrencies and blockchain technology can sense, just with a quick look at the main cryptocurrencies’ prices, the freezing winds of crypto winter. The hype has passed, the bubble has deflated, and all the smoke has dissipated, but this is not necessarily a bad thing. In times like these is when disruptive technologies and innovation thrives, and ​Decentralized Exchanges (DEXs) are one of these potential thrivers ​benefiting from innovation in the cryptocurrency ecosystem in 2019.

What is a Decentralized Exchange?​ You may be wondering. In Centralized Exchanges (CEX), the owner of the platform is our middleman (our crypto-banker). It is charge of storing and managing all the funds traded in their system. CEXs are easy to use and access, and they offer a high liquidity and advanced trading tools, as well as serving as a gateway between FIAT currencies and crypto assets. However, as crypto-lovers ​we know the risks of centralization, and relying on a middleman can lead to risks ​such as ​the death of the Quadriga’s exchange CEO and the loss of the keys guarding users funds​ (in CEXs we have a clear single point of failure) or censorship. ​DEXs aim to remove middlemen and single point of failures in exchanges by managing trades directly between users ​(peer-to-peer) through the underlying blockchain platform, without relying on a central platform. Thus, DEXs goal is simply to provide the infrastructure for buyers of an asset to find sellers and vice versa.

The main benefit of DEXs compared to CEXs is clear: ​(1) They are “trustless”​. There is no need for a middleman anymore. Consequently, ​users are the ones in charge of their funds, and not a centralized platform ​(whose CEO may die, guarded keys stolen, or infrastructure hacked); (2) as user’s control their own funds, and there is no central manager of the platform, ​there is no possible censorship ​(funds cannot be frozen, nor users banned), ​there is no KYC required​ to start trading, and ​exchanges are “private” ​(as private as the transactions in the DEX’s underlying technology), there is no central platform knowing every trade you make; (3) and more importantly, generally, in DEXs you can make ​any kind of exchange between assets ​(as long as a buyer and a seller orders match), so you are not limited to the exchange of listed tokens as in CEXs.

Centralized Decentralized
Exchange control funds User control funds
Not anonymous Anonymous
Hacks and downtime No hacks and server downtime
Listed cryptocurrencies Any time of exchange
KYC required No KYC required
Possible censorship No censorship possible

But as the old saying goes, ​“all that glitters is not gold”. C​urrent DEX technologies have certain downsides yet to be fixed. First and foremost, DEXs are currently ​not easy to use for average users. ​We techies may be comfortable using wallets, managing keys and seeds, and signing transactions, but average users are afraid of this kind of stuff. Moreover, as trades are peer-to-peer, some exchanges require users to be online in order to fulfill their order (this sounds crazy, right?). UX is the main reason why newcomers to the cryptoworld favor CEXs over DEXs for their trading and crypto shopping. As a consequence of this poor UX, DEXs have​ low liquidity for certain currencies and assets​. Again, in case you forgot this minor detail, in DEXs trades are peer-to-peer, so if you are looking to exchange Bitcoins for Litecoins, you necessarily need to find a counterpart (or parts) willing to exchange their precious Litecoins for your offered number of Bitcoins. This may not be an easy task for certain currencies or if the number of base users in the DEX is not high.

Adding to this ​current performance limitations of DEX​ platforms, we have the perfect storm responsible for preventing DEXs’ massive adoption (and lack of users). Fortunately, these ​are the kind of problems that the new wave of developments in the blockchain ecosystem will help to fix in DEXs​. But before we jump to that. How are current DEXs built?

Centralized Decentralized
Easy to use Not easy to use
Advanced tools Basic features
Liquidity Low Liquidity
FIAT exchange possible No FIAT exchange possible

There are three main design approaches for DEXs:

On-chain order books and settlements

This was the design approach of the first generation of DEX’s. They were ​entirely blockchain-based​. Every new order or adjustment to an existing order, updates the state of the blockchain. Thus, the entity ruling the state is a smart contract responsible for recording user orders, locking the funds, matching orders and triggering the exchange. This approach ​offers the underlying decentralization, trust and security of the blockchain platform the DEX is implemented​ in.

However, this method ​renders exchanges illiquid​ if there is not an enough volume of orders in the system; it is ​slow ​(our bottleneck in the execution of orders in the DEX is the smart contract and the maximum transactions per second in the blockchain, imagine running a decentralized stock exchange over this technology); ​expensive​ (every new order or order update, as well as the exchange itself, means a smart contract execution, with its consequent gas expense); and inoperable “by-design” with other platforms​, and this is a huge limitation. What do I mean by inoperable? That in this type of DEXs you are only able to exchange tokens that​ “live”​ on the same blockchain platform the DEX smart contract is deployed in (if no additional blockchain interconnection means are used). Thus, if we deploy an Ethereum-based on-chain DEX, through this platform we will only be able to exchange tokens deployed over the Ethereum mainnet. Even more, on-chain DEXs are usually implemented to allow the exchange of very specific token standards, such as the ubiquitous ERC20 and ERC721, limiting even more the amount of assets to be traded through the decentralized platform.

Examples of DEXs implemented using this approach are, for instance, ​DEX.to​p, or DEXs built using the EIP823 standard proposal (or variations of it). As not everything in the cryptoworld has to be Ethereum-based, let me share with you a representative DEX implemented using this approach over another major blockchain platform such as EOS, Tokena. ​Tokena​ is currently an on-chain DEX implemented over EOS that uses an intermediate token to minimize the commissions to be paid by users.

On-chain orderbook and settlement DEX
No interoperability (limited to specific tokens and standards)
Expensive (gas per action)
Slow (smart contract bottleneck)
High volume required
User funds locked until trades are triggered

Off-chain order books with on-chain settlement

This is the ​approach followed by DEX implemented over Layer 2 blockchain protocols such as Ethereum’s 0x protocol.​ While the execution of trades occurs on the Ethereum blockchain (or any other underlying blockchain used by the DEX and the relay protocol), giving users control of their funds until the trade takes place (and not having to block their funds until order is performed), the order books are hosted by third-parties Relayers. ​These Relayers host and maintain order books, and using the 0x architecture. They broadcast every new order ​pooling all the liquidity of the system together and creating a more robust trading infrastructure.​ After submitting an order of the Relayer, the market maker waits for a taker to fill that order, at which point the trade is trustlessly executed in the blockchain (through a 0x smart contract).

This design approach​ leads to lower commissions​, as no gas has to be paid for new orders or order updates, and the only two commissions to be paid is one to the relayers that facilitated the trade, and the gas required to perform the on-chain exchange of tokens between users. In 0x protocol, anyone can be a relayer and earn additional tokens for making trades possible, thus, covering some of the commissions required to perform their trades. Additionally, the fact that orders are ​processed off-chain reduces the smart contract / blockchain bottleneck we had in on-chain DEXs​,​ enhancing the DEX performance​.

Once again, one of the main drawbacks of this type of DEXs is the lack of interoperability with other platforms. In the case of 0x protocol-based DEXs, we will only be able to trade tokens ​living​ on the Ethereum mainnet. What’s more, according to the specific DEX implementation, additional limitations may exist in the specific token standards that we are allowed to trade (you are right, again, ERC20, ERC721 and some of their variants are the preferred compatible standards for almost every member in this family of DEXs). To interoperability, we must add an ​additional pain point which is data availability. ​DEXs that use off-chain mechanisms to store order books and perform order matching are delegating this operation to relayers who could potential manipulate order matching in a malicious way exposing a vulnerability in the system.

A representative of this type of DEXs? ​Radar Relay​, the perfect example of a DEX implemented using 0x protocol as a relay protocol.

On-chain orderbook and off-chain settlement DEX
No interoperability (limited to specific tokens and standards).
Less commissions
Better performance
Higher liquidity
No user funds locked

Smart contract-managed reserves

This type of DEX is complementary to the previous two, and its main aim is ​to increase liquidity and minimize a DEX’s difficulties in connecting buyers with sellers​. With smart contract-managed reserves, instead of having to directly find a buyer for an asset, a user can trade with an external reserve, depositing bitcoin into the reserve and receiving the counterpart asset in return. It is analogous to having a decentralized bank offering liquidity to the system. By including smart contract-managed reserves to a DEX, ​we are adding a solution to circumvent the double coincidence of wants and open up illiquid tokens for trade. ​Drawbacks? This requires a third-party acting as a bank and offering these staked funds, or the implementation of an advanced policy of staking and rewards to favor users to lock some of their funds for the sake of the DEX’s liquidity in order to decentralize the management of the reserves. A representative project using this approach could be ​Bancor​, a decentralized cross-liquidity network.

Smart contract-managed reserves
Enhances liquidity
Some degree of centralization

A new wave of blockchain innovation

Cool, now you know the different DEX implementation approaches and how current DEXs are implemented, but why their lack of adoption if they have all these benefits? As you may predict from the previous overview, the main issues of current implementations are mainly scalability, liquidity, interoperability and UX. ​How does the new wave of developments being played out in the blockchain ecosystem help us with the development of a next-generation of DEX? ​Let me get you through this interesting landscape.

Issues to be tackled by the new generation of DEXs

Scalability, Ethereum 2.0 and sharding: W​e saw that one of the ​main limitations in the design of DEXs was scalability​. For on-chain DEXs we had smart contract and blockchain limitations, and for the off-chain we needed additional Layer 2 protocols to enhance scalability. The development of new generation of blockchain platforms, such as NEO, NEM or Ethereum 2.0 will enable the development of more scalable DEXs.

Let’s focus on Ethereum 2.0 for a moment. Apart from layer 2 improvements, at a blockchain level, what kind of improvements are being made to boost its scalability?​ The most promising is sharding. ​Sharding consists of ​dividing the Ethereum network into different subnetworks (shards) with a local consensus so that the validation of blocks doesn’t have to be performed by every node in the network​, but only by the members of a shard. In parallel, independent shards communicate with each other to reach a global consensus within the network. For this to be possible, Ethereum will have to port from a Proof-of-Work consensus to a Proof-of-Stake one (​something that we may see in the next few months​). It is expected that a sharded Ethereum will be able to process more than 15,000 transactions per second ​(not bad for the implementation of scalable on-chain DEX).

Source: ​https://medium.com/rocket-pool/ethereum-2-0-76d0c8a76605

Interoperability and Interchain Protocols:​ ​So, we have fixed scalability, but what about interoperability? We can have a very scalable Ethereum platform, but we still can only trade Ethereum-based tokens. Here is where projects like ​Cosmos​ and ​Polkadot​ come into play. These projects aim to interconnect blockchain platforms of different nature, such as Ethereum and Bitcoin, or NEM and ZCash. How do these interchain protocol work? Both projects ​are building an overlapping blockchain for the interconnection of the different blockchains.

Cosmos has the Inter Blockchain Communication (IBC) protocol to allow blockchain to interact with other blockchains. The network of blockchains will communicate with each other through IBC, being the Cosmos network the core entity. This core entity is called the Cosmos Hub, and all connected blockchains talk to it to interoperate. Over this structure, Cosmos uses a Chain Relay (analogous to the 0x protocol relays we know). Chain Relays is the ​technical module in IBC that allow blockchains to read and validate events in other blockchains.​ Imagine that a smart contract on Ethereum wants to figure out if a specific transaction was performed in Bitcoin, then the smart contract needs to verify through the Relay Chain if this transaction has been already validated in Bitcoin, and if it has reached finality. Finally, ​Peg Zones are nodes that act as gateways between the different blockchains and allow the Cosmos Network to connect to other blockchain networks.​ For Peg Zones to work they require a specific smart contract in each of the connected chains to enable the exchange of tokens between them.

Source: ​https://cosmos.network

And what about Polkadot?​ Polkadot and Cosmos follow similar approaches for interoperability. They are building and overlapping blockchain and consensus algorithms over the interconnection of blockchains. In the case of Polkadot, Peg Zones are called Bridges, and they also use Chain Relays for the communication between blockchains. The​ biggest difference is on how they plan to connect the chains and share security.​ With Polkadot the network security is pooled and shared. This means that individual chains can leverage collective security without having to start from scratch to gain traction and trust.

Source: ​https://polkadot.network

These technologies are still under development, so we won’t see, at least for a few months, any DEXs being built over these interoperability protocols and enabling the exchange of assets between different networks. Nonetheless, we see clearly the benefits of this interoperability proposals for the implementation of the next-generation of DEXs.

UX and liquidity using intermediate tokens:​ ​Similar to contract-managed reserves, we have an additional type of DEXs that use independent blockchains as their core infrastructure for the exchange of assets such as Waves, Stellar, or even Ripple. These platforms allow the decentralized exchange of any two assets (of any kind) using an intermediate token. Thus, if I want to exchange Bitcoins for Ethers, internally the intermediate token will be used between the two assets in order to fulfill the trade. Actually, this implementation of DEXs ​works as a path-finding protocol that, leveraging the use of intermediate tokens, aims to find the shortest path (and with a lower cost) to exchange one type of asset for another. ​The use of this path-finding approach and an independent blockchain optimizes the match of buyer and seller orders, increases liquidity and allows the implementation of some trading advanced tools (due to the use of a dedicated blockchain infrastructure and not a general-purpose one). This type of implementation is the one that ​Binance has followed for the development of their brand-new product, Binance DEX.​ Binance ​“has addressed the main concerns plaguing the current DEX adoption through a well-integrated user experience and tackling speed with blocks being confirmed ever second”​ .

The future of DEXs, now!

Considering this new wave of innovation,​ is there any DEX that is already tackling DEXs current limitations, i.e. a representative for this next-generation DEX? ​That’s what we’re tackling at ​ContractLand​. The design is based on two main technologies, Terra-Chain and Terra-Bridge. These technologies are specifically built with the implementation of a new generation of DEXs in mind. Unlike the previously mentioned projects, that are general-purpose and are not yet production-ready, Terra-Chain and Terra-Bridge ​are being specifically implemented to ease the trade and exchange of assets in a efficient way between different blockchains using production-ready technology ​(this is the reason why we don’t see the technology implemented over Polkadot or Cosmos, as they are not ready yet)​.

Let’s start by taking a look at Terra-Chain.​ Terra-Chain is a blockchain platform​ designed with scalability in mind to support critical mass. It doesn’t implement any inherent functionalities, and offloads the application-specific logic to the application layer (i.e. not general-purpose). Terra-Chain does not allow arbitrary logic on smart contracts. It runs a Proof-of-Authority (PoA) consensus, and currently ​can handle over 3000 transactions per second. ​Terra-Chain also allows the implementation of completely on-chain DEXs, as it fixes to a large degree current DEX scalability issue.

And what about interoperability? Terra-Bridge’s technology establishes ​trust-free cross-chain bridges between EVM based chains​ and Bitcoin-like chains. The bridge provides the ability to perform​ interchain communication in a multi-chain ecosystem (analogous to what Polkadot and Cosmos do). One of the current work-in-progress of Terra-Bridge is that it only supports for now cross-chain transfers between EVM-based chains, and Bitcoin-like networks. The good thing is that Terra-Bridge operates with a PoA consensus independent from Terra Chain. This opens the possibility of enhancing the compatibility of Terra-Bridge with other non EVM-based chains.

There are ​3 basic roles in the upkeep of an app-chain in a framework like this: chain validators, bridge validators, and delegators.

  • Chain validators​ are in charge of ​validating new blocks in Terra-Chain.​ Validators will act as such if sufficient funds have been deposited by him or other parties in order for him to be selected. A validator must run a chain client implementation with high availability and bandwidth and maintain the proper functioning of the blockchain network. This process involves receiving, validating and publishing candidate blocks. While the bridge to connect with a new blockchain system can be develop and proposed by the core development team, is it up to the validators to verify and integrate the bridge as part the app-chain. Validators that misbehave will be punished losing the entire bond they used to obtain their role. Thus, validators can be seen as the miners of PoW blockchains.
  • Bridge validators play a similar role as chain validators but for bridges.​ Each bridge in an app-chain has its own consensus and security ecosystem maintained by its bridge validator set. Just like chain validators, a bridge validator must run the bridge client and necessary corresponding blockchain nodes for relaying cross-chain messages. Bonded bridge validators that fails to delivery on their responsibility will be punished (as chain validators are).
  • A delegator is a stake-holding party who contributes to the security bond of a chain or bridge validator.​ They have no additional role except to place capital risk and as such to signal that they trust a particular validator (or set thereof) to act responsibly in their maintenance of the network. They receive a portion of the transaction fees paid out to the validators proportional to their stake contribution.
Source: ​https://contractland.io

Are there any other projects using this technology? There are a few, such as Ambrosus, which is​ leveraging Terra-Chain and Terra-Bridge to build a blockchain-powered IoT network for food and pharmaceutical enterprises, ​enabling secure and frictionless dialogue between sensors, distributed ledgers and databases to optimise supply chain visibility and quality assurance. So at ContractLand we believe this technology can be extended to more than just DEXs – something to further explore!

And this is all for now, folks! The price of your favorite cryptocurrency may be painfully low compared to early last year, but that doesn’t mean that you can’t enjoy these exciting times to create and experience this new wave of blockchain innovations and new DEX implementations. You may not be aware now, but together we are shaping the basis of brand-new financial infrastructures. Warmer times are approaching for the cryptoworld.


  • https://www.cryptocompare.com/exchanges/guides/what-is-a-decentralized-exchange/ ·​ ​https://dex.top
  • https://eips.ethereum.org/EIPS/eip-823
  • https://radarrelay.com
  • https://0x.org
  • https://about.bancor.network
  • https://medium.com/@davekaj/blockchain-interoperability-cosmos-vs-polkadot-48097d54d2e2 ·​ ​https://medium.com/rocket-pool/ethereum-2-0-76d0c8a76605
  • https://cosmos.network
  • https://polkadot.network
  • http://contractland.io

About the author

ContractLand is a chain built for the decentralized trading of cryptocurrencies.