The RPC Standards team is exploring endpoint-level versioning for the JSON-RPC API, and we’d love input from wallet devs and users before we finalize what v1 looks like. Are there specific methods or response fields where backward compatibility is critical for you, or any pain points when the spec changes that we should be aware of?
Background
The RPC Standards team recently merged a versioning scheme for the execution-apis repo via PR #704, which uses semver to give client developers a stable target so that new spec changes don’t immediately break hive rpc-compat tests. This covers repository-level versioning, and we are now exploring whether to also introduce endpoint-level versioning for the JSON-RPC API itself where wallet teams would be most directly impacted.
It’s worth noting that adding versioning is not expected to break backward compatibility for existing integrations, since everything currently pulls from main. The goal is to give developers a more stable and predictable target going forward.
We are currently defining the scope of v1 and would love your input on:
- What should or shouldn’t be included in v1 of the versioned spec?
- Would endpoint versioning (e.g. /v1/, /v2/) be useful for your workflows, or does it add unnecessary complexity?
- How do you currently handle breaking changes when the spec updates? What are your pain points?
- Are there specific methods or response fields where backward compatibility is critical for your wallet?
Join the discussion on the execution-apis repo, please drop your feedback in this thread, join the #json-rpc channel on the Ethereum R&D Discord, and feel free to join our bi-weekly RPC Standards calls (Mondays, 15:00 UTC).