Verify a signed response

Every paid response from these services is Ed25519-signed and carries an evidence record stating what was checked and what the answer does not establish. This page verifies the signature in your browser and renders that record. Your pasted response stays in your browser. Public signing keys are fetched from the services below.

ChainVerdict receipt? Its signature is in the response headers. Paste them here.

ChainVerdict signs the response body in two headers instead of embedding a token. Paste the whole JSON body above, then these two header values.

What verification does and does not prove

A valid signature proves this service produced this exact response and it was not altered afterwards. It does not prove the answer is correct. A signed wrong answer is still wrong, and still signed. That statement ships inside every response and it is meant literally.

How it works

Two signing forms are accepted. TradeRails embeds a compact JWS at _attestation.jws; Pulse /v1/attest returns one in attestation. Ordinary Pulse verdict JSON is unsigned. For signed tokens, this page decodes its header to read the key id, fetches that service's published key from its /.well-known/signing-key.json, and verifies the Ed25519 signature using the browser's own WebCrypto — the same primitive, running on your machine, with no trust in this page beyond the code you can read with View Source.

ChainVerdict signs in headers instead: x-signature is an Ed25519 signature over the body as canonical JSON (keys sorted recursively), then |, then the x-signed-at timestamp. This page rebuilds those exact bytes from what you paste and checks them against the SPKI key ChainVerdict publishes at chainverdict.xyz/.well-known/signing-key.json.

If the key id in the token does not match the currently published key, the signature will fail even if it was valid when issued. That is the correct behaviour and it is why the keys are pinned rather than regenerated.