Analysis of our smart contract transactions

On this page we will show how to gain insights about smart contract transactions that have passed through our LI.FI diamond contract

Checking the parameters of a given transaction

Example SEND transaction on SRC chain:

https://arbiscan.io/tx/0xf6144532bd727469ef70c68009682090151534e05904f479a0244586fb3be016

1. Copy the data that was sent with the transaction by selecting “Original View” on the “Input Data” section in the block explorer:

   

   

2. Head over to https://openchain.xyz/tools/abi and paste the copied data into the form. This will give you a ton of insights

   

BridgeData (mandatory):

every single transaction that will go through our diamond must contain this bridgeData. It consists of a fixed set of parameters. The parameters of the bridgeData are defined here and look as follows:

SwapData (optional):

Only transactions that contain swaps on the source network (i.e. a swap that will be executed before the funds are bridged) will contain this information. Such transactions can be identified either by the name of the function they are calling “swapAndStartBridgingVia…” (otherwise its just “startBridgingVia…”) and also they must have the value “true” for “hasSourceSwaps” in the bridgeData (as you can see in the example above). For each swap, there will be one set of swapData. Also, if we collect a fee, this will also be considered a swap and require one set of swap data. So let’s say we swap from native ETH to USDT, then collect a fee in USDT and then bridge the USDT over to network XY, we will have two sets of swapData. One for native ETH to USDT and one for fee collection of USDT.

A good way to understand the swapData would be to check the “callTo” address (in the block explorer) and see what kind of contract is called, .e.g. could be a UniswapRouter (⇒swap) or could be the address of our ServiceFeeCollector (⇒ fee collection).

The parameters of the swapData are defined here and look as follows:

FacetData (optional):

Some of the bridges require specific parameters such as fee amounts, bridge-specific chainIds, timeouts or parameters related to message passing/execution which we need to pass to the bridge contract in order to bridge funds. Not every bridge has such parameters, so this part is optional. If the bridge is Stargate, this data set is called “StargateData”. If the bridge is Multichain, it’s called MultichainData, etc.

In order to find out more about the parameters, head over to the “Facets” folder in our contracts repo and check the bridge-specific contract for further insights. E.g. here is the StargateData that can be found in the StargateFacet.sol:

How to check if “Get Gas” or “Insurance” feature was used in a tx

Example tx with insurance: LINK

If any of these two features is used in a transaction, for each feature used there will be one set of swapData that:

• has the address of our ServiceFeeCollector as “callTo” parameter. To find out if the callTo address is a ServiceFeeCollector you can either

find the address of the ServiceFeeCollector in a specific network by getting the address from the <NETWORK>.json file in this folder or check the address in the block explorer of the respective network and see if in the “code” tab the name of the contract is “ServiceFeeCollector”

• Then you need to analyze the “callData” parameter of this swapData set by copying it and pasting it in this tool ( https://openchain.xyz/tools/abi)

  

• You will then see which function of the ServiceFeeCollector was called. If the function called was either collectTokenInsuranceFees(..) or collectNativeInsuranceFees(..) then the insurance feature was used, otherwise the Get Gas feature was used (function names are collectTokenGasFees(..) or collectNativeGasFees(..))

  

How to check what destination call was executed

Example TX (via Stargate): https://etherscan.io/tx/0x61854f529273aa6a7469d85e6d280ec81dc0aef6bed45555ea05de8e46fa0089

1. get the parameters for this tx as described in Checking the parameters of a given transaction

2. in the StargateData there is a parameter named “callData” that contains the data which will be executed on the destination chain (same parameter can be found in AmarokData).

   

3. Copy the value of this parameter (0xf7472fa28….), paste it in this tool ( https://openchain.xyz/tools/abi) and uncheck the box “assume first 4 bytes are function selector” to gain some insights about the parameters that are contained in this calldata. Since further analysis depends on the bridge used, we cannot detail this further. Contact the smart contract team for further support.