1

We typically know thay msg.sender stands for the address who invoked the current method of a contract.

Let's say that I have address A (which is a Smart Contract abstract account) and I want to send ERC-20 tokens (defined as the interaction with the ERC-20 contract with address B) to another account C.

Now, the Bundler is the one who will sign an actual transaction and send it, so the transaction origin now will be the Bundler (which is actually another EOA acting as proxy and effectively paying for the ETH gas, even if in the end via business logic I paid the gas in some way). So the tx.origin will be the bundler and, if the call is direct, also msg.sender is the bundler, and not A.

Am I right? Or how is this done? Should the target ERC-20 contract support something else (like a particular definition of the _msgSender() internal method that some implementations offer)?

1 Answer 1

3

Bundler doesn't call the ERC20 contract, it calls the handleOps function in the entrypoint which again calls the execute function in the smart wallet. And the wallet then executes the function. So the wallet becomes the msg.sender for the ERC20 contract.

Have a look at this transaction on tenderly explorer - https://dashboard.tenderly.co/tx/goerli/0x078c79b2370524113ddda9a576059e4dca123e7047fc79c5227345bf09f62fed

This is the place where simpleAccount becomes the msg.sender by caling executeBatch

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.