SIP-340: Add Trusted Multicall Forwarder

Author
StatusImplemented
TypeGovernance
NetworkEthereum & Optimism
ImplementorTBD
ReleaseTBD
ProposalLoading status...
Created2023-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 to msg.data, like the standard’s execute 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 than msg.sender and msg.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 and related rights waived via CC0.