We're offering the best API:

• We support the most chains, bridges, DEX aggregators and single DEXs

• We support the Most Routes

• We offer the Best Prices

• Fastest API (if you only whitelist the bridges & DEXs our competition supports)

• Cross-Chain Contract Call Support

Values & Positioning:

• Integrity - no misleading comparison. An API with three supported bridges is faster than one with 11. Supporting all DEX aggregators is slower than supporting just one. Adjust our API to your needs. We don't fake volumes to appear bigger than we are.

• We're 100% committed to aggregation.

• We're 100% focused on B2B, focusing on your developer's needs.

• We're 100% neutral and don't build our own bridge alongside

• We allow not only asset transfers but also cross-chain contract calls

• We not only aggregate liquidity networks but also allow you to plug in the data messaging bridge of your choice (Axelar, Nomad, LayerZero, Hyperlane - soon)

Approach:

• Security First: Read more in the Security First-Section

• Adjust our tech to your risk profile by allowing and denying chains, bridges, and DEXs as you trust them or not

  • We have the most supported bridges, chains, and DEXs, which can be turned on and off on a per-request basis - this also affects API performance. Adjust to your use case.

• We're the most active research company in the bridge ecosystem

  • Read up on trust assumptions

  • Use our arbitrary messaging bridge comparison framework (40+ pages)

  • We're maintaining the official ethereum.org bridge-documentation

  • In collaboration with Consensys, we're working on a comprehensive bridge-risk comparison framework

• Best Support

  • We provide the best documentation for our SDK and API

  • We're providing a Discord customer support bot for our clients to automate self-help for their users

• Multi-Chain Gas Provisioning

  • Contact us to discuss how to deal with the lack of gas on destination chains

• Enterprise Support

  • We genuinely understand large-scale needs

  • Get dedicated API instances independent of other clients' traffic and only get upgraded on demand.

  • Talk to us about compliance

  • Custom integrations with private institutional-grade blockchains

Top Companies Trust LI.FI

We work closely with companies like Consensys, Ledger, BitGo, Bitpanda, and other enterprise players.

Seamless User-Onboarding from anywhere!

Without LI.FI: For users to start using a new dApp, they often need to go to DEX & bridge interfaces in order to get the right asset, which involves a lot of decision-making.

With LI.FI: Implemented in your dApp interface in any custom way, users can pick any asset on any chain and bridge, swap and move it on the spot, into the desired asset or vault on your dApp.

Cross-chain Swaps

Without LI.FI: DApps are offering asset swaps on one chain and are about loose users as they have to go to other bridges & DEXes.

With LI.FI: DApps can implement our SDK and offer cross-chain bridging & swaps whereby they can always use our "prefer" setting to prefer their own LPs/AMMs whenever possible to avoid losing revenue by doing so.

Cross-Chain Yield Farming Strategies

Without LI.FI: Yield aggregators are primarily acting within one ecosystem. Cross-chain strategies offer much higher yields and are widely untapped.

With LI.FI: Vault contracts keep track of yields across multiple chains, deposit their funds in the best way, and then find the most trustless and cheapest bridge with enough liquidity to deposit into the highest yield generating protocols.

Multi-Chain Money Markets

Without LI.FI: Users can't borrow on chain A without moving funds across chains first.

With LI.FI: DApps can communicate across chains and let users collateralize, borrow and repay their loans on different chains.

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.

Our Thesis

• The future is multi-chain

• Infrastructure and liquidity will continue to fragment

• Aggregating and connecting liquidity sources will pave the way for mass adoption

Ecosystem Problems

dApps: Many users come across a new interesting dApp on a chain they don't have funds in and struggle to get their funds there. This is significant friction in user onboarding as they have to research and find bridges to that chain to start using the dApp.

Yield Aggregators: There are definitely protocols with the better yield on new L2/side-chains but there isn't a secure, reliable way to transfer your funds.

Wallets: Multichain wallets want to compete with CEXs, but they don't have a way to allow easy swap between assets like CEXs

DeFi Protocols: DeFi Dashboards, lending protocols, yield farms, etc., that are present on new chains create a need to do cross-chain swaps, but their users have to wander the ecosystem to quench this need.

Developer Problems

Too many bridges to educate yourself about. It'd be good to have access to all of them and get good guidance from people and algorithms that are specialized. -> LI.FI does that.

Bridges are still immature so it's good to have not only one bridge but fallback solutions in place. Immaturity comes with security risks, insufficient liquidity and a lot of maintenance overhead.

