Receipt integrity
Whether the signed receipt bytes still match the signatures and digests retained with the record.
Receipt verification continuity
Keep the evidence. Keep the ability to check it.
A receipt can be checked later only when the required receipt bytes, verifier, trusted keys, and any required checkpoint are retained together. The downloadable sample below demonstrates one Ed25519 signature check. It is not an accepted continuity or restore result.
What remains checkable
The exact checks depend on the receipt profile and the materials retained with it. The current sample recomputes canonical bytes and verifies one Ed25519 signature against the bundled public key. It does not include a witness proof or establish an independent trust path for that key.
Key relationship
Whether the signatures validate against the public-key material identified by the receipt profile.
Witness inclusion
Whether the retained inclusion proof resolves to the retained witness checkpoint or root.
Later mismatch
Whether content presented later produces a different digest from the one bound into the receipt.
Download the retained sample
Hive Ed25519 Sample Bundle v0.1 includes receipt 25236, a deliberately altered negative fixture, the supplied public key, a no-network Python verifier, expected results, a manifest, and SHA-256 checksums.
This is a retained Hive sample. It is not WEX data, WEX integration, WEX acceptance, production certification, witness independence, or deployed ML-DSA support.
The continuity package
Receipt envelope and payload profile
The canonical receipt, schema version, digest algorithm, signature algorithm identifiers, and any disclosure rules needed to reproduce the check.
Public keys and key history
The applicable public keys, key identifiers, validity metadata, and a retained snapshot of the key material referenced by the receipt.
Witness proof and checkpoint
The inclusion proof, checkpoint or root, and enough history to verify the receipt against the checkpoint retained by the customer or another agreed custodian.
Offline verifier and instructions
Versioned verifier source or binary, verification instructions, test vectors, and a manifest that lets a reviewer check the package itself.
Export manifest
A machine-readable inventory of the package, its versions, hashes, and any dependencies required for long-term re-verification.
Who retains what
Customer or record holder
Retains the receipt, disclosed content needed for the check, the continuity package, and any checkpoint it intends to rely on.
Hive deployment
Publishes the verifier materials and key/checkpoint data promised by the applicable receipt profile and service agreement.
Optional outside custodian
Escrow, alternate hosting, mirrored checkpoints, or third-party custody can be added by contract. They are not implied by a public receipt alone.
Authorized reviewer
Uses the retained package to run the check without needing access to the original operating system or a live Hive account.
The boundary
A valid receipt is evidence of a recorded event, not a verdict about the event.
Verification can show that the retained receipt is internally consistent with the signatures, digests, and checkpoints actually included in the selected profile. It does not establish that the underlying action was correct, lawful, authorized in the legal sense, delivered, accepted, or settled.
Blockchain anchoring is not required to create or verify the standard evidence package. If a customer separately selects an external chain anchor, the applicable order form and receipt profile must identify what commitment is written, where it is written, and how it is checked. Paying Hive in USDC on Base records the payment; it does not by itself anchor the customer’s evidence.
Retention periods, escrow, alternate hosting, migration support, restore testing, and service levels are deployment terms. No accepted continuity, restore, or outside-custody result is claimed on this page.