❓
FAQ
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.
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:
- 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.
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.
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.
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.
Yes, we will and we're already in the process of implementing the required bridges and contracts.
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
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
Last modified 5mo ago