Verifiable Credentials Beyond Blockchain
74 Bytes. Three PQ Families. No Chain Required.

The Blockchain Assumption in Verifiable Credentials

The W3C Verifiable Credentials specification (VC Data Model 2.0) defines a credential as a set of claims made by an issuer about a subject, accompanied by a proof that makes the credential tamper-evident and verifiable. The specification is deliberately agnostic about how the proof is implemented. You can use JSON Web Signatures, Linked Data Proofs, or any other mechanism that satisfies the tamper-evidence requirement.

Despite this agnosticism, the verifiable credentials ecosystem has developed a strong gravitational pull toward blockchain. Decentralized Identifiers (DIDs) are typically anchored on a distributed ledger. Credential status (revocation) registries are often implemented as smart contracts. The entire trust model assumes that the verifier can consult a decentralized consensus mechanism to confirm the credential's validity.

This assumption introduces significant practical problems. Blockchain-based credential verification requires network connectivity at verification time. It introduces latency (block confirmation times). It creates privacy concerns (on-chain queries can reveal what credentials are being checked). And it ties the credential's verifiability to the continued operation of a specific blockchain network, which may not exist in 10, 20, or 50 years.

H33-74 takes a fundamentally different approach. Instead of outsourcing trust to a consensus mechanism, it embeds trust directly into the credential through pure cryptographic construction. The result is a 74-byte attestation that is verifiable by anyone with the open-source verifier, at any time, without network connectivity, and without consulting any external system.

What Is Cryptographic Distillation?

The term "distillation" is deliberate and important. H33-74 does not compress credentials. Compression implies reversibility: you take a large object, make it smaller, and can expand it back to the original. Distillation is a different operation. It takes a complex, multi-component cryptographic attestation and produces a new, smaller artifact that independently proves the original computation was correct.

Think of it like distilling spirits. You start with a mash of ingredients (in our case, three post-quantum signature families, a STARK proof reference, and a timestamp). The distillation process extracts the essence—the essential cryptographic properties—into a concentrated form. The original mash is no longer recoverable from the distillate, but the distillate contains all the proof you need that the original existed and was correct.

In concrete terms, H33-74 works as follows. The full attestation from the H33 pipeline includes a Dilithium (ML-DSA) signature, a FALCON signature, a SPHINCS+ (SLH-DSA) signature, a STARK proof digest, and a timestamp. The combined size of these components is approximately 21,000 bytes. The distillation process computes a SHA3-256 hash chain over all components, producing a 32-byte on-chain anchor and a 42-byte Cachee-stored expansion that includes the component references and verification metadata. The 74-byte result is 285 times smaller than the full attestation but retains full verifiability because the verifier can reconstruct the hash chain and confirm that it matches the original components.

Three Independent Hardness Assumptions

The security of H33-74 rests on three independent mathematical hardness assumptions, each implemented through a different post-quantum signature family.

The first assumption is the hardness of the Module Learning With Errors (MLWE) problem, implemented through ML-DSA (formerly Dilithium). This is a lattice-based assumption: breaking it requires solving a problem in high-dimensional lattice geometry that is believed to be hard for both classical and quantum computers.

The second assumption is the hardness of the NTRU lattice problem, implemented through FALCON. While both ML-DSA and FALCON are lattice-based, they rely on different mathematical structures. FALCON uses NTRU lattices with a distinct algebraic structure from the module lattices in ML-DSA. A breakthrough in one does not automatically transfer to the other.

The third assumption is the hardness of finding collisions in stateless hash functions, implemented through SLH-DSA (formerly SPHINCS+). This is the most conservative assumption of the three: it reduces to the collision resistance of SHA-256, which has been studied for decades and is not known to be vulnerable to any quantum algorithm beyond Grover's generic speedup.

An H33-74 attestation is invalid only if all three assumptions are simultaneously broken. An attacker would need to solve MLWE lattice problems, NTRU lattice problems, and find hash function collisions—three independent mathematical bets that span fundamentally different areas of computational complexity theory. No single cryptographic advance can compromise the system.

Why Not Just Use a Blockchain?

Blockchains solve a specific problem: achieving consensus among mutually distrustful parties about the ordering of transactions. This is valuable when you need to prevent double-spending of digital assets or maintain a globally consistent state. But verifiable credentials do not require global consensus. They require tamper-evidence and verifiability, which are pure cryptographic properties.

