ERC-7412 is a standard that allows smart contract engineers to incorporate off-chain data by simply calling functions on oracle contracts. It preserves composability across smart contracts and also aligns economic incentives between data consumers and oracle networks. This standard relies on transaction batching (i.e. atomic multi-operations, multicalls) to automatically prepend the verification of data from decentralized oracle networks when necessary to execute a transaction.

Synthetix’s Core Contributors developed the trusted multicall forwarder for use with Synthetix V3. It’s a trusted forwarder (per ERC-2771) that includes Multicall3 functionality. This is necessary to enable transaction batching for externally-owned accounts, which are currently used by the majority of people interacting with Ethereum.

This is intended to become obsolete as account abstraction solutions (per ERC-4337) become more widely adopted, since they allow for transaction batching without requiring protocol-level changes. Long-term, it would be ideal for ERC-7412 support to be added to wallet applications. Decentralized oracle networks could feel more like “first-class citizens” in their user experience. Just as you currently configure your wallet to use RPC URLs for blockchains that correspond to chain IDs, you could also manage RPC URLs for a variety of oracle IDs. The proliferation of oracles will ultimately enable more real-world applications for Ethereum outside of finance.

In the meantime, I was thinking it’d be worthwhile to add a system for batching adapters to the ERC-7412 library. There are already a few redundant implementations out there for batching with the trusted multicall forwarder.

I’m also excited that integrators in the Synthetix ecosystem are being very forward-thinking with account abstraction and the possibilities it unlocks for user experience. Kwenta, Polynomial, and Infinex are building features like social sign-in/account recovery, one-click transactions, auto-bridging, delegated trading, and more. The trusted multicall forwarder might become obsolete sooner than I thought. I started looking into how best to create batching adapters for the leading account abstraction solutions as well.

Here’s a rough draft pull request with an adapter for the trusted multicall forwarder and another for Biconomy. It automatically determines a valid approach for batching a given list of transactions and implements some caching to reduce RPC calls. This pull request also adds a function to return a list of transactions (not only a generated batch transaction) such that the list can be sent to a paymaster.

I feel like I’m still getting caught up on recent developments around account abstraction, so I’m very interested in feedback. Conversation can happen in the pull request on GitHub. Happy New Year!