Check a record. No account, no chain.
Paste a record or upload a file. Verification runs against the issuer's published key: it confirms the signature, decodes the claims, and tells you exactly what passed and what it does not prove. Nothing is stored.
- Signature
- valid (Ed25519)
- Issuer
- https://api.vendor.example
- Key
- kid 2026-06-key1 - from /.well-known/jwks.json
- Action
- tools.call search_docs
- Policy
- terms:v3 - sha256:81af2c...
- Result
- allowed - 200 - sha256:9a3c1d...
- Time
- 2026-06-12T14:08:11Z
Verification runs in your browser or via the CLI. Records you paste are never sent to a server or stored.
Don't have a record yet? Verify one of ours.
pnpm dlx @peac/cli samples generate -o ./s pnpm dlx @peac/cli verify ./s/valid/basic-record.jws --public-key ./s/bundles/sandbox-jwks.json
A green check is a precise claim.
A valid result means
- The issuer signed these exact claims.
- The record was not changed after signing.
- The signing key resolves to the issuer's published keys.
- Any bound digest matches the content it covers.
It still does not mean
- That the issuer told the truth.
- That the policy was correct or legally sufficient.
- That you have seen the full payload.
- That every related event was shared.
Three ways to verify. Different network rules.
| How | Network | What it does |
|---|---|---|
| verify --public-key | none | You supply the key. The signature is checked entirely offline. No fetch, no callback. |
| verify (default) | may resolve key | Resolves the issuer's published key from its well-known config, then verifies. URL fields are locator hints only; nothing else is fetched. |
| this hosted page | explicit only | Runs in your browser. It only acts on what you paste or upload. Records are not sent to a server or stored. |
What the verifier checks.
Current release: PEAC v0.16.2. These checks compose; the wire format (0.2) and public schema are unchanged.
Verify a record with only the issuer's public key. The signature is checked entirely offline: no fetch, no callback, no account.
Signatures use Ed25519 (RFC 8032) over compact JWS (RFC 7515), checked with a shared small-order denylist. Runtimes without stable Ed25519 fail closed rather than guess.
The JWS header and payload are validated as I-JSON (RFC 7493) before parsing. Duplicate member names, out-of-range numbers, and invalid strings are rejected, so two verifiers read the same bytes the same way.
A bounded, opt-in guard classifies an already-verified record as fresh, replayed, or outside its acceptance window. Composable; it is not wired into stateless verification.
For request-shaped flows, Originary composes with RFC 9421 HTTP Message Signatures and RFC 9530 content digests computed over the raw body bytes.
A Merkle-style set commitment over a batch of records lets a verifier check inclusion: confirm a record belongs to a published, sealed run without re-checking every other record in the set. A missing record becomes detectable too.