You can't be sued for data you don't have.
Mathematically verified, zero-knowledge attestations for every regulated check.
Anchored on a public ledger. Independently re-verifiable. No credential fields accepted. Minimal record kept.
ZeroVaultID operates a validator node on Canton MainNet. Between August 30 and September 18, 2026, we ran compliance-gated test transactions through it, using synthetic documents, test parties and development keys, with no customers, no securities and no assets. On October 14, 2026, a TALON clearance signed with keys held in AWS KMS, including a post-quantum ML-DSA-87 key, settled in a test transaction on Canton MainNet, again test-only, with test parties, no customers, no securities and no assets, and with key custody recorded as not production. The records below come from our own run records (for October 14, 2026, also from its mint record and our internal disclosures), and each page states its limits. See the MainNet records →
· 2 live in browser demo
issuer-agnostic by design
0xCB9567…4c3264
Ever.
Test transactions on Canton MainNet, August 30 to September 18, 2026, and October 14, 2026.
ZeroVaultID operates its own validator node, zerovaultid-validator-1, on Canton MainNet, and ran its test transactions through it between August 30 and September 18, 2026. On October 14, 2026, a TALON clearance signed with keys held in AWS KMS, including a post-quantum ML-DSA-87 key, settled in a test transaction on Canton MainNet; the keys are held by ZeroVaultID and their custody is recorded as not production. Everything was test-only: test parties, no customers, no securities, and no real person screened; the runs up to September 18, 2026, used synthetic documents and development keys. The results below come from our own run records (for October 14, 2026, also from its mint record and our internal disclosures); one read-back result was later withdrawn and is marked on its page. Each page states its limits.
Compliance-gated DvP
A two-leg test transaction, built on a delivery-versus-payment design, that the ledger code refuses unless each leg carries a clearance record our off-ledger software marked as passing, bound to that leg. On Canton MainNet on September 4, 2026, our submitting node refused seven altered variants while interpreting the commands, so none reached the network; the unaltered test transaction then committed. The legs are data labels and denote no asset.
See the MainNet run →Cross-Rail Compliance Passport
A sealed attestation that carries a completed check from one party to another without re-running it. The receiving side opens it through the Cert Seal rail checks, and the clearance is recorded as spent within its storage partition. Ran end to end on public Canton DevNet with the evidence published, and on Canton MainNet on September 4, 2026, as a test between two test parties we created, with test data and no money or value behind it.
See the published DevNet run →TALON clearance object
One signed, recipient-bound clearance object covering a same-day open and close, checked offline against a sealed verifier before the test transaction is submitted. Six test runs on Canton MainNet between September 4 and 18, 2026. The September 4 run used an earlier verifier with no validity-period check and accepted an object more than 37 days past its stated expiry; the validity window was checked from the September 14 run onward, and a zero-knowledge proof only in the four runs on September 17 and 18. One read-back result was withdrawn for all five runs from September 4 to 17, and the page marks it; the September 18 run takes that result from its own transaction. On October 14, 2026, a TALON clearance object signed with keys held in AWS KMS, including a post-quantum ML-DSA-87 key, settled in a test transaction on Canton MainNet; the offline verifier accepted the object and its zero-knowledge proof before submission. The AWS KMS keys are held by ZeroVaultID, their custody is recorded as not production, and some other keys in that run are not on AWS KMS.
See the MainNet record and its correction →Sanctions-list check on identity documents: OFAC SDN, UN, EU
The check records, as a zero-knowledge proof, whether two identity document numbers, one national identity card and one passport, appear in signed, dated snapshots of the OFAC SDN, UN and EU lists. It does not screen names or dates of birth, so a person whose name is on a list, but whose document numbers are not, passes. Each snapshot carries a signed expiry, and the method that uses the snapshots refuses an expired snapshot before submitting a test transaction. The snapshots in use expired on September 21, 2026. New snapshots were signed on September 23, 2026, but as of October 5, 2026, the software has not been switched to them, so this method cannot currently produce a passing result; the new EU snapshot also lacks five entries added to the EU list on August 7, 2026.
Your KYC stack is your audit trail. It's also your breach surface.
Persona, Jumio, Onfido, Socure, Alloy: every identity vendor on the market ships you a customer file. That file is what you show your auditor. It's also your GDPR exposure, your discovery liability, and your largest unpriced operational risk. The thicker your audit trail, the larger your blast radius.
Three steps. PII stays put.
ZeroVault is the compliance attestation infrastructure for on-chain finance, built so institutions can prove a check passed without re-sharing customer data. You already hold the PII you're legally required to hold, and it stays with you: the zero-knowledge proof is generated at your edge, from the credential you hold. ZeroVault verifies that proof against the published verification key, mints a VRID, anchors it on-chain, and chains it into the customer's FCR Audit, a per-customer ledger with cryptographically enforced continuity. Counterparty onboarding, periodic re-KYC, auditor spot-check, regulator review: each is satisfied by a deterministic lookback across the chain. On Canton MainNet the same principle gated our test transactions: our off-ledger software checked the clearance before the test transaction was submitted, and the ledger recorded the result. The PII never leaves your perimeter.
Credential exists
Your KYC'd customer record already exists, either as a W3C Verifiable Credential or as the verified identity data your platform is legally required to hold. The credential, not the underlying data, becomes the input to the proof.
Proof is verified
The zero-knowledge proof is generated at your edge, from the credential you hold, and ZeroVault verifies it against the published verification key. The proof confirms the attribute (sanctions-clean, KYC-passed, accredited) without exposing the underlying data to anyone downstream.
VRID minted, anchored, and delivered
ZeroVault mints a VRID, anchors it to the on-chain receipt contract, and chains it into your customer's FCR Audit ledger. Your platform receives the VRID bundle and the on-chain transaction logs via API. This is the artifact your auditor verifies, your regulator spot-checks, and your counterparties accept in place of re-sharing the underlying data. The on-chain anchor records a hash of the attestation fields and when it was written. It does not contain the proof or the verification key, so the proof is checked against the published verification key as a separate step.
The attestation protocol behind every ZeroVault check. Prove a regulated check in zero knowledge, return a tamper-evident receipt, and retain none of the underlying data. Verification is deterministic, so anyone can re-check the same proof later and get the identical result.
Zero-knowledge proof
Noir and UltraHONK. The check is proven, the data behind it never leaves your perimeter.
Tamper-evident receipt
A VRID anchored on Base Sepolia testnet, with the timestamp readable on-chain by anyone.
Deterministic by design
Re-check the proof years later for an auditor and it returns the identical result.
Zero retention
No PII sits behind the receipt. Retention is zero by protocol, not by policy.
Tested on Canton MainNet: Cert Seal, our cross-rail layer carries an attestation between parties without re-running the check. We operate a validator node on Canton MainNet, where compliance-gated test transactions committed through the rail between August 30 and September 18, 2026. See the MainNet records → · Earlier DevNet run →
Watch a compliance check run, start to finish.
The demo runs W3C Verifiable Credentials and Noir/UltraHONK proof verification in your browser via Barretenberg WASM, on Base Sepolia testnet. Nine circuits compiled, two live in the browser demo (CR-05 KYC clearance, CR-09 sanctions non-inclusion). Issuer-signature binding and in-circuit nullifier derivation are built and were exercised in the July 31, 2026, public Canton DevNet run, published in full at /passport-verify including what that run does not establish. If you are a CCO, BSA officer, or head of compliance evaluating this for a fintech, start with the demo, then inquire.