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

    • Standard JSON-RPC Errors (-32768 to -32000) (existing)
    • Client-specific Errors (-32099 to -32000) (existing)
    • Gas/Fees Errors (-31999 to -31800)
    • EVM-related Errors (-31799 to -31600)
    • Consensus Errors (-31599 to -31400)
    • Network Errors (-31399 to -31200)
    • TxPool Errors (-31199 to -31000)
  • Expected Error codes response validation implementation can be found here

@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 <[email protected]>
@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?

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.

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.

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"

Comment on lines +53 to +113
## Catalog reference

### [JSON-RPC standard errors](https://www.jsonrpc.org/specification) (`rpc-standard-errors.yaml`)
| Code | Message | Notes |
| --- | --- | --- |
| $-32700$ | Parse error | An error occurred on the server while parsing the JSON text |
| $-32600$ | Invalid request | The JSON sent is not a valid request object |
| $-32601$ | Method not found | The method does not exist / is not available |
| $-32602$ | Invalid params | Invalid method parameter(s) |
| $-32603$ | Internal error | Internal JSON-RPC error |

### [JSON-RPC non-standard errors](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1474.md) (`rpc-non-standard-errors.yaml`)
| Code | Message | Notes |
| --- | --- | --- |
| $-32000$ | Invalid input | Missing or invalid parameters |
| $-32001$ | Resource not found | Requested resource not found |
| $-32002$ | Resource unavailable | Requested resource not available |
| $-32003$ | Transaction rejected | Transaction creation failed |
| $-32004$ | Method not supported | Method is not implemented |
| $-32005$ | Limit exceeded | Request exceeds defined limit |
| $-32006$ | JSON-RPC version not supported | Version of JSON-RPC protocol is not supported |

### Gas errors (`gas-error-groups.yaml`)
| Code | Message | Data |
| --- | --- | --- |
| $-31800$ | GAS_TOO_LOW | Transaction gas is too low / intrinsic gas too low |
| $-31801$ | OUT_OF_GAS | The transaction ran out of gas |
| $-31802$ | GAS_PRICE_TOO_LOW | Gas price too low / gas price below configured minimum gas price |
| $-31803$ | BLOCK_GAS_LIMIT_EXCEEDED | Tx gas limit exceeds max block gas limit / intrinsic gas exceeds gas limit |
| $-31804$ | FEE_CAP_EXCEEDED | Tx fee exceeds cap / max priority fee per gas higher than max fee per gas |
| $-31805$ | GAS_OVERFLOW | Gas overflow error |
| $-31806$ | INSUFFICIENT_TRANSACTION_PRICE | Transaction price must be greater than base fee / max fee per gas less than block base fee |
| $-31807$ | INVALID_MAX_PRIORITY_FEE_PER_GAS | Max priority fee per gas higher than $2^{256}-1$ |
| $-31808$ | INVALID_MAX_FEE_PER_GAS | Max fee per gas higher than $2^{256}-1$ |
| $-31809$ | INSUFFICIENT_FUNDS | Insufficient funds for gas * price + value |
| $-31810$ | TRANSACTION_UNDERPRICED | Transaction's gas price is below the minimum for txpool |
| $-31811$ | REPLACEMENT_TRANSACTION_UNDERPRICED | Replacement transaction is sent without the required price bump |

### Execution errors (`execution-errors.yaml`)
| Code | Message | Data |
| --- | --- | --- |
| $-31600$ | NONCE_TOO_LOW | Transaction nonce is lower than the sender account's current nonce |
| $-31601$ | NONCE_TOO_HIGH | Transaction nonce is higher than the sender account's current nonce |
| $-31602$ | EXECUTION_REVERTED | Execution is reverted by REVERT Opcode |
| $-31603$ | INVALID_OPCODE | An invalid opcode was encountered during execution |
| $-31604$ | OUT_OF_COUNTERS | Not enough step counters to continue the execution |

### TxPool errors (`txpool-errors.yaml`)
| Code | Message | Data |
| --- | --- | --- |
| $-31000$ | ALREADY_KNOWN | Transaction is already known to the transaction pool |
| $-31001$ | INVALID_SENDER | Transaction sender is invalid |
| $-31002$ | INVALID_SIGNATURE | Transaction signature is invalid |
| $-31003$ | TXPOOL_FULL | Transaction pool is full |
| $-31004$ | NEGATIVE_VALUE | Transaction with negative value |
| $-31005$ | OVERSIZED_DATA | Transaction input data exceeds the allowed limit |
| $-31006$ | SENDER_BLACKLISTED | Transaction sender is blacklisted |
| $-31007$ | RECEIVER_BLACKLISTED | Transaction receiver is blacklisted |
| $-31008$ | CHAIN_ID_MISMATCH | Transaction chain ID does not match the expected chain ID |
| $-31009$ | TX_NOT_PERMITTED | Transaction is protected and cannot be permitted for unauthorized users |
| $-31010$ | INVALID_RLP_DATA | Transaction Data contains invalid RLP encoding |
Copy link
Contributor

Choose a reason for hiding this comment

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

Please do not re-list all the errors in this document.

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.

4 participants