Load a receipt from the Hive mesh, or paste your own. Your browser checks the current payload against the pinned published Hive key. A separate mesh lookup must match that same payload, signature and ledger number. Flip the tamper switch to check a changed copy.
Insurance Studio v3 exports have a dedicated local check below. The mesh and countersigner forms accept their separate unversioned Ed25519 formats. Typed, ML-DSA and hybrid envelopes are not accepted by those forms.
Loading local verification resources. No check has run.
Verify an Insurance Studio export
Upload or paste a hive.synthetic.insurance.evidence.v3 JSON package. This check recomputes signed record digests and replays the technical evaluation locally. No package content is sent to a server.
Use synthetic records only. This does not establish source truth, coverage, actual loss, payment, independent witnessing, or organizational authority. Earlier v2 packages do not meet this contract and must be rebuilt.
A key copied from the submitted package is not a trust decision. Obtain the expected key separately from the party whose signature you intend to check. Leaving it blank permits inspection but never a trusted success.
Required verification resources are not ready. No check has run.
Verified business result
Technical verification diagnostics
Alternative receipt formats
Check a receipt
Select Load a live receipt, then Verify this receipt. You can also paste a supported receipt or enter its ledger number and select Load that number.
Tamper switch. Check a copy with one changed value. The checked payload is printed below. Turning this off checks your current input again. The signature should fail on the changed copy; a stored original is not proof for that copy.
On the Hive mesh
·Not run yet
Stored-record status is separate until its payload, signature, key and ledger number match this input.
Offline in your browser
·Not run yet
Your browser checks the current input against a pinned published key. A valid signature under an embedded key alone is not issuer trust.
Issuer key identity
·Not run yet
Pinned key comparison, separate from signature validity.
Evidence scope
Evidence completeness: not established. Trusted checkpoint: unchecked. Log history: unchecked. Independent witnessing: not established. Underlying execution: not verified. A signed model name remains an issuer assertion.
Ledger number
·
Event
·
Signed receipt hash (not recomputed)
·
Signature
·
Public key
·
Key identity
·
Current checked payload, including the test change when the tamper switch is on:
How this check works
We read an existing receipt with GET /v1/receipts/verify/{n}. The visible JSON retains numeric spelling such as 0.0, so copying it does not silently change signed bytes.
Mesh check: a returned verified: true describes a stored record. We compare its current payload bytes, signature, key and ledger number before combining it with the offline result. This is an HTTPS lookup, not a signed checkpoint.
Offline check: the current text is converted to sorted-key compact JSON with Python-compatible ASCII string escaping and unchanged numeric literals. Equivalent alternate number spellings are not guessed. Ed25519 runs using a pinned, locally bundled library with no CDN fallback. No cached payload can override your edits.
Issuer trust: the expected key was read separately from the published key endpoint on September 5, 2026 and is pinned in this verifier. The receipt cannot choose its own trusted key. Key rotation requires a reviewed pin update; this check does not establish current revocation status.
Acceptance limits: unknown envelope fields, declared versions, unsupported mandatory algorithms and critical extensions fail closed. A receipt must carry its ledger sequence inside the signed payload. Business fields inside that payload are signed assertions, not application-schema or execution validation.
Changing a signed value should fail. Editing, clearing, loading or starting another check removes the previous result and cancels stale work. After the local verification resources finish loading, pasted-receipt signature checks work in this open tab without the online services. A first visit or reload offline is not guaranteed; no offline cache or service worker is installed. Missing resources leave checking disabled.
A Hive record can carry a second Ed25519 signature from countersigner.thehiveryiq.com. Your browser checks the current signed bytes against its pinned published key, then checks field binding and BLAKE3 path consistency. Hive operates both services; independent: false.
Change one byte of the signed bytes
Countersignature, checked in your browser
·
Countersigner key identity
·
Signed bytes match signed_over and sequence
·
BLAKE3 leaf and supplied-root consistency
·
Evidence scope
Underlying record and operator signature: unchecked. Evidence completeness: not established. Trusted checkpoint and log history: unchecked. Independent witnessing: no, Hive operates both signers. Underlying execution: not verified.
Sequence
·
Record digest
·
Operator signature digest
·
Leaf
·
Supplied root (checkpoint unchecked)
·
Audit path
·
Countersigner key
·
Exact signed bytes checked by this run:
What this check does and does not cover
Your browser checks the current Ed25519 signed bytes and compares the embedded key with a pin independently read from the published health endpoint on September 5, 2026. It does not let the submitted proof choose a trusted key.
Ed25519 is not post quantum. This check does not verify the underlying record or operator signature. A signed digest or an operator-scheme label is not proof that an operator signature was authenticated.
A locally bundled, pinned BLAKE3 library recomputes the signed leaf and applies the audit path to the supplied root. That proves internal consistency only. The supplied root is outside the countersignature; a signed, independently trusted log checkpoint and log history are not checked here. An empty path alone does not establish that the log has only one entry.
Hive operates both the signer and the countersigner today, so this is a second key and a second clock, not an outside party. The service reports that itself at /health, where independent reads false.
Observed configuration on September 5, 2026: the health response reported log_dir: "/var/hive" and log_durable: true. This service declaration is not a tested recovery guarantee. Restart, crash, backup restoration, retention and continuity acceptance remain untested here.
No blockchain lookup is required for the signature check. A separately selected chain anchor can add another checkpoint, but USDC payment on Base is not itself evidence that a customer receipt was anchored.
from blake3 import blake3
def h(b, tag): return blake3(tag.encode() + b"\x00" + b).hexdigest()
cur = LEAF
for side, sib in AUDIT_PATH:
pair = (cur + sib) if side == "right" else (sib + cur)
cur = h(pair.encode(), "node")
print(cur == ROOT)
Issue your own signed receipt
Inspect the selected endpoint's receipt schema, signature algorithm and published trust key before relying on a result. A returned signature field is not proof of verified ML-DSA-65 output. See endpoint capabilities and acceptance limits.
Local verification. These forms check pasted receipt JSON in your browser. Mesh lookups send the ledger number, not the pasted payload. Loading records contacts Hive services.