You can find the ABI of LifiDiamond in our auto generated lifi-contract-types repository.
- General
- Why LI.FI?
- How It Works
- Architecture
- Repository Structure
- Getting Started
- Contract Docs
- DEPLOY
- More Information
Our vision is to create a middle layer between DeFi infrastructure and the application layer. LI.FI aims to aggregate and abstract away the most important bridges and connect them to DEXs and DEX aggregators on each chain to facilitate cross-chain any-2-any swaps.
To decide which bridge to use, we assess and measure the degree of decentralization, trust assumptions, fees, gas efficiency, speed, and other qualitative and quantitative factors. Then, we use the thresholds and preferences of our integration partners and end-users to select the right path.
- The future is multi-chain
- Cross-chain bridging solutions will play a major role on infrastructure level
- Aggregation will pave the way for mass adoption
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 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 CEXes, but they don't have a way to allow easy swap between assets like CEXes.
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.
Too many bridges to educate yourself about. It'd be good to have access to all of them and getting 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 DEXes/DEX aggregators as bridges are limited to stable-coins 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, DEXes, 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, and as a widget for other developers to plug directly into their products. No need for users to leave your dApps anymore.
Our API and SDK allow dApps and dApp developers to request the best routes for a desired cross-chain swap. Our backend will calculate the best possible routes based on the transaction fees, gas costs and execution duration.
The then returned routes contain already populated transactions which can directly be sent via the user's wallet to our contracts. A single transaction can contain multiple steps (e.g. AAVE on Polygon -> DAI on Polygon using Paraswap -> DAI on Avalanche using Stargate -> SPELL on Avalanche using Paraswap) which will be executed by our contract. Finally, the final amount of the requested token is sent to the user's wallet.
The LI.FI Contract is built using the EIP-2535 (Multi-facet Proxy) standard. The contract logic lives behind a single contract that in turn uses DELEGATECALL to call facet contracts that contain the business logic.
All business logic is built using facet contracts which live in src/Facets.
For more information on EIP-2535 you can view the entire EIP here.
A basic example would be a user bridging from one chain to another using Hop Protocol. The user would interact with the LI.FIDiamond contract which would pass the Hop specific call to the HopFacet which then passes required calls + parameters to Hop Protocol's contracts.
The basic flow is illustrated below.
graph TD;
D{LiFiDiamond}-- DELEGATECALL -->HopFacet;
D{LiFiDiamond}-- DELEGATECALL -->AnyswapFacet;
D{LiFiDiamond}-- DELEGATECALL -->CBridgeFacet;
D{LiFiDiamond}-- DELEGATECALL -->HyphenFacet;
D{LiFiDiamond}-- DELEGATECALL -->StargateFacet;
The LiFiDiamond contract is deployed along with some helper contracts that facilitate things like upgrading facet contracts, look-ups for methods on facet contracts, ownership checking and withdrawals of funds. For specific details please check out EIP-2535.
graph TD;
D{LiFiDiamond}-- DELEGATECALL -->DiamondCutFacet;
D{LiFiDiamond}-- DELEGATECALL -->DiamondLoupeFacet;
D{LiFiDiamond}-- DELEGATECALL -->OwnershipFacet;
D{LiFiDiamond}-- DELEGATECALL -->WithdrawFacet;
contracts
│ README.md // you are here
│ ... // setup and development configuration files
│
├─── config // service configuration files
├─── constants // general constants
├─── deploy // deployment scripts
├─── diamondABI // Diamond ABI definition
├─── export // deployed results
├─── scripts // scripts containing sample calls for demonstration
│
├─── src // the contract code
│ ├── Facets // service facets
│ ├── Interfaces // interface definitions
│ └── Libraries // library definitions
│
├───tasks
│ │ generateDiamondABI.ts // script to generate Diamond ABI including all facets
│
├─── test // contract unit tests
│ ├─── facets // facet tests
│ ├─── fixtures // service fixtures for running the tests
│ └─── utils // testing utility functions
│
└─── utils // utility scripts
You can read more details documentation on each facet here. Sample requests to fetch transactions for each facet can be found at the end of each section.
Make sure to copy .env.example to .env and fill out the missing values. Tests might fail with missing environment variables if some of the variables are blank.
yarnyarn testMake sure to install the latest version of Foundry by downloading the installer.
curl -L https://foundry.paradigm.xyz | bash
Then, in a new terminal session or after reloading your PATH, run it to get the latest forge and cast binaries:
foundryup
Install dependencies
forge install
Run tests
yarn test
We try to keep up with all the latest bridges and DEXes but can't always add them as fast as we would like. If you would like to speed up the process of adding your bridge, we've made it easy for you to contribute yourself.
Follow the deployment checklist here