Skip to content

Conversation

@simsonraj
Copy link

@simsonraj simsonraj commented May 10, 2025

Goal

A standard for JSON-RPC error codes and messages across EVM-compatible chains and execution clients to improve interoperability, facilitate consistent error handling, and provide a better developer experience.

Motivation

Different Ethereum clients and EVM-compatible chains often use overlapping error codes or generic messages in their JSON-RPC API responses. This inconsistency confuses end users and developers, complicates cross-client tooling, and hampers interoperability.

Solution Abstract

  • This is made possible by extending the Open-RPC spec to support Extension specs, particularly by utilizing the x-error-group extension spec
  • This solution aims to address the inconsistent error codes by categorising common error scenarios
  • Each category could have a reserved range (200 in this case) error codes allotted between (-31999 to -30000), excluding the ranges specified in the JSON-RPC 2.0 specification.
  • Example: Below is an example categorisation to imagine how the standardization could look like & can be amended as per feedback with different stakeholders

Reserved ranges at a glance

Extension group Category label Reserved range Source
JSON-RPC standard $-32768$ to $-32000$ JSON-RPC 2.0 spec
JSON-RPC non-standard Client-specific $-32099$ to $-32000$ JSON-RPC 2.0 addendum
Gas errors GAS_ERRORS $800$ to $999$ gas-error-groups.yaml
Execution errors EXECUTION_ERRORS $1$ to $199$ execution-errors.yaml
TxPool errors TXPOOL_ERRORS $1000$ to $1199$ txpool-errors.yaml
ZK execution errors ZK_EXECUTION_ERRORS $2000$ to $2199$ zk-execution-errors.yaml

@simsonraj simsonraj changed the title JSON RPC Error codes standardisation: A sample implementation JSON RPC Error codes standardization: A sample implementation May 10, 2025
@simsonraj simsonraj changed the title JSON RPC Error codes standardization: A sample implementation JSON RPC Error codes standardization: Extended Error groups [ Sample implementation] May 10, 2025
@simsonraj simsonraj changed the title JSON RPC Error codes standardization: Extended Error groups [ Sample implementation] JSON RPC Error codes standardization: open-rpc extension specs [A Sample implementation] May 10, 2025
Co-authored-by: Zane Starr <zcstarr@gmail.com>
@sambacha
Copy link

STOP THIS A.I. SLOP NOW!!!!!!!!!!!!

@zcstarr
Copy link
Contributor

zcstarr commented May 28, 2025

@sambacha this is not AI, but the culmination of many months and pretty close to a year of work, to put together a PR that can help move the ecosystem forward. If you have a criticism of the PR or something about it's content please feel free to comment with something constructive or instructive.

If you don't have anything constructive to add to this conversation, please refrain from spamming the PR with comments

@simsonraj simsonraj changed the title JSON RPC Error codes standardization: open-rpc extension specs [A Sample implementation] JSON RPC Error codes standardization using open-rpc extension specs Sep 26, 2025
let extensionSpecs = [];

// Enhance the existing XErrorGroupsJSON extension with conditional validation for different error categories
const enhancedErrorGroupSchema = JSON.parse(fs.readFileSync('src/extensions/schemas/x-error-category-ranges.json', 'utf8'));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just going to write this here for tracking purposes, that this works as a stopgap until we on the OpenRPC side have a better story for being able to apply extensions to json pointer references. If we have that then there's no need to overwrite the error group spec. You'll able to just push the two specs, here but we're still a little ways from that.

@fjl
Copy link
Contributor

fjl commented Oct 13, 2025

One thing to note, is that there is no requirement for RPC errors to be negative numbers. The JSON-RPC specification itself uses a specific range of negative numbers for its errors, but the predefined errors are just for reporting protocol-level faults.

The entire range of positive integer values is available to us, so we should use it.

message: "EXECUTION_REVERTED"
data: "Execution is reverted by REVERT Opcode"
x-error-category: "EXECUTION_ERRORS"
- code: -31603
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this error condition exists here?

Copy link
Contributor

@macfarla macfarla Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#600 just merged has reverted error code = 3 which contradicts this. will this value change?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will fix this as per our last RPC call, it will still be code = 3

message: "INVALID_OPCODE"
data: "An invalid opcode was encountered during execution"
x-error-category: "EXECUTION_ERRORS"
- code: -31604
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same with this one, what is the meaning of this particular code? The term "step counters" has no defined meaning in Ethereum.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is ZK stack specific, I will move this out to a separate category

Comment on lines +6 to +11
- code: -32001
message: "Resource not found"
data: "Requested resource not found"
- code: -32002
message: "Resource unavailable"
data: "Requested resource not available"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the meaning of these two codes? These are very generic errors. I suggest we drop these, since they are not meaningful.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just reflect the standard we already have
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1474.md

Comment on lines 39 to 41
- code: -31009
message: "TX_NOT_PERMITTED"
data: "Transaction is protected and cannot be permitted for unauthorized users"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the meaning of "transaction is protected"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated this description

simsonraj and others added 4 commits October 19, 2025 19:34
Co-authored-by: Sally MacFarlane <macfarla.github@gmail.com>
Co-authored-by: Sally MacFarlane <macfarla.github@gmail.com>
Co-authored-by: Sally MacFarlane <macfarla.github@gmail.com>
Co-authored-by: Sally MacFarlane <macfarla.github@gmail.com>
@simsonraj simsonraj requested review from fjl, macfarla and zcstarr October 25, 2025 15:14
@fjl fjl removed the triage label Oct 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants