ERC-7884: Operation Router

Abstract

This EIP introduces a protocol that enables smart contracts to redirect write operations to external systems. The protocol defines a standardized way for contracts to indicate that an operation should be handled by either a contract deployed to an L2 chain, to the L1, or an off-chain database, providing an entry point for easy developer experience and client implementations.

Motivation

As the Ethereum ecosystem grows, there is an increasing need for efficient ways to manage data storage across different layers and systems.

This protocol addresses these challenges by:

• Providing a gas-efficient way to determine operation handlers through view functions
• Enabling seamless integration with L2 solutions and off-chain databases
• Maintaining strong security guarantees through typed signatures and standardized interfaces

Specification

Core Components

The protocol consists of three main components:

1. A view function named interface getOperationHandler for determining operation handlers that can be one of the following types: a. OperationHandledOnchain for on-chain handlers b. OperationHandledOffchain for off-chain handlers through a gateway
2. A standardized message format for off-chain storage authorization

Interface

The onchain flow is specified as follows:

It is important to notice that the getOperationHandler relies on the given argument, the encoded function, to specify which contract will the request be redirected to, therefore, it is unable to address multicall transactions that could lead to different destination contracts. That means that multicall that is known will be redirected to different contracts should be handled in a sequential way by first calling the getOperationHandler and then making the actual transaction to the returned contract.

Database flow

The HTTP request made to the gateway follows the same standard proposed by the EIP-3668 where the URL receives /{sender}/{data}.json enabling an API to behave just like an smart contract would. However, the EIP-712 Typed Signature was introduced to enable authentication.

Implementation Example

The contract deployed to the L1 MUST implement the getOperationHandler to act as a router redirecting the requests to the respective handler.

The client implementation would look as follows:

Rationale

The standard aims to enable offchain writing operations, designed to be a complement for the CCIP-Read (ERC-3668) which is already widely adopted by the community.

Backwards Compatibility

This EIP is fully backward compatible as it:

• Introduces new interfaces that don't conflict with existing ones
• Uses view functions to gather offchain information
• Can be implemented alongside existing storage patterns

Security Considerations

Handler Validation

Off-chain handlers must:

• Verify EIP-712 signatures
• Implement proper access controls
• Handle concurrent modifications safely

General Recommendations

• Implement rate limiting for off-chain handlers
• Use secure transport (HTTPS) for off-chain communications
• Monitor for unusual patterns that might indicate attacks
• Implement proper error handling for failed transactions

Copyright

Copyright and related rights waived via CC0.