Contracts may require off-chain data during execution. A smart contract function could implement the standard proposed here by reverting with error OracleDataRequired(address oracleContract, bytes oracleQuery, uint256 feeRequired). Clients supporting this standard would recognize this error message during a simulation of the request, query the specified decentralized oracle network for signed data, and instead stage a transaction with a multicall that prepends the verification of the required off-chain data. The data would be written on-chain during verification to a smart contract for the subsequent call to read, avoiding the error.
Ethereum's scaling roadmap involves a series of separate execution contexts for smart contract code (including layer two and layer three scaling solutions). This makes the ability to read data across multiple chains crucial to the construction of scalable applications. Also, for decentralized finance protocols that rely on price data, it is not reasonable to expect oracle networks will be able to continuously push fresh data to every layer two and layer three network for an arbitrary number of price feeds.
Cross-chain bridges are being developed where smart contract functions can write data to other chains. There is a need for a similar standard that enables reading data from other chains. This standard can be generalized for reading any off-chain data from a decentralized oracle network, including price feeds.
With standards for both writing and reading cross-chain data, protocol developers will be able to create abstractions for asynchronicity (a topic thoroughly explored in other software engineering contexts). This will enable the development of highly sophisticated protocols that do not suffer from scaling constraints.
ERC-3668 introduced the use of reverts for requiring off-chain data, but there are various challenges introduced by the specifics of that standard which are outlined in the Rationale section below. By leveraging multicalls rather than callback functions, the standard proposed here is able to overcome some of these constraints.
A contract implementing this standard MUST revert with the following error whenever off-chain data is required:
oracleQuery specifies the off-chain data that is being required. Valid data formats for this parameter are specific to the oracle ID specified by the oracle contract. This might include chain id, contract address, function signature, payload, and timestamp/"latest" for cross-chain reads. For price feeds, it could include a ticker symbol and timestamp/"latest".
oracleContract is the address of the contract which can verify the off-chain data and provide it to the contract to avoid the OracleDataRequired error. This contract MUST implement the following interface:
oracleId is a unique identifier that references the decentralized oracle network that generates the desired signed off-chain data. Oracle IDs would be analogous to Chain IDs in the Ethereum ecosystem. Clients are expected to resolve a gateway that corresponds to an Oracle ID, similar to how clients are expected to resolve an RPC endpoint based on a Chain ID.
It should be possible to derive the oracleQuery from the signedOffchainData, such that the oracle contract is able to provide the verified offchain data based on the oracleQuery.
The contract implementing the IERC7412 interface MUST revert with the following error message if it requires payment to fulfill the oracle data query:
amount specifies the amount of native gas tokens required to execute the fulfillOracleQuery function, denominated in wei. This error MUST be resolved if the caller provides sufficient msg.value such that the fee amount can be collected by the oracle contract. The contract MAY NOT return gas tokens if they are provided in excess of the amount. In practice, we would expect the fee amount to remain relatively stable, if not constant.
Additionally, to optimize for scenarios where multiple oracle data requests are needed (such as protocols requiring many price feeds simultaneously), the interface MAY include an error for batching multiple errors:
This allows clients to efficiently handle multiple OracleDataRequired errors in a single transaction simulation, reducing the number of separate requests needed. When encountering this error, clients should parse each error in the array and handle them accordingly, potentially using recursion for nested error objects.
It is the responsibility of the client to decide how to construct the multicall, where necessary the fulfillOracleQuery functions are being called before the intended function call in an atomic transaction. Wallets that support account abstraction (per ERC-4337) should already have the ability to generate atomic multi-operations. For EOA support, protocols could implement ERC-2771. A standard multicall contract can only be used to construct multicalls including functions which do not reference msg.sender or msg.data.
Note that URI could be used as the oracleId with a URI specified as the oracleQuery. This would allow this standard to be compliant with arbitrary on-chain URIs without requiring updates to a client library, similar to ERC-3668.
This proposal is essentially an alternative to ERC-3668 with a couple notable distinctions:
With this standard, not only can oracle providers scalably support an unlimited number of networks but they can also be compatible with local/forked networks for protocol development.
Another major advantage of this standard is that oracles can charge fees in the form of native gas tokens during the on-chain verification of the data. This creates an economic incentive where fees can be collected from data consumers and provided to node operators in the decentralized oracle network.
The following pseudocode illustrates an oversimplified version of the client SDK. Ideally, this could be implemented in wallets, but it could also be built into the application layer. This function takes a desired transaction and converts it into a multicall with the required data verification transactions prepended such that the OracleDataRequired errors would be avoided:
An oracle provider could create a contract (that might also perform some pre-processing) that would automatically trigger a request for off-chain data as follows:
Now a top-level protocol smart contract could implement a cross-chain function like so:
Note that the developer of the CrosschainAdder function does not need to be concerned with the implementation of this standard. The add function can simply call the function on the oracle contract as if it were retrieving on-chain data normally.
Cross-chain functions like this could also be leveraged to avoid O(n) (and greater) loops on-chain. For example, chainIdA and chainIdB could reference the same chain that the CrosschainAdder contract is deployed on with functionA and functionB as view functions with computationally intensive loops.
One potential risk introduced by this standard is that its reliance on multicalls could obfuscate transaction data in wallet applications that do not have more sophisticated transaction decoding functionality. This is an existing challenge being addressed by wallet application developers, as multicalls are increasingly common in protocol development outside of this standard.
Note that it is the responsibility of the verifier contract to confirm the validity of the data provided from the oracle network. This standard does not create any new opportunities for invalid data to be provided to a smart contract.
Copyright and related rights waived via CC0.