---
eip: 8166
title: Shared Sequencer Interface for Agent L2s
description: An interface for shared sequencer contracts on Ethereum L2 networks, designed for autonomous agent compatibility.
author: Michael Winczuk (@michaelwinczuk)
discussions-to: https://ethereum-magicians.org/t/erc-8166-shared-sequencer-interface-for-agent-l2s/27772
status: Draft
type: Standards Track
category: ERC
created: 2026-02-19
---

## 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:

1. Enables any autonomous agent to interact with any compliant shared sequencer
2. Provides gas-predictable submission with cost estimation
3. Returns explicit, machine-readable error codes
4. Exposes sequencer metadata for dynamic agent adaptation
5. 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

```solidity
// 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](../LICENSE.md).