Transaction lanes: reserved blockspace with custom lane support

Start with EvolvePayloadBuilder in crates/node/src/builder.rs, then inspect the proposed Lane, LaneMatcher, and LanePolicy locations in crates/common/ or crates/evolve/. Trace the existing EvolveConfig chainspec extras and receipt/RPC paths before defining the integration points. Done means the checklist is covered, including lane guarantees, overflow, metrics, RPC and receipt metadata, integration tests, and documentation.

Summary

Implement a lane-based block construction system in the payload builder that reserves blockspace for different transaction categories, with built-in payment lanes and a pluggable interface for custom lanes.

Motivation

At 100ms block times with sequencer-controlled ordering, the scarce resource isn't confirmation speed -- it's guaranteed throughput under congestion. When block gas is fully utilized, high-value payment transactions compete with arbitrary EVM workloads (DeFi, NFT mints, contract deployments). Payment lanes guarantee that stablecoin transfers and payment-critical transactions always have access to blockspace, regardless of what else is happening on-chain.

Custom lanes extend this to any transaction category a chain operator cares about: system transactions, oracle updates, bridge operations, or domain-specific workloads.

Design

Lane model

A lane defines:

• Name / ID: identifier for the lane (e.g., payment, system, general)
• Gas reservation: minimum gas guaranteed for this lane per block
• Gas cap: maximum gas this lane can consume (optional -- lanes can overflow into general capacity)
• Matcher: predicate that routes a transaction to a lane (by tx type, destination address, calldata selector, or custom logic)
• Priority: ordering within the lane (FIFO, fee-based, or custom)

Block structure

Block gas_limit: 30M
├── system lane:   2M reserved  (system txs, L1 info, oracle updates)
├── payment lane:  15M reserved (stablecoin transfers, 0x76 payment calls)
├── general lane:  13M remainder (everything else)
└── overflow: unused lane capacity redistributed to general

Chainspec configuration

{
  "evolve": {
    "lanes": [
      {
        "id": "system",
        "gas_reserved": 2000000,
        "matcher": { "type": "tx_type", "values": ["system"] },
        "priority": "fifo"
      },
      {
        "id": "payment",
        "gas_reserved": 15000000,
        "gas_cap": 20000000,
        "matcher": {
          "type": "any_of",
          "rules": [
            { "type": "to_address", "addresses": ["0x...USDC", "0x...USDT"] },
            { "type": "selector", "selectors": ["0xa9059cbb", "0x23b872dd"] }
          ]
        },
        "priority": "fee"
      }
    ],
    "lanes_activation_height": 0
  }
}

Custom lane interface

Chain operators can define lanes via chainspec (static) or register them programmatically via a trait:

pub trait LaneMatcher: Send + Sync {
    /// Returns the lane ID this transaction belongs to, or None for general lane.
    fn match_tx(&self, tx: &EvTxEnvelope, state: &dyn StateProvider) -> Option<LaneId>;
}

pub trait LanePolicy: Send + Sync {
    /// Orders transactions within a lane. Returns sorted transaction list.
    fn order(&self, txs: Vec<&EvTxEnvelope>) -> Vec<&EvTxEnvelope>;
}

This allows customers to:

• Define lanes by contract address, function selector, tx type, sender allowlist, or arbitrary state-dependent logic
• Implement custom ordering within lanes (auction-based, priority fee, FIFO, round-robin)
• Compose matchers (any_of, all_of, not)

Payload builder integration

EvolvePayloadBuilder in crates/node/src/builder.rs changes:

1. Classify: Route each incoming transaction to a lane via matchers
2. Reserve: Allocate gas budget per lane from block gas limit
3. Fill: Execute transactions lane-by-lane, respecting per-lane gas reservations
4. Overflow: Redistribute unused lane capacity to general lane
5. Metrics: Emit per-lane utilization metrics (gas used, tx count, overflow)

Receipt / RPC extensions

• eth_getTransactionReceipt includes lane field indicating which lane the tx was routed to
• New RPC: evolve_getLaneStatus returns current lane utilization and available capacity
• Useful for clients to estimate inclusion probability and fee dynamics per lane

Scope

• Define Lane, LaneMatcher, LanePolicy traits in crates/common/ or crates/evolve/
• Implement built-in matchers: tx_type, to_address, selector, sender, any_of, all_of
• Add lane configuration to EvolveConfig chainspec extras
• Modify EvolvePayloadBuilder to classify, reserve, fill, and overflow
• Add per-lane metrics (gas used, tx count, overflow events)
• Extend RPC with lane status endpoint
• Extend receipts with lane metadata
• Integration tests: congested blocks with lane guarantees, overflow behavior, custom matcher registration
• Documentation: how to define custom lanes for a chain deployment

Prior art

• Tempo: payment lanes with dual gas limits -- general_gas_limit caps non-payment gas, remaining reserved for payments
• Ethereum EIP-7766: Priority lanes proposal -- similar concept for L1
• #94 (closed) -- ToB auction research; auction-based ordering becomes a LanePolicy implementation
• #127 (closed) -- pre-confirmations; moot at 100ms blocks, lane guarantees are the actual need