Inspect what runs. Understand what it proves.
Open the service, run the check yourself, and read exactly where our evidence stops. Measured AI means the depth is stated, not implied — so we would rather you found the limits here than in a procurement review.
Rootz Node: a signed service response
On 15 September 2026 at 15:02 UTC, a public JSON-RPC request returned Polygon block 93,853,009. A client-side check verified the Ed25519 and P-256 signatures, the keyset digest and the certification signature against the supplied root key. The node demonstrably authored the envelope.
And the binding is checkable by you, without asking us. The envelope commits to the exact wire bytes of the response: payload.hash = BASE64URL(SHA-256(JCS(signedObject))), where signedObject for a JSON-RPC response is {rpc_body_bytes, rpc_body_sha256}. The body is never re-parsed — JSON.parse silently corrupts integers beyond 253, and chain data is full of them — so the commitment is to the bytes as they crossed the wire.
The rule is published, and three frozen test vectors are served live at /verify/vectors.json so you can validate your verifier before you write a line against the live service. We reproduced all three independently on 17 September 2026.
Worth stating, since this page is about honesty rather than polish. Two independent implementers — including us — first concluded this signature did not bind to content, because both hashed the response body directly and got a mismatch. The cryptography was sound the whole time; the documentation was not, and that was our defect rather than theirs. It was found by someone trying to verify us, published as a rule with vectors on 15 September, and it is the reason this paragraph exists. A signature only our own code can check is a claim, not a proof.
The public request in this check was unsigned. This observation verifies the signed-output path against the supplied keys; it does not independently establish the hardware identity or demonstrate signed-request authorization.
The published Node scope
| Available evidence | Declared boundary |
|---|---|
| Boot measurements for PCR 0, 4 and 7 | The Bor chain-client binary is outside the measured set. Runtime integrity is not claimed. |
| A software vTPM signing root and OCI instance identity evidence | The published root is a software vTPM. The instance certificate asserts identity, not runtime integrity. |
| Signed MCP results and JSON-RPC responses | Inspect the covered content, request context and validity window for the chosen call. |
| Committed index queries with explicit coverage | A completeness claim applies to the declared key space and range. Required freshness must be checked. |
The wider Rootz system
The services below show different parts of the architecture. They have different evidence profiles; their results should be evaluated on that basis.
Origin’s SEC source references and leaf hashes support independent source checks; they are not SEC-issued cryptographic signatures.
What a customer engagement must establish
Signed intent and authorized execution
Demonstrate the complete request-to-result path in the customer’s selected workflow.
Required measurement depth
Integrate and validate the application, model or hardware evidence the customer needs.
Recipient enforcement
Show that the receiving system actually blocks or routes a failed evidence check.
Operational continuity
Exercise key rotation, status changes, evidence retention and recovery.
A design is not a customer deployment.
The driver-licensing and building-permit pages describe proposed applications of the components. They do not claim a government rollout. A deployment report should identify the environment, exact checks and results before broader claims are made.
Ask for evidence that matches your decision.
We will define the demonstration and acceptance criteria with your architecture and service teams.
Scope your evidence profile