Li.Fi

LI.FI is a multi-chain liquidity aggregation protocol that supports any-2-any swaps by aggregating bridges and DEX aggregators across +20 networks.

Our JS/TS SDK can be implemented in any front- or backend so that you can build your UX/UI around our bridge & swap functionalities. It furthermore handles all the communication between our smart routing API and smart contract and provides outstanding event and error handling.

Our REST API gives you all the information and allows deeper and custom integrations.

Implemented in 5 minutes, the widget helps to onboard users from anywhere.

If you have no time to integrate us, link to our website with your token & chain pre-configured.

ur smart contracts are open source, but our API is not. This is our competitive advantage, and we’re handling it and aligning our strategy with the big DEX aggregators like 1inch and Paraswap, who also keep their API closed source.

While our smart contracts are running decentralized, our backend has to be centralized.

Why? The amount of data processing can’t be processed on the blockchain in a fast enough manner, and at the same time, it would cost hundreds of dollars per swap computation from a gas-fee perspective.

Will it change? We’d also love to decentralize our infrastructure if the future allows it. We know that some projects are working on this, and we’re watching them closely. Around that, we also need a proper dev-ops ecosystem that allows us to keep such an infrastructure up and running and maintain it while keeping it fast and secure for the user.

We move forward in a three-step way:

Assess existing bridges on their capabilities (which chains are supported) and security.

Check if all existing chains in our system are least supported by the two bridges we’ve implemented. That way, we make sure that there is a fallback solution should liquidity be empty or if we have to turn a bridge off due to a hack or something else.

Either implement a bridge that backs up another or a bridge that expands our capabilities to bridge toward new chains.

Each bridge is graded manually and automatically based on qualitative and quantitative factors. Qualitative factors are, for example, trust assumptions and attack vectors. Quantitative factors like speed, fees, gas costs, and reliability can be measured. Our algorithm adjusts its decision-making based on these factors and generally acts after our default prioritization pattern, which says security > speed > costs. We believe that this pattern provides the most responsible and sustainable user experience. Anyone implementing our bridge aggregation protocol or SDK can adjust the prioritization pattern.

Yes, we support whitelisting and blacklisting certain bridges. We also allow for prioritizing one bridge over the other, and we allow for a change of the default prioritization pattern. That way, we allow you to act biased. For example, you might like a certain bridge protocol or DEX aggregator because you don’t trust certain others.

No matter if Ethereum owns the majority of the market, there will be multiple chains:

making Ethereum more scalable (optimistic- and zk-rollups)

trying to compete with Ethereum (see Solana, Terra, Near, Tezos, etc.)

provided by large companies or nation-states

application-focused ones (e.g. financial, gaming, social, data storage, data processing (e.g. bioinformatics)

Liquidity will have to be bridged, and a one-stop solution/an aggregator for that will always find its space.