Blockchain

De facto standards for the blockchain layer, published by the API Commons.

Nobody ratified the Ethereum JSON-RPC interface as a standard for every other chain. It became one because every EVM chain and every node provider implemented it, and a client written for one now points at hundreds by changing a URL.

This repository measures what that actually gets you — by calling the methods.

Measured, not read

The other profiles in this org grade a standard by counting what adopters declare in their published OpenAPI. That does not work here. A JSON-RPC provider exposes one endpoint and a method name in the request body, so there are no paths to count: of the 86 providers in the catalog claiming EVM compatibility, some publish a path per method, some publish a single /, and most publish no spec at all.

The endpoints, though, are public, free and unauthenticated by design. So the strongest evidence grade available anywhere in this org — actually calling the method — is also the cheapest one here. 42 endpoints were called; 21 produced usable results.

Method	Tier	Endpoints serving	Share
eth_blockNumber	core	20	95.2%
eth_chainId	core	20	95.2%
eth_estimateGas	core	20	95.2%
eth_gasPrice	core	20	95.2%
eth_getBlockByNumber	core	20	95.2%
eth_getBlockTransactionCountByNumber	core	20	95.2%

Read-only throughout: no transaction was ever submitted and nothing here costs gas. The core tier is 22 methods — what a majority of endpoints serve, method by method, which is not the same as any one endpoint serving all of it. The median endpoint serves 20 of 22, and 8 serve every one. The core methods most often missing are the most recently added: eth_blobBaseFee, eth_createAccessList, eth_getProof. Adoption lags the specification, and the profile records where.

The signals, and the one that matters

Response	What it means
result present	The method is supported
error -32601	The only proof a method is absent
any other error code	The method exists and rejected this call
a non-JSON body	Not an RPC endpoint. Nothing was learned

Counting -32602 Invalid params as unsupported would under-report every provider whose argument validation is stricter than the probe's guesses.

One endpoint served nothing, and that is a real answer

One endpoint in the cohort served 0 of the core methods while passing its negative control cleanly. It was checked by hand rather than published on trust: api.mainnet.iota.cafe answers rpc.discover with its own OpenRPC document and serves iota_getChainIdentifier. It is a working JSON-RPC server that genuinely does not implement the eth_ namespace, so the zero is a measurement. The catalog entry listing it as EVM-compatible is the thing that is wrong.

Every endpoint gets a negative control

Before any real method, each endpoint is asked for eth_thisMethodCannotExist. An endpoint that answers anything but -32601 has no working discriminator, so nothing it says about any method can be trusted — and it is recorded as inconclusive rather than read as a long list of absences.

This is not hypothetical. 8 of the endpoints failed it, and they failed in both directions. Some returned a valid-looking error for a method that cannot exist — including one whose catalog entry pointed at a documentation page rather than an RPC endpoint, which would have read as an EVM node implementing nothing. Two returned a successful result, which would have read as an endpoint implementing every method asked of it. Neither reading is recorded.

The engine namespace is supposed to be absent

25 of the upstream methods are engine_* — the consensus-layer API, spoken between a node's execution and consensus clients over an authenticated port. No public endpoint served any of them, and that is the correct result, not a gap. They are graded vendor, and the ruleset warns if a public profile advertises one.

What's here

standard/eth-jsonrpc/
  profile.yml        78 methods, each with its tier and the evidence
  openrpc.json       the artifact of record — the profile in the protocol's own format
  openapi.yml        a convenience wrapper: one path, method as a `const` in the body
  schema/            JSON Schema 2020-12 for the core request envelopes and results
  mcp/tools.json     MCP tool definitions for the core tier
  arazzo/            chainId, then blockNumber, then the block at that height
  spectral/          generated from the profile, with fixtures and a harness
adopters/
  eth-jsonrpc.yml    40 entries, each with the endpoint and the date probed
  eth-jsonrpc-matrix.md
scripts/             every artifact above is generated; none is hand-maintained

The OpenRPC is the artifact of record and the OpenAPI is a convenience. JSON-RPC has a specification format of its own; modelling it as a path per method would read more naturally and would describe an API that nobody serves.

Check a provider

Lint what they advertise:

npx @stoplight/spectral-cli lint their-openrpc.json \
  -r https://raw.githubusercontent.com/api-commons/blockchain/main/standard/eth-jsonrpc/spectral/eth-jsonrpc-profile.yaml

Or find out what they actually serve, which for JSON-RPC is the more interesting question:

python3 scripts/probe-adopters.py --endpoints endpoints.json --out probe.json

Who reaches the core tier

8 of 21 probed endpoints serve every core method. 13 serve some of it, which is not a failing grade — a partial implementation is a normal thing to be. 19 could not be probed at all and carry no tier, because an endpoint we could not reach is not an endpoint that failed.

Regenerate

python3 scripts/probe-adopters.py  --endpoints endpoints.json --out probe.json
python3 scripts/build-profile.py   --openrpc openrpc.json --probe probe.json --tag <tag> --sha <sha> --claimants 86
python3 scripts/build-artifacts.py
python3 scripts/build-ruleset.py
python3 scripts/harvest-adopters.py --probe probe.json --claimants claimants.json
python3 scripts/build-readme.py
node scripts/test-ruleset.mjs

The ruleset, its fixtures and this README are all generated from profile.yml, so a re-probe that moves a method between tiers moves the rules, the fixtures and this page with it.

Provenance

Derived from ethereum/execution-apis at release v1.0.0-beta.7 (commit 5aebdfdd45cadeb723be4bd45b4611b71c8b1c85) — OpenRPC 1.2.4, 78 methods.

That repository is CC0-1.0: public domain, the cleanest source of any standard in this programme. Ethereum JSON-RPC is a community specification and nothing here implies endorsement by the Ethereum Foundation or by any provider named in the registry.

Part of API Commons

Related

• adopters — the schema behind the registry
• models — the OpenAI and Anthropic interfaces

License

Artifacts are CC BY-NC-SA 4.0. Code in scripts/ is Apache-2.0.