Navigator : Swap Routing Engine
The Navigator engine uses the liquidity of all existing DEXs in the Klaytn network. We guarantee that users can always buy tokens at the lowest price by finding the optimal route via multiple DEXs, tokens, and protocols for one swap transaction. To guarantee this, organic and stable interlocking of various components is needed.
Swapscanner provides a route to buy tokens at the lowest price for traders by processing all the pipelines of the following things within one second (sub second) through 1. Navigator, 2. Klaytn Node Cluster, and 3. NAEP (Navigator Aggregation Execution Protocol) systems to be described below.
- Blockchain synchronization with mainnet
- Extraction of liquidity information from blockchain data
- Calculation of the best route
Navigator is a unique algorithm of Swapscanner, which finds the optimal route by using in real time the liquidity data updated to buy tokens at the lowest price.
- It extracts the optimal route by analyzing all liquidity data within one second by optimizing a huge amount of calculation algorithm and processing it using a distributed system.
Assuming that approximately 150 tokens are listed, the number of cases increases 150 times whenever passing through one token. For example, when going through 5 tokens, the total number of routes is 75,937,500,000. Considering the number of cases in which the tokens to be swapped are divided into multiple routes, the amount of calculation increases exponentially.
If the computing speed to perform this amount of calculation becomes slow, we can say that it is already not an optimal route. The creation time of default block of Klaytn is 1 second. Since blocks are created every second, liquidity can fluctuate every second.
Namely, an optimal route can be extracted when a huge amount of calculation can be processed within 1 second, which is the Klaytn block creation time. Swapscanner have made the calculation algorithm that seemed to be impossible using its technology.
- It finds the optimal route by including both gas fee and DEX fees in the calculation, as well as the simple liquidity ratio calculation.
Each DEX and each pair have different liquidity and gas fee. You cannot extract the optimal route through only calculation of the liquidity ratio. Navigator has included the gas fee and fees generated when going through each DEX in its calculations.
- It collects the latest liquidity data every <1 second and utilizes the data to calculate the optimal route in real time.
As liquidity data can change every second, Navigator always needs the latest liquidity data to guarantee that users can buy tokens at the lowest price. The liquidity data before one second has already become stale and valueless data. Most DEXs update this data once every 10 seconds. However, Navigator collects liquidity data every <1 second and use it to calculate the optimal route in real time by utilizing Klaytn node cluster of the stable Swapscanner.
The Klaytn node enables the liquidity data of DEXs and pairs to be provided. How quickly this node synchronizes with the real network becomes the most important factor when finding the optimal route in real time. Swapscanner operates nodes in the following ways.
- It operates multiple nodes so that the function does not stop under any circumstances..
Like all production server infrastructure, when only one node is operated and a failure occurs, the entire function will stop. Swapscanner does not conduct the risky behavior of using only one node to save money.
- It uses high performance nodes that have more than 200% of the recommended specifications of Klaytn.
Node reads, verifies, and stores data whenever every block is created. As the number of transactions in a block increase, the better performance node is required. Unlike other services that use inexpensive nodes, Swapscanner uses high-performance nodes to reduce costs. The nodes of Swapscanner utilize 16 vCPU, 64GB RAM, and 120k Provisioned IOPS SSD. This performance is over 200% of the recommended specifications of Klaytn.
- The system responds immediately to the failure.
The nodes which Swapscanner operates check the synchronization with the mainnet every second and monitor any possible failures. When a failure occurs, the system immediately fails over the failed node and automatically replaces it with a new node through load balancer, health check, and advanced metric collection without human intervention.
The role of this protocol (smart contract) is to actually execute the token purchase route in real time at the lowest price that Navigator calculates. It is important to calculate it, but it is also a key technology that makes it to be actually executed.
- It responds to the liquidity that can change at every block by processing all routes in one transaction.
If the swap is executed by dividing it into several transactions due to the complexity of the route, all transactions may not be contained in one block. Since liquidity can change from block to block, it cannot be said that the optimal route has been executed when it is not processed in one transaction.
- You don’t have to worry about it, even if the DEX interlocked is not safe, because you can directly verify the amount of token to be received.
You don’t have to worry about it, even if the transaction execution is delayed and the swap is executed to the optimal route of the past several seconds ago. NAEP verifies the volume of tokens to receive while the transaction is executed, and automatically rolls back the transaction if it falls below the expected volume. At this time, the swap is not performed, and no tokens disappear. In other words, you don't have to worry about it at all, even if the DEX interlocked by Swapscanner is not safe!
- It is safe against MITM (man-in-the-middle) attacks.
NAEP will never execute a transaction if it is not a swap route issued by Navigator. When executing a transaction, if the receiving address of a transaction coincides with the NAEP contract address, anyone cannot manipulate the actual transaction data (tx data). This can be performed with the following execution structure.
1) Navigator calculates the route, directly signs on the route data, and sends it to the user.
2) The user signs on the data again and sends it to NAEP.
3) NAEP executes the actual swap after verifying both the user's signature and the Navigator's signature.
Last modified 1yr ago