Receipt verifier

Verify a real Hive receipt yourself

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.

Signing key did:hive:governance · Algorithm Ed25519 (RFC 8032)

Supported here: the unversioned mesh signed_payload response and the unversioned countersigner inclusion response. Ed25519 only; the latter also checks BLAKE3 path consistency. Typed, ML-DSA and hybrid envelopes are not accepted by these two forms.

Loading local verification resources. No check has run.

Check a receipt

New here? Just press Load a live receipt, then Verify. It pulls one real signed receipt off the ledger and checks it. You can also paste a receipt, or type a ledger 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.

How this check works

Published key: /v1/receipts/pubkey · DID document: did:hive

Check a countersignature

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

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.