Abstract
This ERC defines a standard interface for shared sequencer contracts on Ethereum Layer 2 networks, with a specific focus on compatibility with autonomous agent systems. It provides a minimal, stateless, gas-predictable interface enabling agents and applications to interact with any compliant shared sequencer implementation without chain-specific integration work.
Motivation
Vitalik Buterin's February 2026 critique of "copypasta L2 chains" highlighted the need for innovative infrastructure that tightly couples application-specific systems to Ethereum's security guarantees. Shared sequencers (Espresso, Taiko's based sequencing, Puffer UniFi) represent one of the most promising vectors for this coupling — but each project currently implements a proprietary interface. There is no standard.
This fragmentation creates real problems:
For autonomous AI agents: Agents operating on L2s need gas-predictable submission costs, explicit machine-readable error codes for automated retry logic, and stateless view functions for pre-flight checks. No current shared sequencer implementation is designed with autonomous agents as a primary user.
For tooling developers: Wallets, block explorers, monitoring infrastructure, and SDKs must write custom integrations for every sequencer.
For the ecosystem: The post-Astria vacuum (Astria shut down December 2025) and the EF's 2026 Protocol Priorities interoperability track create a direct opening for a clean, minimal interface standard.
This ERC proposes a minimal standard interface that:
- Enables any autonomous agent to interact with any compliant shared sequencer
- Provides gas-predictable submission with cost estimation
- Returns explicit, machine-readable error codes
- Exposes sequencer metadata for dynamic agent adaptation
- Defines slashing event signatures for decentralized sequencer accountability
Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Interface
// SPDX-License-Identifier: MIT
pragma solidity >=0.8.19 <0.9.0;
interface ISharedSequencer {
struct ConfirmationReceipt {
uint64 timestamp;
bytes32 l1TxHash;
bytes32 l2TxHash;
uint8 status;
string errorReason;
}
struct SequencerMetadata {
string version;
address[] supportedL2s;
uint256 minConfirmationTime;
uint256 maxTxSize;
}
event TransactionSubmitted(address indexed sender, bytes32 indexed transactionId, uint256 paidAmount);
event TransactionConfirmed(bytes32 indexed transactionId, bytes32 l1TxHash, bytes32 l2TxHash);
event TransactionFailed(bytes32 indexed transactionId, string errorReason);
event SequencerSlashed(address indexed sequencer, uint256 slashAmount, string reason);
function submitTransaction(bytes calldata transactionData) external payable returns (bytes32 transactionId);
function getConfirmationReceipt(bytes32 transactionId) external view returns (ConfirmationReceipt memory);
function estimateSubmissionCost(bytes calldata transactionData) external view returns (uint256 totalCostWei);
function getSequencerMetadata() external view returns (SequencerMetadata memory);
}Design Principles
Agent-first: All status queries are view functions. Agents can poll confirmation status at zero gas cost.
Gas predictability: estimateSubmissionCost() MUST be implemented as a view function, allowing agents to budget before submission. Implementations SHOULD be accurate within ±10%.
Explicit errors: Implementations SHOULD use custom errors rather than string reverts to enable efficient agent-side error handling and retry logic.
Composability: The interface is minimal by design. Agents MAY wrap it for batching, scheduling, or multi-sequencer routing without protocol changes.
Decentralization-ready: The SequencerSlashed event provides a standard signature for decentralized sequencer accountability systems.
Functions
submitTransaction
Submits a transaction to the shared sequencer for ordering and inclusion.
MUST be payable. MUST return a unique transactionId. MUST emit TransactionSubmitted. MUST revert if msg.value is insufficient to cover submission costs.
getConfirmationReceipt
Returns the confirmation receipt for a previously submitted transaction.
MUST be a view function (zero gas cost for callers). MUST return a ConfirmationReceipt with status of 0 (pending), 1 (confirmed), or 2 (failed). If status is 2, errorReason MUST be non-empty.
estimateSubmissionCost
Estimates the total cost in wei to submit the given transaction data.
MUST be a view function. SHOULD account for current block.basefee and any sequencer-specific fees.
getSequencerMetadata
Returns metadata about the sequencer implementation.
MUST be a view function. MUST include the list of supported L2 chains and maximum transaction size.
Rationale
Why string errorReason in ConfirmationReceipt?
The errorReason field is intentionally a string rather than a custom error type. Confirmation receipts are returned from view functions — there is no revert context to propagate typed errors. Human-readable strings allow agents to log and surface failure reasons while implementations are still encouraged to use custom errors in their revert paths for gas efficiency.
Why a single submitTransaction rather than batching?
Minimal surface area maximizes composability. Batching, scheduling, and multi-sequencer routing are higher-order concerns best handled by wrapper contracts. A batch-aware interface MAY be proposed as a companion ERC extending this one.
Why agent-first design?
Autonomous agents are emerging as primary users of L2 infrastructure. Unlike human users who interact through wallets and UIs, agents need programmatic interfaces with predictable costs, machine-readable errors, and stateless queries. Designing for agents first produces an interface that is equally usable by traditional applications but adds no complexity for them.
Backwards Compatibility
This ERC introduces a new interface standard with no modifications to existing contracts, protocols, or clients. It is fully backwards compatible.
Reference Implementation
A complete reference implementation is provided in the assets directory, including:
MockSharedSequencer.sol— full implementation with O(1) receipt storage, spam protection, emergency pause, dynamic cost estimation- Custom error types:
InsufficientFee,SequencerPaused,ReceiptNotFound,MalformedTransaction - Foundry test suite: 14 tests (unit, fuzz, invariant, gas profiling, regression)
Security Considerations
Reentrancy: submitTransaction is payable. Implementations MUST use Checks-Effects-Interactions ordering or ReentrancyGuard.
Front-running: Transaction submission ordering is at sequencer discretion. Agents MUST NOT rely on submission order for time-sensitive operations.
Sequencer trust: This standard does not enforce decentralization. The SequencerSlashed event is designed for decentralized implementations. Agents SHOULD call getSequencerMetadata() to understand the trust model before use.
Fee volatility: estimateSubmissionCost() uses block.basefee which fluctuates. Agents SHOULD apply a buffer (RECOMMENDED: 20%) to all estimates.
DoS via spam: Permissionless deployments MUST implement fee or staking requirements to prevent spam submissions.
Copyright
Copyright and related rights waived via CC0.
