Summary

Flex is a Everscale decentralized and distributed limit order book (DLOB), which takes a most common centralized exchange model: central limit order book (CLOB) and implements it on-chain via a distributed smart contract model.

Flex Motivation - EVM Compatible DeFi Deadend

Being able to see the future is essential for success. At this point it's obvious that the future is multi blockchain. The value keeps moving to non ETH networks. ETH TVL in DeFi is down from 98% to 67%. A multibillion dollar question is then which blockchains will dominate? Closer look at layer 1 technologies in the current market reveals that successful marketing is much more important than underlying technology. It is perceived by most that there are many promising layer 1’s to choose from, however there are significant design flaws in essentially 90% of prevailing layer 1’s on the market. These designs are either centralised or lack linear scalability or both. ETH 2.0 will not ever deliver smart contract execution capability because it's simply impossible to scale and stay backward compatible with EVM. At Everscale labs we believe that there is just one way to design layer 1 to enable almost linear scalability, throughput in millions of transactions per second and uncompromised security at the same time. High level Everscale OS design is described in this document. You are welcome to read the full Everscale whitepaper or light paper as well. The reality is that only real mass adoption can show if particular technologies are able to deliver what it promises to deliver. As overall crypto adoption grows and required transactional throughput will be in millions of TPS, layer 1’s capable of delivering such throughput will be the ones accumulating most value.

There is no EVM compatible technology that is able to handle such throughput. Decentralisation is an essential part of DeFi and protocols enabling it are often computationally intensive, ETH blockchain just can’t handle it. Therefore the future of DeFi will not include any EVM compatible designs long term. The EVM solutions that we see today will prove to be transitory. With this vision in mind we’ve designed and built FLEX. Built on Everscale OS it inherits all the features of Everscale including everything is a smart contract concept. The fact that every position in Flex order book is a separate smart contract and all order matching logic is performed by each client separately makes it the fastest DEX on the planet.

Flex Gateway To The World

Bridge built by Broxus supports transfer of value between the Everscale network and any EVM compatible network. We believe that many tokens will be moving through this bridge into Everscales direction as their owners would want to move to the future of DeFi and leave the inefficient and expensive past behind. Broxus bridge is the only fully decentralised bridge in existence and it is another example of the capabilities of Everscale OS technology.

Products that can be built on FLEX

In spite of having its own GUI the idea of Flex is similar to that of Serum on Solana. Its decentralised limit order book liquidity can be used by various DeFi players. It can have borrowing-lending markets, margin, perp, options trading dApps built on it as well as launchpads and various GUIs to the DEX itself. It will have other market makers connected to it. It can be used for decentralised KYC’ed crypto darkpools for institutional players. It can become a cross liquidity hub for centralised exchanges willing to trade against each other.

Flex General Architecture

What Problem Are We Trying to Solve?

The biggest problem with decentralised exchanges is its speed of execution, lack of advanced trading strategies ability and complex management. Here we propose a decentralised trading engine and order book with low latency and guaranteed trade execution. It is flexible — allowing extendable strategies, extremely fast — providing immediate execution and settlement of an order and both decentralised and distributed.

This allows Flex to perform on par with the Everscale blockchain performance. For example, an average execution across 128 threads will be 0.08 seconds at roughly 80,000 trading pairs messages per second throughput for one shardchain. It will take just 15 workchains to beat Binance performance and 150 workchains to compete with BATS exchange. Usage of DeBots makes it very easy to add simple or advanced user interfaces.

Flex is a decentralised and distributed limit order book (DDLOB) which takes a most common centralised exchange model: central limit order book (CLOB) and implements it on-chain via a distributed smart contract model. Many have tried this approach before and failed (EtherDelta, DDEX, Radar Relay, etc.). Up until now the problem of creating an order book on chain were: the slow speed of execution and the possibility of front-running orders.

Some are trying to solve this by moving to the fastest possible blockchain. But just having a fast blockchain is not enough because usually order books are pretty large and complex which takes time to operate on. Flex distributed atomic contracts to solve this problem, distributing the load of the order book down to the price of a single pair.

Central exchanges using CLOB such as NYSE, CBOT, Coinbase, Binance operate in microsecond time frames. That is how it looks:

Fig. 1. CLOB Exchange infographics

How are orders filled on CLOB?

The most common algorithm used is Price/Time priority, aka FIFO: all orders at the same price level are filled according to time priority; the first order at a price level is the first order matched. Up until now there was a problem implementing this algorithm on a blockchain because transactions are usually prioritized by miners based on the gas fee they pay, allowing for front-running the Time priority. Everscale does not have these problems.

CLOB are hard to implement on a blockchain because:

The size of the state needed by an order book to represent the set of outstanding orders is large and extremely costly in the smart contract environment, where users must pay for pace and compute power utilized.

[G. Wood et al., “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum project yellow paper, vol. 151, no. 2014, pp. 1–32, 2014.]

