Skip to content

Proposal: eth_getCapabilities method #697

@s1na

Description

@s1na

Summary

Add a discovery method eth_getCapabilities that lets clients advertise what historical coverage their node actually maintains, so users, middleware, and infra can route queries correctly instead of trial-and-error or out-of-band guesses.

This is about data coverage, not feature flags. It answers questions like:
• Which transaction-hash index do you keep (from block X to block Y)?
• Which logs/receipts range do you keep?
• Which canonical block history do you serve?
• Which historical state (world-state) ranges can you answer eth_call/eth_getBalance/eth_getStorageAt for?
• Which trie node history (for proofs/time-travel state) do you keep?

Motivation

Nodes now run with varied pruning/indexing modes (archive, partial archive, snap-pruned, custom log indexers, state diffs, etc.). Without a standard discovery mechanism:
• Clients spray RPCs that fail unpredictably.
• Load balancers can’t route by capability.
• Users infer coverage from client brand/mode, which is error-prone.

A single, cheap call that returns machine-readable coverage ranges fixes this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions