First of all, you need to decide whether you want to support only routes that can be done in a single send transaction, or also routes that require the user to sign a second send transaction on the dest chain. The first is clearly easier to implement and simpler for the user. The second solution is needed to support all types of assets. If you focus mainly on native and stable coins, the complex flow is not needed.
- Noticed you have the whole LiFi.executeRoute thing. We are likely going to want to sign these steps one by one. Is this going to cause any troubles for us? Is there any nuance to the way these transactions are executed?
> Executing a route, especially if it consists of two steps, requires some work. We have bundled that work into this function. The function is intended to be used when you have access to a wallet in a node environment or a signer in the browser. The flow it performs is:
* check if the user has the required funds
* check if the user needs to set approval for the tokens to sent
* set that approval if needed
* request the transaction to trigger the user's (swap+)bridge action (using /advanced/stepTransaction endpoint)
* send the transaction
* wait for the chain to confirm the transaction
* wait for the bridge to transfer the tokens (using /status endpoint)
* checks if the route contains a second step(swap) that the user needs to execute on the destination chain
* if that's the case: update the step with the actual received amount from the bridge, check/set approval, request transaction, send transaction, wait for execution
You can for sure code all of that yourself as well and maybe you already have handling for approvals/balances. It is a normal execution of transactions, with the only difference that with bridging the funds are received delayed and not immediatelly after the sending transaction is minded.
- Our plan is to generate these quotes on our backend in a node environment. Any objections here?
> That is no problem, you can wrap our API in your backend and forward the information to your UI. You can use the SDK to communicate with our API and receive typed data or access the API directly and use our types package if you need the typescript types.
- Trying to test some bridge transactions and nothing goes through due to maxFeePerGas being too low. Generally a bit concerned about failures being common. What is a typical failure rate on a MATIC —> ETH route?
> There are different kinds of errors and ways to prevent them:
* the transaction is not accepted by the the chain due to the maxFeePerGas error: This can happen if the gas price the user defined is too low compared to the gas price on chain. We use multiple APIs to suggest a good gas price, but as the prices constantly change it can be too low a few seconds later. For chains that support it we will implement EIP1559 to be able to provide a price range instead of a fixed price. On your end you may have your own ways to set a gas price or allow the user to change it, feel free to replace the price if you think it is too low or the user needs some time to use the most current price. We also provide an API for gas prices: https://apidocs.li.fi/reference/get_gas-prices-chainid
* the transaction is sent to chain but fails there with a slippage error: The market changed more than the user configured slippage, to prevent him from losing money the transaction reverts. This is an expected case, if it happens a lot the slippage is probably set too low. We default to 0.3%
* the transaction fails on chain due to other reasons: That should not happen, we monitor this closly and catch those kind of problems in our testing stages already.
- What’s the difference between step types? (SwapStep | CrossStep | LifiStep | CustomStep)
> You will always receive a list of LifiSteps. The other step types are used only in the includedSteps property of a LifiStep. Which means one LifiStep can combine multipe of the other step, e.g. a swap and bridge action in one transaction. The different step types are used to get some context of what they do, you would mainly interact with them to display a overview to the user.
* CrossStep: bridges funds to another chain
* SwapStep: same chain exchange of tokens
* ProtocolStep: additional action, e.g. buying insurance, collecting a fee
* CustomStep: you can provide custom steps to e.g. by a NFT or stake funds at the end of your transaction
- What’s the maximum number of transactions in a LiFi execution? Would it be as follows? Do we need to sign these individually?
2x approvals (source and dest chain)
2x swaps (source and dest chain)
1x send
1x receive (not needed to be signed)
> The following transactions can happen
1. approval on source chain (triggered by the user if ERC20)
2. send LifiStep (can contain swap and bridge calls)
0. bridge sends funds to the user (no user interaction needed, bridge pays gas)
Only if the route contains a manual swap on the destination chain
3. approval on dest chain (triggered by the user if ERC20)
4. send LifiStep (swap on dest chain)
In most cases the user triggers 1 or 2 transactions, if you want to support the complex flows 3-4 transactions are possible, never more.
- What about if we only want to bridge from ETH to WETH on Solana / Polygon? Would these be single transactions?
> Yes, if you start with a native asset the approval on the source chain is not needed. And as there are direct routes to receive WETH from bridges no swap on the destination chain is needed.
- Since you only accept to / from token addresses for RouteRequest, how can we specify native tokens via your SDK?
> both native and ERC20 tokens are "token" for us. We use "0x0000000000000000000000000000000000000000" as the address of the native asset on EVM chains. For Solana the addresses will be a bit different as they are longer. We will let you know how to specify them once we have the APIs ready for Solana.