LI.FI Documentation
LI.FI WebsiteAPI ReferenceHelp / FAQ / Create support ticketRequest API Key
  • 🏡Getting Started
    • ❓What is LI.FI
    • 🌟Why LI.FI?
    • 🆚LI.FI vs Aggregators/DEXs/Bridges
    • 📖LI.FI Terminology
    • ❓FAQ
    • 💡Use Cases
      • Mobile/Gaming Wallets
    • 🏹LI.FI vs. Other Aggregators
    • 🤝Partnership
    • 🌐Powered by LI.FI
  • 🔐Security First
  • ✅List: Chains, Bridges, DEX Aggregators, Solvers
  • 💲Monetization / Take Fees
  • 🔎Transaction Explorer
  • 🔏Rate Limits & API Key
  • How to get integrated by LI.FI?
    • For Bridges
    • For DEXs/Aggregators/Solvers
  • 🆘Technical FAQ
  • LI.FI PRODUCTS
    • Glacis
    • LI.FI Solver
    • LI.FI Intents System
  • LI.FI API
    • ⚙️LI.FI API
      • Transferring Tokens (Example)
      • Requesting supported Chains
      • Requesting all supported Tools
      • Requesting all known Tokens
      • Getting Token Information
      • Getting all possible Connections
      • Requesting a Quote
        • Token Transfer
        • Optimizing quote response timing
        • Cross-Chain Contract Calls
        • Possible Tool Errors
        • Testing your integration
      • Status of a Transaction
      • Requesting Analytics Data
    • ⚔️TX-Batching aka "Zaps"
    • 🏄Solana
      • Request examples
    • 🪙Bitcoin
      • Request examples
    • ⛽LI.Fuel
  • Integrate LI.FI SDK
    • 🚀LI.FI SDK Overview
    • 📦Install LI.FI SDK
    • ⚙️Configure SDK
    • 🪐Configure SDK Providers
    • 📜Request Routes/Quotes
    • 🎯Execute Routes/Quotes
    • ⛓️Chains and Tools
    • 💰Token Management
    • 🕵️Testing Integration
    • 🚗Migrate from v2 to v3
  • INTEGRATE LI.FI WIDGET
    • 🧩LI.FI Widget Overview
    • 📦Install Widget
    • 🎮Select Widget Variants
    • ⚙️Configure Widget
    • 🎨Customize Widget
    • ⚡Widget Events
    • 👛Wallet Management
    • 🌍Internationalization
    • ⚛️Compatibility with Next.js, Remix, Nuxt, etc.
    • 🛣️React Router Compatibility
    • 📖Widget API Reference
    • 🚗Migrate from v2 to v3
  • Smart Contracts
    • Overview
    • Deployments/Contract Addresses
    • Audits
  • Support & Misc.
    • API Status
    • Technical Help Desk & FAQ
    • Create a Partner Ticket
    • Discord Support
    • Telegram Support
    • Twitter
    • Github
    • Licenses
Powered by GitBook
LogoLogo

Connect with us

  • Github
  • Twitter
  • Discord
  • LinkedIn

More Information

  • Help Desk / FAQ
  • API Reference
  • Website
On this page
  • 1. Is LI.FI Open Source?
  • 2. How decentralized is LI.FI?
  • 3. How do we decide which bridge to implement next?
  • 4. How do we decide which bridge to use?
  • 5. Can our backend algorithm / API be influenced?
  • 6. Do bridges cooperate with you?
  • 7. Why LI.FI?
  • 8. Why is LI.FI better than their competition?
  • 9. How do you think about the multi-chain future?
  • 10. Will you also support other Non-EVM L1s like Solana/Terra/Polkadot?
  • 11. Whom do you use for auditing?
  • 12. Is there a kill switch if a bridge gets hacked?
  • 13. What does LI.FI stand for?

Was this helpful?

Export as PDF
  1. Getting Started

FAQ

Last updated 8 months ago

Was this helpful?

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

Find the reports here: Audits

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

7. Why ?

8. Why is better than their competition?

13. What does stand for?

🏡
❓
LI.FI
LI.FI
LI.FI
LI.FI