|Network||Ethereum & Optimism|
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.
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.
- The deployment of an ERC-2771 compliant trusted forwarder including Multicall3 functionality (which appends
msg.data, like the standard’s
executefunction 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
CREATE2guarantees a consistent address for the contract across chains, so it can be hardcoded.)
- The use of
_msgData(from the context library) rather than
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
payableto 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.
A solhint linter can be used to help avoid mistaken explicit use of
msg.data throughout the codebase.
Copyright and related rights waived via CC0.