Platform: Code4rena
Start Date: 24/03/2022
End Date: 30/03/2022
Period: 7 days
Status: Completed
Pot Size: $75,000 USDC
Participants: 59
Reporter: liveactionllama
Judge: gzeon
Id: 103
League: ETH
0xDjango | 1/59 | $7,983.73 | 6 | 2 | 0 | 2 | 0 | - | - | 0 |
GeekyLumberjack | 2/59 | $6,849.87 | 2 | 1 | 0 | 1 | 0 | 0 | 0 | 0 |
pmerkleplant | 3/59 | $6,234.50 | 4 | 1 | 0 | 3 | 0 | 0 | 0 | 0 |
rayn | 4/59 | $5,952.43 | 9 | 1 | 0 | 6 | 0 | - | - | 0 |
kirk-baird | 5/59 | $5,507.65 | 8 | 1 | 0 | 6 | 0 | - | 0 | 0 |
hake | 6/59 | $4,591.30 | 6 | 1 | 0 | 3 | 0 | - | - | 0 |
hyh | 7/59 | $3,496.42 | 8 | 0 | 0 | 7 | 0 | - | 0 | 0 |
hickuphh3 | 8/59 | $3,115.31 | 8 | 0 | 0 | 6 | 0 | - | - | 0 |
CertoraInc | 9/59 | $2,593.92 | 3 | 0 | 0 | 1 | 0 | - | - | 0 |
shenwilly | 10/59 | $2,530.80 | 3 | 1 | 0 | 1 | 0 | - | 0 | 0 |
Auditor per page
All solidity files in the src folder except src/Interfaces/* and src/Libraries/LibBytes.sol.
| File | Docs | SLOC | External contracts called | Libraries used |
|---|---|---|---|---|
| LiFiDiamond.sol | 39 | 0 | 1 | |
| Facets - Logic | ||||
| Swapper.sol | (docs) | 15 | 0 | 2 |
| AnyswapFacet.sol | (docs) | 97 | 2 | 4 |
| CBridgeFacet.sol | (docs) | 117 | 1 | 3 |
| HopFacet.sol | (docs) | 129 | 1 | 3 |
| NXTPFacet.sol | (docs) | 122 | 1 | 3 |
| GenericSwapFacet.sol | (docs) | 23 | 0 | 1 |
| Facets - Management | ||||
| OwnershipFacet.sol | 12 | 0 | 1 | |
| DiamondCutFacet.sol | 13 | 0 | 1 | |
| DiamondLoupeFacet.sol | 37 | 0 | 1 | |
| WithdrawFacet.sol | 28 | 1 | 1 | |
| DexManagerFacet.sol | 59 | 0 | 2 | |
| Libraries | ||||
| LibAsset.sol | (docs) | 67 | 1 | 0 |
| LibBytes.sol (Not part of audit) | (docs) | 291 | 0 | 0 |
| LibDiamond.sol | (docs) | 171 | 0 | 0 |
| LibStorage.sol | (docs) | 5 | 0 | 0 |
| LibSwap.sol | (docs) | 50 | 1 | 2 |
| LibUtil.sol | (docs) | 10 | 0 | 1 |
The following risks should be given special consideration during the audit:
We are planning to to improve the LibSwap libraries to not only check the exchange calls using a contract address whitelist, but also use a function signature whitelist to ensure that only known functions are called in those contracts.
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.
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 NXTP -> 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 -->NXTPFacet; D{LiFiDiamond}-- DELEGATECALL -->HopFacet; D{LiFiDiamond}-- DELEGATECALL -->AnyswapFacet; D{LiFiDiamond}-- DELEGATECALL -->CBridgeFacet;
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 │ ├─── 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.
yarn
yarn test