This plugin allows for the decoding of Arbitrum transactions by way of action spec.
- Ethereum must be either sourceChain, or destinationChain, otherwise the quest will not be passable. It is not possible to bridge between Arbitrum Nova and Arbitrum One.
- Only tokens which are compatible with all three chains were added. USDT was considered, but there is issues with bridging USDT to Arbitrum Nova
- If tokenAddress is set to any, then amount will also be set to any, regardless of what is input.
Arbitrum's native token bridge is a general messaging bridge allowing for transfer of ETH, and any token.
They support exchange to/from mainnet to their two main networks (One, and Nova).
Arbitrum uses different paths for ETH vs Tokens, and relies on precompiles when routing the base network currency (AEth) from L2 to L1.
For a given bridge action we generally have 4 types of transactions we want to ensure we're parsing:
- ETH from L1 to L2
- Tokens from L1 to L2
- ETH from L2 to L1
- Tokens from L2 to L1
In some cases there won't be a difference between L1/L2 leading to two types of transactions to parse, but in general this enumerates the upper bound of transactions a bridge action should be responsible for parsing. It's also possible for different tokens to route differently, this would be the case with Arbitrum if they didn't pipe transactions through their router first.
Token Transfers from L1 get routed through the L1 Gateway Router
This is an example of an Outbound Transfer from the L1 Gateway Router
This is the function call on the L1GatewayRouter.sol contract.
Token transfers from L2 get routed through the L2 Gateway Router
This is an example of an outbound transaction from the L2
ETH transfer from L1 get routed through the Delayed Inbox using the Deposit ETH function
ETH transfers from the L2 use the ArbSys contract using the Withdraw ETH function
This is an example of an ETH withdrawl through the ArbSys contract