-> LI.FI maintains all bridge connections, gives you access to multiple ones and handles fallbacks and decision-making programmatically.

Bridges are most often not enough. You also need DEXs/DEX aggregators as bridges are limited to stablecoins and native currencies.

-> LI.FI not only aggregates bridges, but also connects to sorts of DEX aggregators and if not available, the DEXs directly in order to find the best swap possible to arrive at the desired token and to allow to start the whole process with any asset.

A data mesh of cross-chain liquidity sources: cross-chain liquidity networks, bridges, DEXs, bridges, and lending protocols.

As a bridge and DEX aggregator, LI.FI can route any asset on any chain to the desired asset on the desired chain, thus providing a remarkable UX to their users.

All of this will be made available on an API/Contract level which comes as SDK, iFrame solution (deprecated), and as a widget for other developers to plug directly into their products. No need for users to leave your dApps anymore.

Wallets

• , , , , , , , and are using us either as a DEX-aggregator-aggregator to get the best price for on-chain swaps and/or for cross-chain any-to-any swaps.

Web3 Exploration

• , , , and leverage our platform to facilitate easy bridging within their DeFi infrastructure.

DeFi Protocols

• , , and have integrated with us to simplify user onboarding, allowing users to bridge directly on their respective pages for a smoother experience.

Onramps

• , , and employ our technology to effortlessly on-ramp into and from any long-tail asset on any chain.

DEX Interfaces

• and enable swapping and bridging on their interface, assisting in better user retention.

Payment Solutions

• , , , and are payment solutions that are leveraging our platform to enable cross-chain payments effectively.

1. Is LI.FI Open Source?

Our 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.

2. How decentralized is ?

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.

3. How do we decide which bridge to implement next?

We move forward in a three-step way:

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

2. 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.

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

4. How do we decide which bridge to use?

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.

5. Can our backend algorithm / API be influenced?

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.

6. Do bridges cooperate with you?

Yes, over 50% of all bridge developers have invested in us. We're very close to them as we bring them more volume.

1. Liquidity is fragmenting, and your users might come from everywhere.

2. Two options

   1. You could either tell your users to use a bridge that sends them away, creates friction, reduces your conversion rates, and is a communication overhead.

   2. You implement one or more bridges by yourself.

3. Option b) is the better one, but it comes with a lot of drawbacks.

   1. One bridge is not enough, either because there is no bridge supporting all chains or because the bridge might get hacked or doesn't have sufficient liquidity, in which cases you need to have a fallback solution.

   2. Bridges are still immature and will often change, which creates unnecessary dependency and maintenance overhead.

   3. Implementing a bridge is not enough; you also need them to connect to DEX aggregators and DEXs to have a real benefit. Bridges are just focusing on stablecoins and native currencies.

4. As soon as you have implemented multiple bridges, you also need a lot of business logic to decide when to use which bridge.

5. We work with almost 20 people on doing nothing else than that: bridge aggregation

Because we're the most focused company in the space. We do just one thing, B2B, and do that really well. On top, we have an experienced team with a lot of experience building SDKs and integrations. We know how to build a sustainable and smooth company structure and developer environment around that.

9. How do you think about the multi-chain future?

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

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

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

3. provided by large companies or nation-states

4. 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.

10. Will you also support other Non-EVM L1s like Solana/Terra/Polkadot?

Yes, we will and we're already in the process of implementing the required bridges and contracts.

11. Whom do you use for auditing?

We are in contact with multiple audit firms and will be doing multiple audits of our smart contract one after another. Latest Audits:

• October 2022 - Spearbit

• April 2022 - Quantstamp

• March 2022 - Code4rena

12. Is there a kill switch if a bridge gets hacked?

Yes, we have two kill switches: 1. on API level, where our route calculation starts ignoring the bridge, and 2. on smart contract level - whereby we also provide the option to ignore kill switch checks for the protocol that has integrated us very deeply.

LI = Linked | FI = Finance LI.FI => Linked Finance

At LI.FI, we strive to simplify the complexities of any-to-any cross-chain transfers. To describe these transfers and bridge funds from chain to chain, we've introduced some LI.FI-specific terminology.

Route

A "Route" object represents an entire transfer, whether it occurs within one single chain, such as a token swap, or across chains. It summarizes transfer details, featuring properties prefixed with from for source information, including the originating chain, transferred funds, and sender address. Conversely, to-prefixed properties denote destination specifics, such as the target chain, received funds, and recipient address. These attributes collectively define transfer parameters, facilitating seamless execution within applications or platforms. Each Route object includes one or more Step Objects that represent the individual transactions of that Route.

