Skip to main content
The Product Key Registry is the canonical, signed answer to two enterprise questions: “how do I independently confirm this signature came from a genuine AlgoVoi key?” and “what happens when that key rotates?” It is additive. Every AlgoVoi product receipt is already self-verifying — the public key and kid travel inside the signed envelope, and the free verifier checks it with zero network calls. The registry adds an independent trust path: a signed, discoverable record of which keys AlgoVoi operates, the key-custody model for each product, and a cross-signed lineage so a retired key stays followable to its successor.

​
The signed registry

A single Falcon-1024 signed document (same root key, trust model, and monthly re-sign discipline as the ATB hub registry). It carries:
  • algovoi_operated_keys — the keys AlgoVoi signs with, fully specified (algorithm, kid, public key, what each is used for): the gateway Ed25519 (hosted compliance receipts / JWS) and the two Falcon-1024 ATB keys (registry root, certificate issuance).
  • products — one entry per commercial product with an honest key_custody field.
  • key_lineage — a genesis anchor per operated key, ready to carry cross-signed rotation proofs.

​
Key custody — who holds the signing key

Most commercial SKUs (Records Vault, Travel Rule, Audit Log, Agent Passport, …) are buyer-onprem — your keys never leave your estate. A few (e.g. Compliance Gate) are hybrid: a hosted convenience path under an AlgoVoi-operated key alongside the on-prem SDK. The registry documents the model honestly rather than implying AlgoVoi holds your keys.

​
Verify it yourself

The free verifier authenticates the registry and any kid offline — no AlgoVoi code, just pqcrypto + rfc8785:
The registry’s signed payload uses RFC 8785 (JCS) canonicalization, and it canonicalizes byte-identically across eight independent implementations (Python, Node.js, Ruby, PHP, Go, Rust, Java, .NET) — the same discipline as the open conformance corpus. So the exact bytes the Falcon-1024 signature covers are reproducible in your own stack.

​
Per-product DID

Each product resolves as a did:web:
The DID document links to this registry and the product’s documentation, and states the product’s key-custody model and signature algorithm — a stable, resolvable identifier per product.

​
Key rotation lineage

Records that outlive their signing keys need provable continuity across rotations. The registry carries an F7 cross-signed lineage (the same mechanism behind Recovery Vault and the conformance vectors epi_pqc_v0 set): on rotation, the old key authorises the successor and the new key counter-signs. A verifier follows the chain from any retired kid to the current one, so everything the retired key signed stays trustable.
Buyer-onprem products run this same lineage mechanism on their own keys (included with Crypto-Agility); the registry’s lineage covers the AlgoVoi-operated keys.