We have been working on a non-custodial relayer (e.g. proxy bidder) called any.sender. Bob can send any.sender a transaction via the API and any.sender gradually bumps the fee until it gets in. Its a pretty useful service as products can focus on actually building their product and not boring/very tedious transaction infrastructure.
We came across the msg.sender problem while we were building any.sender. To quickly summarise, if your contract relies on msg.sender to authenticate the caller and Bob has registered his EOA with the contract, then it is impossible for Alice to send a transaction on behalf of Bob. This is because an Ethereum Transaction intertwines who is paying the gas (Alice) and who wants to execute a smart contract (Bob).
There are several smart contract solutions to mitigate the problem including msgSender() and the adoption of wallet contracts. However, both solutions do not come for free and I’ve listed several problems in the write-up. So please check there for more information.
I believe we should solve this problem at the platform / EVM-level, so non-custodial third party relay infrastructure can become a native citizen of Ethereum (alongside various other use-cases).
I have a detailed write up here on a potential solution to help kick-start the discussion:
Given my quirky academic background it is a bit long, but in essence it proposes a new opcode/precompile:
targetContract.callWithSigner(callData, value, replayProtection, signature, signer)
It is similar in style to CALL, DELEGATECALL, etc. The precompile verifies:
- The user has signed the target contract + function call
- The user’s replay protection is valid (e.g. unique transaction)
If successful, it swaps msg.sender == the signer’s address and executes the target contract with the desired data.
There are several other ways to solve the problem, most notably to modify the Ethereum Transaction format. I believe a new precompile/opcode is probably the best approach as it is the least intrusive e.g. it doesn’t change any existing infrastructure / client tooling.
It would be great if others are happy to read the proposal and help me kick-start a discussion here. While I think it is a nifty way to solve the problem, there may be superior ways to do it (e.g. full-fledged account abstraction) - so let’s start working it out together.
By the way - this impacts anyone working on meta-transaction infrastructure that includes:
- gas station network
- Gnosis safe
- Pillar wallet
-… so on