Every attestation, signed and chained

Every release receipt, published proof object and conformance result is signed by the service and appended to the public verification ledger at /ledger.html. Anyone can check an entry with the service's public key: no account, no form, no vendor contact.

What is on it

An entry attests what it names: a seal existed, a proof verified, a result was produced, on the date it carries. It is not an audit opinion and not a certification. The proof format is written out on the proof object page, and the standard behind it on the Verify Standard.

The public key

The ledger

Reading the ledger from the service.

Verify a proof object

Paste a signed proof object. The service answers five checks and stores nothing: the schema of the proof object, its integrity hash, the key it names, the signature, and its date.

How a decision packet becomes a proof

The decision packet you can download from the discrepancy session and the cash flow simulator is a demonstration object, made in your browser from the page's own state and labeled DEMO. It is not signed. In a workspace the same steps run on real records:

1. A person decides. The decision and who made it are the organization's record.
2. The record is signed. An owner, an admin or a controller asks the service to sign it (POST /proofs/emit). The service hashes the record as it holds it and signs the hash, with the organization, the kind and the record id inside the signed text.
3. A proof object results. It carries the claim, its input (the record's hash), its method, what disagreed (contradictedBy), what is unresolved and what it does not claim. It sits in the organization's private ledger, and the organization hands it to whoever needs it.
4. Anyone checks it. With the proof and the public key, in the box above or offline. A change to any field breaks the hash, and a change to the organization or the record id breaks the signature.

A proof appears on this public ledger only when the operator publishes it, and only a proof that verifies is accepted. An organization's other records are never on it.

From the command line

The same checks run offline, with no account and no secret, from a checkout of the service (the command ships with the service source, given with diligence access). One line per check; the exit code is 0 only when every check passes.

eos-verify proof proof.json --keys keys.json
eos-verify receipt integrity.json ./site
eos-verify ledger https://snx-api-yzwoeh2uha-uc.a.run.app

The rules, so you can check without our code

The integrity hash is the SHA-256 of the proof object's canonical JSON: keys sorted at every level, the integritySha256 field left out at every level, and the top-level signature block left out. The signature is Ed25519 over the text eos-proof/v1, a line feed, then the JSON array of the proof's context organization, kind and record id and its integrity hash. The key id is the first 16 hex characters of the SHA-256 of the raw 32-byte public key. A ledger entry's chain hash is the SHA-256 of the JSON object of its sequence number, the ledger name, the previous entry's hash and the entry, and the first entry follows GENESIS.

One proof layer, two surfaces

This site is the private control plane: an organization signs and keeps its own proofs here. The consumer estate is the public trust plane: its release receipts are the public attestations of this same ledger. The estate's verification page shows them. A receipt hash can also be anchored on a chain, hashes only and never data, as the Verify Standard states.