Call context — how does a shadow wallet that performs the final call to a Smart Contract retain the msg.sender so that it emulates live transactions as close as possible.
Approach #1: Fit Standards like ERC20
Using a Forward/Shadow Address for each User — ie. User creates a unique Forwarder for all transactions.
- LP deposits will yield NFTs that are assigned to this Forwarder.
- The owner of the Forwarder Address is then the original wallet.
- If we can detect the type of transaction, we could automatically transfer received assets onto the original owner.
Issue: Where Smart Contract interactions do not fit a standard, and/or a standard cannot be detected, arbitrary msg.sender related mappings or other state variables will reference the Forwarder Address.
Approach #2: Proxies
This would still result in the Backend Service submitting the transaction.
Approach #3: User Wallet Submits Transaction
- Transaction is submitted
- Transaction is intercepted and paused
- Transaction gas is estimated
- https://docs.tenderly.co/simulations-and-forks/simulation-api/using-simulation-api
- Backend service checks if Gas Currency funds exist
- Backend service accepts USDC (Gas Currency) → ETH swap meta-transaction — using 0x Protocol
- Executes it in order to fund the wallet with enough ETH to execute the original transaction.
- ETH is transferred to the user
- Original Transaction is executed
Taking the gas currency as collateral works.
Approach #4: User Wallet Submits Transaction /w Cross-chain
- Backend service accepts USDC (Gas Currency) transfer meta-transaction
- Transfer is made to contract that swaps to ETH
- After swap, transfer to ETH to destination wallet using Axelar
- Original transaction is executed