Why LI.FI, how does it work and what about Latency?
As a trading stack, LI.FI is often misunderstood and used alongside already integrated swapping and bridging solution.
Disclaimer: Performance-related screenshots in this document are just a "moment-in-time" capture.
TLDR: LI.FI's API overhead is just ~100ms
What is LI.FI?
LI.FI is a multi-chain liquidity aggregator. LI.FI aggregates three types of liquidity sources: DEX aggregators, solver systems, and cross-chain bridges.
DEX Aggregators: DEXs have “liquidity pools” of asset pairs and an on-chain price function. This data can be aggregated and computation can be run on it. This is what a DEX aggregator does.
Solvers: Solvers work similarly to DEX aggregators but make use of more types of on-chain liquidity pools (e.g., bei, minting/burning DAI, or tapping into lending protocols). This yields better prices but takes longer (multiple seconds).
Bridges: Bridges have liquidity pools of single assets on multiple chains, and their price calculation is not on-chain but comes from an API. Most bridges then work with a lock-and-release mechanism to transfer funds from one chain to the other.
LI.FI is a trading stack that saves you a ton of research, integration, consolidation, and maintenance overhead.
Why is LI.FI not as fast as a single DEX aggregator?
While LI.FI is an aggregator, it does fundamentally different things than a DEX aggregator from a technical perspective. Comparing them directly or even using them in parallel is the wrong usage.
TLDR: While a DEX aggregator generates prices, LI.FI discovers prices. LI.FI provides a whole trading stack for your application, while a DEX aggregator generates slippage-reducing prices for same-chain swaps. A DEX aggregator computes across mirrored on-chain data while LI.FI is aggregating APIs, which means that when you send a request to LI.FI, we're relaying this request to applicable partners and then waiting for those external parties to compute a quote and return the call data to us. That means LI.FI has to wait for others like you would have to wait for them. Since LI.FI wants to provide you the best price, we're waiting for multiple quotes to come back in order to compare and return you the best ones. Our API's waiting behavior can be customized/controlled.
More detailed difference between a DEX aggregator and LI.FI
A DEX aggregator operates on single-chain on-chain data. DEX aggregators do not talk to third-party APIs to generate prices. Blockchain data is indexed and mirrored in their own databases, and companies like Superchain.Network are able to update this data in real-time (way below sub-second). DEX aggregators then tap into their data and split trades across different liquidity pools to reduce the slippage per trade. This is especially meaningful for larger trades. All of this can happen really fast, and DEX aggregators can easily have a response time below 500ms.
Does it make sense to aggregate DEX aggregators?
Yes. DEX aggregators greatly differ in their efficiency and constantly improve their algorithms. They are also not present on the same chains. This is why it makes sense to work with multiple DEX aggregators at the same time and compare prices. This is what LI.FI does for you:
LI.FI also has its own small DEX aggregator. We only use this for small trades and to have a DEX aggregator on very new chains on which established DEX aggregators like 1inch, and 0x are not present yet.
The swap distribution is constantly changing and also differs from chain to chain:
If you’re comparing 1inch or Jupiter API response time with LI.FI’s, you’re using LI.FI the wrong way since the idea is that you would consume those liquidity sources out of LI.FI’s trading stack.
It is also very interesting to see that a DEX aggregator's performance vastly differs depending on the trade size. We can see in the following chart (left side) that 0x gets a decent amount of transactions on Arbitrum, while in absolute volume traded (right side), it is almost insignificant compared to 1inch. 0x seems to perform much better at low-volume retail trades, while 1inch excels at larger whale trades.
How does LI.FI function, and what do we do to keep API latency low?
When an API request is sent to LI.FI, LI.FI talks to RPCs, ~19 bridges, and, depending on the request, 9 DEX aggregators and 2 solvers. See here for the full list. This is a decent amount of network latency. The same network latency you’d experience if you were to implement all these solutions yourself and wait for all results to come in.
However, LI.FI takes multiple measures to ensure a seamless experience and the lowest latency.
Global API availability to reduce geographic distance
LI.FI's API is hosted in the US-East, Europe, and Southeast Asia. This reduces long distances for our partners. However, many of the liquidity sources don't have this in place, which makes it hard sometimes to guarantee short latencies.
Globally shared caching system
LI.FI has a globally shared in-memory caching system across all customers. We integrate APIs in such depth that we question every single piece of information and cache as many things as possible in tight dialogue with our partners to reduce the amount of network overhead.
(Really) Smart Order Routing
Our smart order routing understands when to talk to which solution and when not. This works not only for implementation- but also for data-driven. It might, for example, omit certain solutions for certain routes, as we know they never win on this route (regularly allowing them to prove us wrong).
Thereby, we can reduce the amount of outgoing API requests, which in return gives you a faster response.
Customize LI.FI's API response time (set timeout)
You can tell our API how long to wait for API responses and make this dependent on how many results we've received from liquidity sources in certain defined periods. Learn how to build your own timeout-strategy here: Optimizing quote response timing.
Enterprise SLAs with 3rd-Parties (e.g. private endpoints)
We build up and maintain deep relationships with all our liquidity sources. We have private endpoints, API keys, whitelisted IPs, and very high rate limits, which allow us to do way more requests than a normal business partner would be able to.
How fast is LI.FI's API?
LI.FI’s own API overhead is just ~100ms.
This is essentially the price for a lot of workloads that need to be done to support many chains, EVM and non-EVM, canonical asset management, transaction generation and tracking, 3rd-party API implementations, monitoring and maintenance, data homogenization and data analytics, customer support tooling, multi-chain dev ops toolings, fail safety and redundancy mechanisms, smart order routing and so much more.
How many people work at LI.FI and do you have dedicated dev ops?
LI.FI has more than 55 employees and multiple dedicated dev ops engineers who continuously work on the availability, scalability, reliability, and redundancy of our backend clusters. We also monitor and load-test all third-party integrations and track their performance.
Last updated
