SIP-340: Add Trusted Multicall Forwarder
Author | |
---|---|
Status | Implemented |
Type | Governance |
Network | Ethereum & Optimism |
Implementor | TBD |
Release | TBD |
Proposal | Loading status... |
Created | 2023-09-16 |
Simple Summary
This SIP proposes the addition of an ERC-2771 compliant trusted forwarder including Multicall3 functionality with error bubbling, which will enable gasless transactions and ERC-7412 support for EOAs.
Abstract
Protocol clients will be able to simulate transactions, gather necessary signed data from decentralized oracle networks (such as prices), and use the functionality proposed in this SIP to create a single transaction that includes the verification and storage of the data necessary to complete a transaction.
Motivation
To implement SIP-329 with ERC-7412, we’d like to provide a method for constructing a multicall for EOAs. Waiting on the Ethereum ecosystem to move to smart contract wallets (per Account Abstraction, ERC-4337) is not viable.
Specification
Overview
Implementation involves:
- The deployment of an ERC-2771 compliant trusted forwarder including Multicall3 functionality (which appends
msg.sender
tomsg.data
, like the standard’sexecute
function and adds error bubbling). - The addition of an ERC2771Context library to the protocol which references the contract above as the trusted forwarder. (Note that deployment of the trusted forwarder with
CREATE2
guarantees a consistent address for the contract across chains, so it can be hardcoded.) - The use of
_msgSender
and_msgData
(from the context library) rather thanmsg.sender
andmsg.data
, respectively.
Rationale
We previously considered adding a multicallThrough
function to the MulticallModule
with an SCCP-configurable list of addresses external to the protocol which it could call. (This list could include oracle contracts, for example.) We opted to present the solution here instead because:
- All functions would need to be changed to
payable
to allow composing payable and otherwise non-payable calls in the multicall. This would be a breaking change, as the function signatures through the codebase would be altered. - The protocol’s attack surface would become larger, as exploits in the listed external addresses could have detrimental consequences for the protocol.
An added benefit of using a trusted forwarder is that we can take this opportunity to add ERC-2771 compliance, enabling gasless transactions.
Technical Specification
See draft implementations of the trusted-multicall-forwarder and the protocol upgrade.
A solhint linter can be used to help avoid mistaken explicit use of msg.sender
and msg.data
throughout the codebase.
Configurable Values
N/A
Copyright
Copyright and related rights waived via CC0.