The matching logic for order books is often complicated as it must often support several different order types (such as icebergs, good-till-cancel, and stop-limit orders.

[M. Wyart, J.-P. Bouchaud, J. Kockelkoren, M. Potters, and M. Vettorazzo, “Relation between bid–ask spread, impact and volatility in order-driven markets,” Quantitative Finance, vol. 8, no. 1, pp. 41–57, 2008]

How does FLEX solve this

Flex achieves load balancing and speed of execution by distributing the logic among many atomic smart contracts, while simultaneously transferring search and decision logic to user computers. All Order Book contracts addresses are deterministically calculated: the Trading Pair and its Price order contracts.

For instance, EVER-USDT will resolve a Root of EVER-USDT trading pair. Users then can calculate an address of a particular Price Contract by entering a Price. “Code Hash=$EVER-USDT Data=1.2” will calculate an address of a contract that currently trades a EVER-USDT pair at 1.2 USDT per 1 EVER.

After performing the calculation of addresses, the user performs a read operation: querying a blockchain database with SDK over GraphQL. Since each user only calculates pairs and prices it needs, the operation takes microseconds and one query is almost instantaneous.

Let’s agree that a trading step should not be more than 0.01 (this information will be provided in the pair's Root Contract data). Users can now calculate a whole order book of this pair by entering all price steps around the target price or ask the database for all addresses of that Price contract code hash. After calculating all price step contract addresses, a user may try to retrieve all these contracts. If the contract does not exist, it means there are no orders of that price.

Fig. 2. Decentralized TIP3 architecture of the Flex

Main Functions

Ability to create new pairs

New token pairs can be added to Flex by deploying a new Pair Root contract from the Exchange Root contract. It can be done with the help of the Listing DeBot.

Ability to create new orders

If the price contract does not exist, a User can create a "Good-til-cancelled (GTC) order" by deploying the pair contract adding the price as a contract data in the constructor and sending the required amount of money to cover the trade.

For example, passing a price of $0.55 USDT into the constructor and sending 10,000 EVERs to the contract will create a sell order of 10,000 EVERs for $0.55 USDT per 1 EVER in a EVER-USDT trading pair contract. Sending USDT tokens will create a buy order.

A User can Cancel un-executed orders at any time. Flex orders also have expiration time set by users to avoid a long-forgotten order suddenly being filled.

Exchange tokens

All matched orders in the contract are executed immediately. If the contract does not have any orders it will terminate itself, this is important as the existence of the price contract at the calculated address by itself means orders of that price exist.

A “limit order” is an order to buy or sell a security at a specific price or better. A buy limit order can only be executed at the limit price or lower, and a sell limit order can only be executed at the limit price or higher. Such logic is implemented at the Flex DeBot level, which collects information about all deployed price contracts. Flex DeBot can inform the user if a better price is available when creating a new order.

A “market order” is another common trading tool. It could be filled if the User client software searches for the latest transactions in the pair contracts to sell say 10,000 EVERs. When finding a deployed contract with the best price starting from the latest executed, user client software can retrieve the offered amount and send the Currency to this contract. Sending EVERs to such a contract will immediately execute the trade with the contract price for the sent amount. This logic can again be implemented at the Flex DeBot level, and many other complex trading strategies are possible but are yet to be implemented (iceberg orders, etc.)

Economic Model

There are essentially two profit centers in the Flex Ecosystem:

-Flex Exchange
-Flex Market Maker

Flex Exchange

The Flex Exchange collects a configurable percentage fee for processing each transaction in the Order Book.

Flex Market Maker

The Flex Market Maker by providing liquidity to the Order Book facilitates the process of finding a fair price for a pair of tokens and ensures that market participants have a trading partner. If the fair price is found, the market maker would earn the price difference between their bid and ask prices when participants trade against them. The market maker may also earn a maker fee from the exchange for providing liquidity.

Team

Flex has been developed by EverX Labs, the developer of Everscale OS. The plan is to assemble a separate team for Flex after closing the first investment round. There will be a separate technical team and business team. This team will operate totally independently from EverX Labs.

Roadmap

Q3’22

Distributed Limit Order Book
Phase 1 formal verification
TradingView support
Optimized Flex Cloud
Spot markets
Limit orders
Maker / Taker order types
Decentralized User Interface
Decentralized Auth Protocol
Sub-accounts with policies
Documentation

Q4’22

Widget to buy EVERs with card
Web version with a wallet extension
Octus Bridge integration for deposits
Phase 2 formal verification

2023

Phase 3 formal verification
DAO voting
Perpetual futures
Marginal trading

Formal Verification

Flex will be the only formally verified DEX in the world. What it means is that its software was initially written in formal language and mathematically proven to be 100% correct. Formal verification is rarely used as its quite complex and expensive procedure. It is used for software that shouldn’t fail under any circumstances. For example Airbus aircraft software is formally verified.