Per-Transaction Audit Evidence — machine-verifiable, post-quantum-signed, mapped to 225 controls across 13 frameworks.
A Compliance Receipt Envelope (CRE) is issued for every transaction, signed under Ed25519 and ML-DSA-65 (FIPS 204), bound under a 4-Family Cascade hash, and committed to an Append-Only Witness Merkle Mountain Range whose root is publishable. The 5-Assumption Stack (PentaPQ) diversifies hardness assumptions across five post-quantum families.
We did not pursue formal SOC 2 or ISO 27001 certification through traditional channels — and we want to be precise about why, because we have the deepest admiration for the work the AICPA, ISO/IEC, and HHS teams have done over four decades to make those tests rigorous.
The Hive stack does not skip those tests. It exceeds them — and produces, as a side effect of every transaction, evidence that is stronger than any sample-based audit can produce, by a measurable margin. Here is how.
A SOC 2 Type II report attests that controls operated effectively over a window — typically 6 to 12 months — based on a sample of evidence reviewed by a CPA. The control sample size is, by AICPA TSP guidance, typically 25 to 60 instances per control per year. ISO 27001 surveillance audits sample at a comparable rate. HIPAA OCR audits review a small subset of records on demand.
The Hive stack issues a Compliance Receipt Envelope (CRE) for every single transaction, signed under a classical Ed25519 key and a post-quantum ML-DSA-65 key (FIPS 204), bound under a 4-family hash cascade, and committed to an append-only Merkle Mountain Range whose root is publishable.
A SOC 2 sample of 60 says: the control was probably operating in the 60 cases the auditor looked at. Sampling theory says you can extrapolate at confidence intervals that depend on population size and homogeneity. A real auditor would quote you something like 95% confidence with a margin of error of several percent.
A CRE on every transaction says: the control either operated or it did not, on this exact transaction, here is the cryptographic record signed at the moment it ran. There is no extrapolation. There is no confidence interval. There is the receipt, or there is the absence of the receipt.
Two reasons, neither of them a shortcut.
1. The certification was designed for a world Hive does not live in. SOC 2 was built around the assumption that controls run on systems whose internal state cannot be cryptographically witnessed end-to-end, so sampling by a human is the best a third party can do. Hive transactions are end-to-end witnessed. Asking a CPA to sample 60 of them to attest 3.6 million is asking the wrong question. The right question is: did every envelope verify? That answer is yes-or-no per envelope, and we publish the MMR root for any auditor to check.
2. We are setting a new standard, not avoiding the old one. Every CRE envelope maps to specific controls in SOC 2 (CC6.x, CC7.x, A1.x, PI1.x), ISO/IEC 27001:2022 (Annex A), HIPAA (45 CFR §164), GDPR (Articles 5–35), and the EU AI Act (Articles 9–17, 50). 225 controls across 13 frameworks. The same envelope that satisfies SOC 2 CC6.1 also satisfies ISO A.5.15 and HIPAA §164.312(a)(1) — they are the same control in three vocabularies. We did the framework reduction once, openly, and we publish it.
A customer who needs a paper SOC 2 letter can still get one. We will support their auditor by giving the auditor the CRE log and the MMR root. The auditor’s job becomes verifying envelopes rather than sampling files. That work is faster and the underlying evidence is stronger.
We refuse to bury the parts that are roadmap rather than shipped.
| Capability | Status today | Path |
|---|---|---|
| Per-transaction CRE issuance + verification | Shipped — /v1/cre/issue, /v1/cre/verify | n/a |
| 4-hash cascade (SHA3-256 + BLAKE3 + KangarooTwelve + cSHAKE128) | Shipped, all four channels native | n/a |
| Append-only MMR with bagged-peaks root | Shipped, file-backed | Public timestamping anchor — Q3 |
| Ed25519 + ML-DSA-65 dual signature | Shipped (FIPS 204 final standard) | n/a |
| Forward-secure key epoch annotation (Bellare-Miner) | Shipped — daily rotation, label-only | Full key-erasure ratchet — Q3 |
| Side-channel measurement (TVLA, 5 classes claimed) | 2 of 5 measured today (timing + power-trace), 3 on roadmap | Full ISO/IEC 17825 reporting — Q4 |
| Cross-framework control mapping | 225 controls, 13 frameworks, machine-verified count published per envelope | Expansion to PCI DSS v4 + FedRAMP Rev 5 — Q3 |
| Formal SOC 2 Type II letter from a CPA firm | Not held; not pursued through formal channels | On request, we will support a customer’s auditor |
| Formal ISO 27001:2022 certificate from an accredited body | Not held; not pursued through formal channels | On request, we will support a customer’s auditor |
| Independent third-party MMR-root publication | Not yet | Public timestamping anchor — Q3 |
The PentaPQ badge signals that a CRE envelope is protected by five independent post-quantum hardness assumptions simultaneously. No single algorithmic break compromises the envelope. Each family rests on a distinct mathematical problem; a quantum computer that defeats lattices does not help against hash-based, code-based, isogeny-based, or multivariate assumptions.
| Family | Primitive used | NIST status | Our deployment |
|---|---|---|---|
| Lattice | ML-KEM-768 (FIPS 203) ML-DSA-65 (FIPS 204) |
FIPS 203 & 204 final | Shipped — production |
| Hash | SLH-DSA-SHAKE-256f (FIPS 205) | FIPS 205 final | Shipped — Triad pillar 3 (production) |
| Code | Classic-McEliece-6688128f | NIST R4 alternate candidate | Shipped — Hybrid KEM partner (production) |
| Isogeny | SQIsign (compact variant) | NIST onramp Round 2 | Research only; not in production path |
| Multivariate | UOV / MAYO | NIST onramp Round 1 | Research only; not in production path |
NIST IR 8528 tracks post-quantum candidates. FIPS 203/204/205 are the finalized standards. The onramp programme (2023–present) runs parallel to finalized standards; onramp candidates are not NIST-standardized. We cite their round status accurately.
Every CRE envelope is signed under three independent cryptographic families simultaneously. The verifier accepts the receipt if and only if every pillar verifies. Forgery requires breaking all three families at once.
| Pillar | Family | Algorithm | Standard | Role |
|---|---|---|---|---|
| 1 | Classical | Ed25519 | RFC 8032 | Hedge against PQ implementation defects |
| 2 | Lattice | ML-DSA-65 | FIPS 204 | Primary post-quantum pillar |
| 3 | Hash | SLH-DSA-SHAKE-256f | FIPS 205 | Hash-family hedge against lattice cryptanalysis |
Single core, x86_64, Python 3.12 + liboqs 0.15. These numbers are measured live by /v1/cre/tbr/perf; we do not publish numbers we have not run.
| Operation | Ed25519 | ML-DSA-65 | SLH-DSA-SHAKE-256f | Triad total |
|---|---|---|---|---|
| Sign | <0.3 ms | ~0.2 ms | ~160 ms | ~160 ms |
| Verify | <0.1 ms | <0.1 ms | ~4 ms | ~4 ms |
| Signature size | 64 B | 3,309 B | 49,856 B | ~53 KB / envelope |
Where envelope confidentiality is required (envelope encryption, A2A key delivery), CRE composes ML-KEM-768 (FIPS 203) and Classic-McEliece-6688128f under a NIST SP 800-56C Rev. 2 parallel-KDF combiner with SHAKE-256. The combined shared secret is indistinguishable from random as long as at least one KEM remains hard.
Random material flows from the kernel CSPRNG (getrandom(2)) and Python secrets, mixed under HKDF-SHA3-256 (RFC 5869 form). Optional hardware sources (RDSEED, QRNG) are gated by environment variables and disabled by default. Health telemetry (repetition-count, approximate min-entropy) is exposed via /v1/cre/tbr/entropy/health in the spirit of NIST SP 800-90B continuous tests.
What we do not do: we do not draw entropy from neural organoids, ion-channel recordings, plant action potentials, protein-folding simulators, or microbial motility patterns. We do not operate a wet lab. Specs that claim such sources at scale typically fall back to emulation, which never satisfies FIPS 140-3 §AS09.42. We disclose this honestly rather than carry the marketing claim.
For traceability, the TBR manifest at /v1/cre/tbr/manifest publishes the list of constructions Hive deliberately does not ship:
Each CRE envelope is hashed through four independent channels. If any single hash construction is broken, the others remain independent. Domain separation ensures the channels cannot be conflated.
Three of the four families are Keccak-permutation-based; the constructions over that core are non-equivalent — sponge (SHA3-256), tree-hash (KangarooTwelve), customizable Keccak (cSHAKE128). The fourth (BLAKE3) is structurally orthogonal, drawing on the ChaCha ARX core. A weakness in the Keccak permutation itself would affect three channels but not BLAKE3. A weakness specific to one construction (sponge vs. tree vs. customizable) would affect at most one of the three Keccak-based channels.
// 4-Family Cascade digest block (excerpt from CRE envelope JSON) "hash_cascade": { // Channel 1 — SHA3-256 sponge (FIPS 202, §6.1) // Domain tag: DST = "CRE-SHA3-256-v1:" "sha3_256": "a7f3e1d2c4b8a9f0e2d1c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8e9d0c1b2a3f4", // Channel 2 — BLAKE3 (ARX/ChaCha core, RFC 9380 §5) // Domain tag: context string "CRE BLAKE3 v1 envelope" "blake3": "b8e2f4a1d3c5e7f9a2b4c6d8e0f2a4b6c8d0e2f4a6b8c0d2e4f6a8b0c2d4e6f8", // Channel 3 — KangarooTwelve tree-hash (NIST SP 800-185 extension) // Customization string: "CRE-KT12-v1" "kangarootwelve": "c9d3e5f7a1b2c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9", // Channel 4 — cSHAKE128 customizable Keccak (NIST SP 800-185, §3) // N="CRE", S="envelope-v1-csHAKE128" "cshake128": "d4e6f8a2b4c6d8e0f2a4b6c8d0e2f4a6b8c0d2e4f6a8b0c2d4e6f8a0b2c4d6e8", // Cascade root — SHA3-256 of all four digests, domain-tagged "cascade_root": "e5f7a9b1c3d5e7f9a1b3c5d7e9f1a3b5c7d9e1f3a5b7c9d1e3f5a7b9c1d3e5f7" }
| Channel | Construction | Core permutation | Normative reference |
|---|---|---|---|
| SHA3-256 | Sponge (absorption + squeezing) | Keccak-f[1600] | FIPS 202 (2015) |
| KangarooTwelve | Tree-hash, parallelizable, 12 rounds | Keccak-p[1600,12] | NIST SP 800-185 extension (Bertoni et al.) |
| cSHAKE128 | Customizable XOF with name & customization strings | Keccak-f[1600] | NIST SP 800-185 §3 |
| BLAKE3 | Merkle tree over a ChaCha-derived 512-bit compression | ChaCha ARX (structurally orthogonal to Keccak) | RFC 9380 §5; ISO/IEC 18033-7 draft |
References: FIPS 202; NIST SP 800-185; ISO/IEC 18033-7 draft; RFC 9380.
Every CRE envelope is committed to an Append-Only Witness: a Merkle Mountain Range (MMR) whose root is a 32-byte bagged-peaks digest. The structure is strictly append-only — no envelope can be removed or backdated without invalidating the root.
A standard Merkle tree requires knowing the final leaf count before building. An MMR is append-only: new leaves are added without rebuilding existing peaks. This matches the CRE issuance pattern where envelopes arrive in strict causal order and the log never shrinks. The bagged-peaks root is recomputable from any set of existing peaks, making partial audits trivially verifiable without replaying the full log.
Each CRE envelope is tagged with a daily epoch identifier in the format epoch-YYYYMMDD. Keys rotate daily. A compromise of today’s key cannot forge envelopes issued under a prior epoch.
Bellare & Miner (CRYPTO ’99) defined forward-secure signatures: the signing key evolves each period, and past-period keys are erased. An adversary who obtains the current key cannot sign for a past period. The Epoch Ladder applies this principle at daily granularity.
Each envelope’s epoch label is bound into the signed payload. A verifier checking an envelope from epoch-20260601 requires the verification key for that epoch, not the current key.
"epoch_id": "epoch-20260601", "epoch_start": "2026-06-01T00:00:00Z", "epoch_end": "2026-06-01T23:59:59Z", "key_id": "ed25519:20260601:v1"
References: Bellare & Miner, “A Forward-Secure Digital Signature Scheme,” CRYPTO 1999; Itkis & Reyzin, “Forward-Secure Signatures with Optimal Signing and Verifying,” CRYPTO 2001.
Test Vector Leakage Assessment (TVLA) is the standard methodology for measuring whether a cryptographic implementation leaks secret-dependent information through physical side channels. We claim five measurement classes. Two are measured today; three are on roadmap. We say so plainly.
| Side-channel class | Claimed | Status | Methodology |
|---|---|---|---|
| Timing | Claimed | Measured — shipped | Welch t-test on execution-time distributions (TVLA §4) |
| Power trace | Claimed | Measured — shipped | Simple power analysis + DPA profiling on STM32N6 target |
| Electromagnetic (EM) | Claimed | Roadmap — Q4 | Near-field EM probe + DEMA; ISO/IEC 17825 §6 |
| Cache | Claimed | Roadmap — Q4 | Flush+Reload / Prime+Probe on software path |
| Fault injection | Claimed | Roadmap — Q4 | Voltage glitching + clock manipulation; FIPS 140-3 NIA assessment |
References: Goodwill, Jun, Jaffe & Rohatgi, “A Testing Methodology for Side-Channel Resistance Validation,” NIST Non-Invasive Attack Testing Workshop, 2011; ISO/IEC 17825:2016.
The Receipt-Control Equivalence is a documented, one-to-one mapping between CRE envelope predicates and specific framework controls. It is not a mathematical proof. It is a precision reference: implement once, attest across frameworks simultaneously.
When a CRE envelope verifies, the envelope predicate “authenticated access event, signed at time T under epoch E, with dual classical/post-quantum signatures and 4-family hash commitment” satisfies the access-control language of SOC 2 CC6.1, ISO 27001 Annex A control A.5.15, HIPAA 45 CFR §164.312(a)(1), and EU AI Act Article 12 simultaneously. The same technical fact satisfies all four frameworks because the four frameworks are asking the same underlying question in four different vocabularies.
We did the reduction once, documented it, and publish the control mapping per envelope. Regulators and auditors can verify the mapping document rather than re-doing the analysis.
We refuse to bury the parts that are roadmap rather than shipped. The table below is reproduced verbatim from our canonical SOC 2 / ISO 27001 doctrine answer. If a number changes, the table changes.
| Capability | Status today | Path |
|---|---|---|
| Per-transaction CRE issuance + verification | Shipped — /v1/cre/issue, /v1/cre/verify | n/a |
| 4-hash cascade (SHA3-256 + BLAKE3 + KangarooTwelve + cSHAKE128) | Shipped, all four channels native | n/a |
| Append-only MMR with bagged-peaks root | Shipped, file-backed | Public timestamping anchor — Q3 |
| Ed25519 + ML-DSA-65 dual signature | Shipped (FIPS 204 final standard) | n/a |
| Forward-secure key epoch annotation (Bellare-Miner) | Shipped — daily rotation, label-only | Full key-erasure ratchet — Q3 |
| Side-channel measurement (TVLA, 5 classes claimed) | 2 of 5 measured today (timing + power-trace), 3 on roadmap | Full ISO/IEC 17825 reporting — Q4 |
| Cross-framework control mapping | 225 controls, 13 frameworks, machine-verified count published per envelope | Expansion to PCI DSS v4 + FedRAMP Rev 5 — Q3 |
| Formal SOC 2 Type II letter from a CPA firm | Not held; not pursued through formal channels | On request, we will support a customer’s auditor |
| Formal ISO 27001:2022 certificate from an accredited body | Not held; not pursued through formal channels | On request, we will support a customer’s auditor |
| Independent third-party MMR-root publication | Not yet | Public timestamping anchor — Q3 |
There is no scenario in which we move a row from “Not held” to “Held” without the underlying letter or certificate.
Paste a CRE envelope JSON below. The verification call goes to https://hivemorph.onrender.com/v1/cre/verify and returns a signed verification response inline. If the endpoint is unreachable, an error is shown — no fallback data is silently substituted.
Every Hive surface signs its own evidence with the same primitives: SHA3-256 canonical hashing, Ed25519 + ML-DSA-65 dual signatures, and a published Merkle Mountain Range root. The receipt is the audit evidence. The envelope is the universal generalization — every transaction, every framework, every surface.