Checking the parameters of a given transaction
Example SEND transaction on SRC chain:
Copy the data that was sent with the transaction by selecting “Original View” on the “Input Data” section in the block explorer:
Head over to https://openchain.xyz/tools/abi and paste the copied data into the form. This will give you a ton of insights
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:
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:
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 filein 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
collectNativeInsuranceFees(..)then the insurance feature was used, otherwise the Get Gas feature was used (function names are
How to check what destination call was executed
Example TX (via Stargate): https://etherscan.io/tx/0x61854f529273aa6a7469d85e6d280ec81dc0aef6bed45555ea05de8e46fa0089
get the parameters for this tx as described in Checking the parameters of a given transaction
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).
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.