I would like to open the discussion about a proposal for a new opcode named IMPERSONATECALL that calls other contracts and replaces the msg.sender at the same time. It saves gas and simplifies several use cases regarding muti-user wallets, sponsored wallets, meta-transactions, cheap batch operations (similar to rollups), and more.
The idea is that a contract can impersonate child contracts (created with a derivation similar, but not equal, to CREATE2). Therefore there is no practical risk that the caller impersonates a third party contract.

This opcode enables the creation of multi-user wallets, where each user is given a separate non-custodial smart-wallet having its own address for storing ethers and tokens, yet no contract code is deployed, and a main-wallet contract retains the common functionality (i.e. social private key recovery). Wallets are accessed by a meta-transaction system (i.e using EIP-712) embedded in the multi-user wallet contract.
Even if the same functionality can be achieved by using counterfactual contract creation, this solution is attractive because:

  • It’s much simpler to design and less error prone.
  • It provides the sponsor huge gas savings, removing the need for the deployment of thousands of wallets.

I’m sure there are plenty more use cases that can benefit from this opcode.
You can read the proposal here:

1 Like

Does anyone have any opinion on this super useful feature?

What is the definition of a child contract for the purposed of your EIP?

A contract whose address is derived from the parent’s contract address only for the purpose of IMPERSONATECALL.

In other words, the child contract address cannot be derived by CREATE2/CREATE from that parent’s contract, or from any other account without breaking the keccak hash function.

I think omitting the word of zeros in the address pre-image is best, since it can’t collide with CREATE or CREATE2.

Otherwise, I like this EIP.