The H33 Attestation API produces post-quantum signed evidence for authentication, governance, privacy proofs, and AI agent actions.
An attestation is a post-quantum signed proof that a computation happened. It records what was computed, who computed it, when, under what authority, and under which policy — all cryptographically bound and independently verifiable.
Three ways to integrate attestation into your workflow. All produce identical attestation output.
| Method | Best For | Format |
|---|---|---|
| REST API | Backend services, microservices, serverless | POST /api/v1/substrate/attest |
| Rust SDK | High-performance, embedded attestation | h33::attest() |
| CLI | CI/CD pipelines, scripts, testing | h33 attest --input data.json |
Every attestation produces exactly 74 bytes. The first 32 bytes are a commitment hash anchorable on any blockchain. The remaining 42 bytes contain attestation metadata cached in Cachee for retrieval and verification.
| Component | Size | Location | Purpose |
|---|---|---|---|
| Commitment Hash | 32 bytes | On-chain | Anchors the attestation on Bitcoin, Solana, Ethereum, or L2s |
| Attestation Metadata | 42 bytes | Cachee | Signer ID, timestamp, policy version, signature family indicators |
Every attestation is signed with three post-quantum signature families simultaneously. An attacker must break all three to compromise a single attestation.
| Family | Algorithm | Hardness | Standard |
|---|---|---|---|
| Lattice (MLWE) | ML-DSA-65 | Module Learning With Errors | FIPS 204 |
| Lattice (NTRU) | FALCON-512 | NTRU shortest vector | NIST Round 3 |
| Hash-Based | SLH-DSA-SHA2-128f | Second preimage resistance | FIPS 205 |
Three independent mathematical bets. Security breaks only if MLWE lattices, NTRU lattices, and stateless hash functions are all simultaneously compromised.
The Attestation API works with any computation that produces a deterministic output. Common use cases include:
Every login, MFA event, and session creation produces a post-quantum signed attestation with 74-byte footprint.
Policy changes, key rotations, access grants, and compliance checks are attested with full authority context.
ZK-STARK proofs are wrapped in attestations that add who, when, authority, and policy to the mathematical proof.
Every autonomous action produces an attestation recording the delegation chain, policy state, and scope at execution time.
Token minting, transfers, and redemptions are attested with PQ signatures and anchorable on any chain.
Documents signed with ArchiveSign produce attestations that survive quantum computing advances.
Generate a post-quantum signed attestation with a single API call.
# Generate an attestation via REST API
curl -X POST https://api.h33.ai/v1/substrate/attest \
-H "Authorization: Bearer $H33_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"computation_type": "authentication",
"input_hash": "a3f8c1e9...7b2d",
"output_hash": "d4b2f8a1...9c3e"
}'
# Response: 74-byte attestation
{
"attestation_id": "h33_att_7f8d9ef2...",
"commitment": "32-byte-hex...",
"metadata": "42-byte-hex...",
"signatures": {
"ml_dsa_65": true,
"falcon_512": true,
"slh_dsa_sha2_128f": true
},
"verify_url": "https://h33.ai/verify/h33_att_7f8d9ef2..."
}
Never hardcode API keys in source code. Use environment variables ($H33_API_KEY) or a secrets manager.
One API key. 74 bytes per attestation. Three post-quantum signature families. Independently verifiable forever.
Classical digital signatures (RSA, ECDSA, EdDSA) prove that a specific key holder approved a specific message. H33 attestations prove that a specific computation occurred, who authorized it, under what policy, and when -- signed with three independent post-quantum families. The distinction matters when signatures must serve as long-term evidence in a world where quantum computers will eventually break classical algorithms.
| Dimension | Classical Digital Signatures | H33 Post-Quantum Attestation API |
|---|---|---|
| What is signed | A message or document hash. The signature proves authorship and integrity of the message content. | A computation with governance context. The attestation records the computation type, input hash, authority, policy, timestamp, and hash-chain position -- then signs the entire bundle. |
| Quantum resistance | None. RSA and ECDSA are broken by Shor's algorithm on a sufficiently powerful quantum computer. EdDSA is similarly vulnerable. | Three independent PQ families: ML-DSA-65 (FIPS 204), FALCON-512, SLH-DSA-SHA2-128f (FIPS 205). Breaks only if MLWE lattices, NTRU lattices, and stateless hash functions are simultaneously broken. |
| Signature count | One signature per operation, typically one algorithm family. | Three signatures per attestation. Every operation is signed with all three PQ families simultaneously. Resilient against the failure of any two families. |
| Governance context | None. A signature does not record who authorized the signing, under what policy, or whether it was within scope. | Full governance context. Authority, policy, scope constraints, and operational context are cryptographically bound to every attestation. |
| Chain integrity | Signatures are independent. There is no cryptographic linkage between successive signatures. | Hash-chained via SHA3-256. Every attestation is linked to its predecessor, creating a tamper-evident DAG. Gaps, modifications, and insertions are mathematically detectable. |
| Attestation size | Varies. RSA-2048: 256 bytes. ECDSA P-256: 64 bytes. No compression primitive. | 74 bytes via the H33-74 Post-Quantum Attestation Primitive. 32 bytes on-chain commitment, 42 bytes in cache. Full signature bundle available for offline verification. |
| Verification model | Requires the signer's public key and the appropriate library. Often vendor-specific tooling. | Open-source verifier CLI. No API key, no account, no connectivity. Third-party implementations produce identical results. |
| Performance | RSA-2048 sign: ~1ms. ECDSA P-256 sign: ~0.5ms. Per-operation. | Full triple-PQ attestation pipeline: less than 42 microseconds per operation. Over 1.6 million attestations per second sustained on Graviton4 hardware. |
Classical digital signatures remain appropriate for short-lived, low-stakes signing where quantum resistance is not required. For long-term evidence, regulated environments, and any scenario where signatures must remain valid for years or decades, post-quantum attestation provides the necessary security guarantee.
The H33 Attestation API is a single HTTP endpoint that accepts any computation and returns a post-quantum signed attestation. It is the foundational primitive on which all other H33 products -- governance, privacy, replay, and verification -- are built.
When you submit a computation to the attestation API, the pipeline executes in three stages. Stage 1: FHE batch processing -- the computation metadata is encrypted using BFV homomorphic encryption and processed in batches of 32 operations (943 microseconds per batch, 70% of total latency). Stage 2: Batch attestation -- SHA3-256 hashing plus triple PQ signing with ML-DSA-65, FALCON-512, and SLH-DSA-SHA2-128f, followed by signature verification (391 microseconds, 29% of latency). Stage 3: ZKP cached lookup -- the attestation is indexed via the cache engine for rapid future retrieval (0.358 microseconds, less than 1% of latency). Total pipeline per 32-operation batch: 1,345 microseconds. Per-operation: 42 microseconds.
Every attestation is compressed into 74 bytes. The first 32 bytes are a SHA3-256 commitment that can be anchored on any blockchain -- Bitcoin via OP_RETURN, Solana via the memo program, Ethereum via calldata, or any chain that supports arbitrary data embedding. The remaining 42 bytes are stored in the H33 cache layer for rapid retrieval. The full signature bundle -- containing all three PQ signatures, the canonical computation frame, the governance context, and the hash-chain linkage -- is available as a separate artifact for offline verification. This architecture separates the compact proof-of-existence (74 bytes) from the full evidence bundle, optimizing for both on-chain efficiency and verification completeness.
The attestation API signs every operation with three independent post-quantum signature families, each based on a different mathematical hardness assumption. ML-DSA-65 (FIPS 204) is based on the Module Learning With Errors (MLWE) problem over structured lattices. FALCON-512 is based on the NTRU lattice problem with a distinct algebraic structure. SLH-DSA-SHA2-128f (FIPS 205) is based on the security of stateless hash functions. An adversary must break all three assumptions simultaneously to forge a single attestation. This is a fundamentally stronger security posture than any single-algorithm approach.
Integration requires a single HTTP POST to the attestation endpoint. The request includes the computation type and the input data (or its hash). The response includes the 74-byte attestation, the full signature bundle, and a verification URL. No SDK is required -- any language that can make HTTP requests can use the API. For high-throughput environments, the batch endpoint accepts up to 32 operations per request. The API is stateless; all governance context is embedded in the attestation itself.
The attestation API is the foundational primitive for any application that needs independently verifiable, post-quantum secure evidence of computation.
Cryptographic attestation is a signed, independently verifiable record that a specific computation was performed, by a specific party, at a specific time, under a specific policy. Unlike a digital signature (which proves authorship of a document), an attestation proves that a computation occurred and binds it to governance context. H33 attestations are signed with three independent post-quantum signature families, ensuring they remain valid against quantum adversaries.
A digital signature proves that a specific key holder approved a specific document or message. An attestation proves that a specific computation was performed, records the governance context (who authorized it, when, under what policy, within what scope), and signs the entire bundle with three independent post-quantum families. Signatures answer "who signed this?" Attestations answer "what happened, who authorized it, and can you prove it independently?"
The H33-74 Post-Quantum Attestation Primitive compresses the full attestation bundle into 74 bytes: 32 bytes for a SHA3-256 commitment (anchorable on any blockchain) and 42 bytes stored in the H33 cache layer. The full signature bundle -- containing all three PQ signatures, the canonical frame, and the hash-chain linkage -- is available as a separate artifact for offline verification. This separation optimizes for on-chain efficiency while preserving verification completeness.
Every attestation is signed with three independent NIST-standardized post-quantum signature families: ML-DSA-65 (FIPS 204, based on MLWE lattices), FALCON-512 (based on NTRU lattices, pending FIPS standardization), and SLH-DSA-SHA2-128f (FIPS 205, based on stateless hash functions). An adversary must break all three independent hardness assumptions simultaneously to forge an attestation -- three independent mathematical bets protecting every operation.
Yes. The verifier CLI is open-source and runs completely offline. Once you have the attestation evidence bundle, you can verify on an air-gapped machine with no network connectivity. No H33 API key, account, or infrastructure access is required. Third-party verifier implementations produce identical results, ensuring no single party controls the truth of the attestation record.
The attestation pipeline adds less than 42 microseconds per operation on Graviton4 hardware. In batch mode, 32 operations are attested in a single 1,345-microsecond batch. The pipeline sustains over 1.6 million attestations per second on production hardware. FHE batch processing consumes 70% of latency (943 microseconds), batch signing and verification consumes 29% (391 microseconds), and the cached ZKP lookup consumes less than 1% (0.358 microseconds).