Consider what happens when you anchor a credential on a blockchain. The credential issuer publishes a transaction containing the credential hash. A verifier who wants to check the credential must query the blockchain to confirm the transaction exists. This introduces several dependencies:

Network dependency. The verifier needs network access to query the chain. An airplane passenger, a field medic in a disaster zone, or an IoT device in a remote facility cannot verify blockchain-anchored credentials offline.

Chain dependency. The credential's verifiability is coupled to the continued operation of a specific blockchain. If the chain shuts down, forks, or migrates, the credential's anchor may become inaccessible. Credentials are supposed to last for years or decades. Most blockchain networks are younger than the credentials they host.

Privacy leakage. Querying a blockchain for a specific credential hash reveals to network observers that someone is checking that credential. Depending on the chain's design, this can leak information about when and where credentials are being verified.

Cost. Writing to a blockchain requires paying transaction fees. At scale, the cost of anchoring millions of credentials per day on a public chain becomes significant. Private or consortium chains reduce fees but reintroduce centralized trust assumptions.

Latency. Block confirmation adds seconds to minutes of latency to credential issuance. For real-time authentication scenarios (processing over a million authentications per second), blockchain anchoring would be a catastrophic bottleneck.

H33-74 eliminates all five dependencies. The attestation is self-contained: the 74 bytes include everything needed for verification. The verifier does not need network access, does not need to query any external system, and does not reveal what it is verifying. Issuance takes 26 milliseconds (dominated by the SPHINCS+ signature), not minutes. And the cost is a function of compute time, not blockchain gas fees.

The 74-Byte Anatomy

The 74-byte H33-74 attestation is split into two segments. The first 32 bytes form the on-chain anchor (optional—used when an organization wants the additional assurance of blockchain anchoring). The remaining 42 bytes are stored in Cachee, H33's distributed caching layer.

The 32-byte anchor is a SHA3-256 hash of the full attestation bundle. This hash commits to all three signatures, the STARK proof reference, and the timestamp. Because SHA3-256 is collision-resistant, the anchor uniquely identifies the attestation. If any component of the original attestation is modified, the anchor will not match.

The 42-byte Cachee segment contains: a 4-byte version identifier, an 8-byte Unix timestamp, a 16-byte STARK proof reference (a truncated hash that can be used to retrieve the full proof from the Cachee network), a 6-byte signature family bitmap (indicating which PQ families were used), and an 8-byte checksum that cross-references the on-chain anchor.

Together, these 74 bytes allow a verifier to confirm: (1) that the attestation was produced by the H33 pipeline, (2) when it was produced, (3) which signature families were used, and (4) that the underlying STARK proof exists and is retrievable. If the verifier has the open-source verifier tool, they can independently reconstruct the hash chain and confirm the attestation's validity without any external calls.

Offline Verification

The most powerful consequence of self-contained attestations is offline verification. A verifier who has previously downloaded the H33 open-source verifier can verify any H33-74 attestation without network connectivity. This is because the verification algorithm is purely computational: it takes the 74 bytes as input, performs a deterministic sequence of hash operations, and outputs a boolean (valid or invalid).

This property is critical for several real-world scenarios. Healthcare workers in disaster zones need to verify patient identity credentials without reliable internet. Military and government applications require air-gapped verification capability. Financial institutions need to verify credentials even when their network connections to third-party systems are disrupted. IoT devices in industrial environments may have limited or intermittent connectivity.

In all these cases, blockchain-based verifiable credentials fail because they require network access to query the ledger. H33-74 succeeds because the attestation carries its own proof.

Credential Revocation Without a Ledger

One legitimate use case for blockchain in verifiable credentials is revocation. If a credential needs to be revoked (an employee leaves a company, a certificate expires, a license is suspended), there needs to be a way for verifiers to learn about the revocation. Blockchain-based revocation registries solve this by publishing revocation transactions.

H33 handles revocation through Cachee, which maintains a distributed revocation list. When a credential is revoked, the corresponding entry in Cachee is flagged. Verifiers who are online can check Cachee for revocation status. Verifiers who are offline can still verify the cryptographic validity of the attestation but will not have real-time revocation information.

