Overview
Architecture
The main LI.FI smart contract is built using the EIP-2535 ( Diamonds, Multi-Facet Proxy) standard. Users interact exclusively with this contract, which is called LiFiDiamond. The LiFiDiamond uses so-called "facet" contracts that it calls via DELEGATECALL to execute their logic in its own state (contrary to an external call which would execute the logic in state of the external contract being called). This means that all LI.FI transactions go through and are executed by the LiFiDiamond.
The LiFiDiamond furthermore uses so-called "periphery" contracts for specific purposes such as executing external calls in a safe environment (e.g. Executor), keeping treasury of funds (e.g. FeeCollector), receiving tokens on destination chain and executing destination calldata (e.g. ReceiverStargateV2) or for pre-bridging tasks (e.g. TokenWrapper).
All LI.FI smart contracts are public and can be found in the contracts repo:
Also please see the contract-specific docs section in the repo for more insights into how some of our contracts work in detail.
Transaction and Funds Flow
While the implementations for specific protocols vary greatly, the transaction and funds flow usually follows a coherent pattern:
A caller (EOA or contract) sends a transaction that directly or indirectly calls the LiFiDiamond
The LiFiDiamond will transfer the to-be-bridged/-swapped tokens from the caller (=msg.sender) to itself, making those funds available for any subsequent action. For this it is necessary that an allowance has been set by the caller prior to calling the LiFiDiamond (exception: gasless transactions).
If applicable, the LiFiDiamond will execute any pre-bridging steps such as swapping tokens, wrapping/unwrapping native tokens, collecting fees or sending a small gas amount to the destination chain
Then some parameter validation and protocol-specific logic is executed and, once all this clears, the funds are forwarded to the selected bridge
An event is emitted by the LiFiDiamond to conclude the transaction and emit the key parameters of the transfer
Events
Any successful bridge transaction will emit our LiFiTransferStarted event which contains information about what is bridged where by whom.
In case of same-chain swaps, a LiFiGenericSwapCompleted event is emitted.
For successfully executed destination calls , our protocol-specific receiver contract will emit either of the following two events:
LiFiTransferCompleted (=destination call success)
LiFiTransferRecovered (=destination call unsuccessful but bridged funds were forwarded to receiver address) event.
Last updated
Was this helpful?