Flash Exchange (FLEX)
Summary
Flex is a TON 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 Flex 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. 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 the 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 TON OS it inherits all the features of TON 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.
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 TON 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. TON 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, TON-USDT will resolve a Root of TON-USDT trading pair. Users then can calculate an address of a particular Price Contract by entering a Price. “Code Hash=$TON-USDT Data=1.2” will calculate an address of a contract that currently trades a TON-USDT pair at 1.2 USDT per 1 TON.
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 TONs to the contract will create a sell order of 10,000 TONs for $0.55 USDT per 1 TON in a TON-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 TONs. 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 TONs 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.)
Composition of the Order Book
Just by retrieving all deployed contracts by a contract code hash, a user can see a whole stack of the order book.
Trade history
User client can retrieve all messages for a trading pair contract and sort them by time to find the latest trades of that pair. Successful trade transactions should emit a message so it can be found later. The trade history is available through the Flex decentralized interface.
Automated Market Maker
Instead of a client software like Flex DeBot, an automatic execution could be programmed with a paid subscription method of an $Asset contract. The contract may send a message to other contracts that are subscribed to it once any trade is executed. The subscribed contract can then perform automatic strategies based on this information, to connect Automated Market Maker smart contracts or Liquidity Pools.
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.
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.