interface Route {
  id: string
  insurance: Insurance
  fromChainId: number
  fromAmountUSD: string
  fromAmount: string
  fromToken: Token
  fromAddress?: string

  toChainId: number
  toAmountUSD: string
  toAmount: string
  toAmountMin: string
  toToken: Token
  toAddress?: string

  gasCostUSD?: string // Aggregation of underlying gas costs in usd

  containsSwitchChain?: boolean // Features required for route execution

  steps: Step[]

  tags?: Order[]
}

Step

Step Objects represent the individual transactions a wallet must sign to execute the entire transfer. These actions move funds by interacting with contracts. It's crucial that Steps are signed and executed in the exact order listed since subsequent steps rely on the output funds of preceding ones.

Note that for every Step the user has to sign either one or two transactions: the main transaction described in the step and possibly one preceding approval transaction.

Example: Why do we need multiple Steps?

Consider a transfer bridging USDC on Arbitrum to some obscure token on Base. While there's no direct bridge between these assets, multiple transactions chained together can achieve the desired outcome. A Route for this transfer might, for example, involve two Steps. The first Step swaps USDC on Arbitrum to USDC on Base using a cross-chain bridge, returning the swapped tokens to the executing wallet. Upon receiving the funds, the first Step can be marked as completed. The second Step involves a same-chain token swap from USDC to the obscure token, with the resulting funds again returned to the wallet. If the destination wallet differs from the source, the last Step directs the funds accordingly.

Anatomy of a Step

interface Step {
  id: string
  type: StepType
  tool: StepTool
  toolDetails: StepToolDetails
  integrator?: string
  referrer?: string
  action: Action
  estimate?: Estimate
  transactionRequest?: TransactionRequest
}

Please note that the interface depicted above is a simplified version of the Step object. We have broken down all possible variants and condensed them into one for easier understanding.

Each step is identified by a unique id and characterized by its type, indicating the nature of the step (e.g., swap, cross-chain transfer). The tool and toolDetails properties specifies the tool / protocol used to fulfill the action described. Furthermore, in order to accurately describe its transaction each step is broken down into two more objects: action and estimate.

Action

interface Action {
  fromChainId: number
  fromAmount: string
  fromToken: Token
  fromAddress?: string

  toChainId: number
  toToken: Token
  toAddress?: string

  slippage: number
}

Describes the action taken in the Step. In this object you can find information about the from and to token, source and destination chain, the tool that will be used as well as the amount that will be sent to that tool to be bridged or swapped.

Estimate

interface Estimate {
  tool: string
  fromAmount: string
  fromAmountUSD?: string
  toAmount: string
  toAmountMin: string
  toAmountUSD?: string
  approvalAddress: string
  feeCosts?: FeeCost[]
  gasCosts?: GasCost[]
  executionDuration: number
}

This object contains all estimated values for that step. Here you can find estimated gas prices and fees a user has to pay in order to fulfill the transaction. This object also contains the estimated return value in the currency a user will receive when successfully executing the transaction. Please note that the values in this object are only estimates, they may be less accurate for extremely volatile markets.

Execution

This object is not included in Steps when they are returned from the server. These object are appended to each Step when executed via the LI.FI SDK. It contains all information necessary to track a Steps execution progress like monitoring the state of approval transactions and of the main transaction. It plays a crucial part in the SDKs ability order to resume a step if an error occurs.

The LiFiStep variant

This is a special variant of the Step object. In order to minimize the amount of transactions a user has to sign and to improve the UX, LI.FI has deployed Smart Contracts that can condense multiple steps into one by directly executing transactions on the blockchain. The steps can be recognized via the step type which is set to type: lifi. These Steps have the additional includedSteps property. This property contains a list of Steps that are executed via the LI.FI Smart Contracts.

Quotes

"Quotes" are essentially standalone Steps with additional transaction data that can directly be executed by a wallet. They come without an encompassing Route object as they contain all necessary information to execute and display the transfer within one single step.

Explore Integration Opportunities

Fill out our integration form at partner.li.fi to discover how you can partner with us and integrate LI.FI into your platform.

Official Business Partnership Contacts

For any business partnership discussions, please ensure you are only communicating with the following team members from LI.FI:

Andrei - Head of DeFi Sales

• Telegram: @Cerberus0x

• Email: andrei@li.finance

• Twitter: @0xCerberus

Sarthak - Head of Integrations

• Telegram: @Sarthak_LIFI

• Email: sarthak@li.finance