This is the same trade-off that exists with CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol) in the TLS ecosystem. Offline verification confirms the credential was validly issued; online verification additionally confirms it has not been revoked. H33-74 supports both modes, while blockchain-based credentials support only online verification.

Integration With Existing Standards

H33-74 is designed to work within the existing W3C Verifiable Credentials ecosystem. An H33-74 attestation can be embedded as the proof in a standard VC JSON document. The issuer, subject, and claims follow the standard VC data model. Only the proof mechanism differs: instead of a JSON Web Signature or a blockchain-anchored proof, the proof is a 74-byte H33-74 attestation.

This means organizations can adopt H33-74 without abandoning their existing credential infrastructure. Existing VC wallets that support custom proof types can store and present H33-74 credentials. Existing issuance workflows need only swap the proof generation step. And because H33-74 is backward-compatible with blockchain anchoring (the 32-byte anchor can optionally be written to a chain), organizations that want belt-and-suspenders can use both mechanisms simultaneously.

The Distillation Ratio

H33-74 achieves a 285x distillation ratio: 21,000 bytes of full attestation (three PQ signatures plus STARK proof) are distilled into 74 bytes. This ratio is not achieved through lossy compression or information discard. It is achieved through cryptographic commitment: the hash chain commits to all the original components without encoding them in full.

The distillation ratio matters for storage, bandwidth, and embedded systems. A device with limited storage (a smart card, an NFC tag, a QR code) can store an H33-74 attestation but cannot store a full Dilithium signature (3,293 bytes) plus a FALCON signature (1,281 bytes) plus a SPHINCS+ signature (17,088 bytes). The 74-byte format makes post-quantum verifiable credentials practical in constrained environments where they would otherwise be impossible.

Post-Quantum Durability

Credentials need to outlast the cryptographic algorithms that produced them. A professional license issued today might need to be verified in 2040. An educational credential might need to be verified in 2050. A birth certificate might need to be verified in 2090.

Classical digital signatures (RSA, ECDSA, Ed25519) will not survive the quantum era. A credential signed with ECDSA today could be forged by a quantum computer in the future, making the credential worthless. This is the "harvest now, decrypt later" threat applied to credentials: an adversary can store credentials today and forge them later when quantum computers mature.

H33-74 is designed for post-quantum durability. The three signature families (ML-DSA, FALCON, SLH-DSA) are all NIST-standardized post-quantum algorithms. The hash function (SHA3-256) is quantum-resistant. The attestation remains valid as long as at least one of the three hardness assumptions holds, which provides a much wider margin of safety than any single-algorithm approach.

Furthermore, if a new post-quantum algorithm is standardized in the future, H33's crypto-agile architecture allows the signature families to be updated without changing the attestation format. The 74-byte structure is algorithm-agnostic: it commits to whatever signatures the pipeline produces, regardless of which specific algorithms are used. This means H33-74 credentials issued today will remain verifiable even if the underlying algorithms are upgraded in the future.

Real-World Applications

H33-74 verifiable credentials are already being used in several production scenarios.

Authentication attestation. Every authentication processed by the H33 pipeline produces an H33-74 attestation that proves the authentication was computed correctly. This creates an auditable trail of authentications that can be independently verified by any third party.

Document signing. The ArchiveSign product uses H33-74 to create tamper-evident signatures on documents that are verifiable for decades, regardless of which blockchain networks exist in the future.

Device identity. The DeviceProof product issues H33-74 credentials to IoT devices, allowing them to prove their identity to other devices or services without relying on a centralized authority or a blockchain.

AI compliance. H33's AI Compliance product uses H33-74 to attest that AI model outputs were produced by a specific model version with specific safety constraints, creating verifiable provenance for AI-generated content.

Conclusion

Verifiable credentials do not require a blockchain. They require cryptographic tamper-evidence and independent verifiability, both of which can be achieved through pure cryptographic construction. H33-74 demonstrates this: 74 bytes, three independent post-quantum hardness assumptions, a 285x distillation ratio, and verification that works offline, without network access, without consulting any external system.

The blockchain was a useful forcing function that made people think about decentralized trust. But the end goal was never "put everything on a chain." The end goal was verifiable credentials that anyone can check, anywhere, forever. H33-74 delivers that goal with less complexity, less cost, and stronger post-quantum security than any blockchain-based approach.