JSON-RPC: Eight Conformance Checks Against the Live Endpoint, and All Eight Pass

Why this is worth checking rather than asserting

JSON-RPC is a very small specification, which is exactly why implementations get it wrong: the easy parts are obvious and the edges are ignored.

The edges are where a client library breaks. "We speak JSON-RPC 2.0" is a claim about behaviour under conditions nobody tests by hand, so this page tested them.

Eight checks, and what came back

a batch of two calls returns an array of two responses with both identifiers echoed > a notification, sent with no identifier, returns an empty body > a string identifier comes back as the same string rather than a number > a request missing the version field is refused with invalid request > a request claiming version one is refused the same way > too few parameters is refused with invalid params, and a data field naming the problem > a malformed body is refused with parse error and a null identifier > omitted parameters on a method that takes none simply works All eight are the specification's required behaviour, including the two most commonly missed: a notification must produce no response at all, and a parse error must report a null identifier because the real one could not be read.

CONTROL: the battery mixes requests that must succeed with requests that must fail with named codes. A server that answered everything would fail it, and so would a server that refused everything.

And the HTTP layer is also right

a request with the wrong content type is refused, rather than parsed anyway a preflight returns the allowed method and header lists, not a blanket answer the vary header names the request headers the response actually depends on a plain browser visit returns a readable page instead of a protocol error

The strict content-type refusal is the one worth calling out. Accepting anything that happens to parse is the lazy option, and this endpoint declines it.

Why the open origin policy is correct here

The endpoint allows requests from any origin, which looks alarming and is right.

Every method is either read-only or requires a signature, and a browser cannot produce that signature without a key it does not have. So there is nothing an open origin policy gives away, and closing it would only break the browser tools this endpoint exists to serve.

The reasoning matters more than the setting. An open policy is correct when nothing is authorised by origin, and wrong the moment anything is.

The other half, which this page will not omit

Conformance is about the shape of the conversation, not what is in it.

Twenty methods are served. No certificate, no state proof, no anchor, and no compute record is among them, and several pages in this estate end at that wall.

And one trap for anybody iterating: use the canonical sequence, not the height. Three chained blocks share a height value, and the interface's own documentation says to prefer the sequence for exactly this reason.

One observation, hedged as an observation

The node reports its own resident memory. Two samples about two hours apart show it higher in the second, on a chain that produced very few blocks between them.

And the obvious inference is ruled out by arithmetic, which is worth more than the hedge. Extrapolating that difference across the process's uptime would predict a size many times larger than what it actually reports. So it is not a steady leak. It is either recent, episodic, or an artefact of comparing two different instruments.

Two points are still not a trend, and a third taken minutes later moved by a negligible amount. It is written down so somebody watches it over days rather than hours, which is the only thing that would settle it.

What you can check yourself

send a notification: a request with no id field

You should get an empty body, not a response with a null identifier. Then send a batch of two calls and confirm you get an array back. Those two catch most non-conforming servers on their own.