Skip to content

Explorer integration: Blockscout and Atlas support for 0x76 transactions #130

@tac0turtle

Description

@tac0turtle

Summary

Integrate block explorer support for ev-reth chains, targeting both Blockscout (open-source, self-hosted) and Atlas (in-house explorer). Both need custom rendering for Evolve-specific transaction types (0x76 batch calls, fee sponsorship).

Motivation

Every production chain needs a block explorer. ev-reth's custom transaction type (0x76) with batch calls and fee sponsorship won't render correctly in stock explorers -- it will show as an unknown transaction type with opaque calldata. Both Blockscout (for self-hosted/community deployments) and Atlas (for first-party deployments) need to understand Evolve primitives.

Scope

1. RPC layer (shared by both explorers)

The RPC responses from ev-reth must expose 0x76 fields in a way explorers can consume:

  • eth_getTransactionByHash must include feePayer (address), calls (array of {to, value, input}), and txType: "0x76"
  • eth_getTransactionReceipt must indicate effective gas payer and per-call log attribution
  • This is the foundation -- get the RPC right and both explorers benefit

2. Blockscout integration

  • Document archive node configuration for ev-reth
  • Docker compose setup for Blockscout + ev-reth
  • Verify standard Ethereum transactions (types 0, 1, 2, 3) render correctly
  • Verify RPC compatibility (Blockscout's required endpoints vs ev-reth's exposed endpoints)
  • Custom 0x76 rendering via Blockscout's plugin/extension system:
    • Batch calls: Display individual calls within a 0x76 transaction instead of opaque calldata
    • Fee sponsorship: Show feePayer address, distinguish executor vs sponsor
    • Transaction type label: "EvNode Transaction" instead of "Unknown Type"

3. Atlas integration

  • Ensure Atlas consumes the extended RPC fields for 0x76 transactions
  • Native rendering of batch calls, sponsorship, and Evolve-specific metadata
  • Atlas can go deeper than Blockscout since it's in-house: lane attribution, per-call gas breakdown, sponsor history, etc.

4. ev-node considerations

  • Explorers need to handle ev-reth's block structure (no ommers, modified consensus fields)
  • Block finality semantics: ev-node-derived finality vs explorer default assumptions
  • If the chain uses ev-node for DA, explorers should ideally link to DA layer block references

Prior art

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions