Cert Seal on Canton

A compliance rail you can verify yourself.

We ran it live across two Canton participants: closed on one rail, sealed, reopened under a fresh identity, with five attacks each rejected by its own check. Confirm the cryptography yourself, offline, in minutes.

2
Canton participants, one rail each
5
attacks, each rejected at its own check
7
checks you recompute offline

What Cert Seal does

Move a position between venues without re-disclosing the counterparty, and without re-running the compliance checks it already passed. Built for overnight and intraday repo and collateral mobility, where the same position must be recognized in more than one place, fast, without leaking who holds it.

Forward-unlinkable by design

Built, per our patent, so each party sees only its own leg of a transfer while the full chain stays auditable to authorized parties.

Auditable for the full horizon

Banking-grade compliance attestations, verifiable today and decades from now.

Quantum-anticipating

ML-DSA signatures on the validator node, per NIST FIPS 204.

The attestation format, the Passport portability protocol, and the composite signature design are shared under NDA. What you see below is one run, fully open, so you can judge the engineering before we go further.

New to this? See how the compliance gate works →

Watch it run

The verifier executing its seven checks against the evidence bundle.

node verify.js . zerovaultid-certseal-rung6
Press Run the verifier to begin.
A dramatization. The real proof is the kit you run yourself, below.
A note on this demo. It runs on our page, so it will always pass. A demo the vendor controls is not evidence. The result that matters is the one you produce with the kit, which is why the steps below begin with your own tools.

Verify it yourself

One signed archive, one standalone verifier, fully offline. No Canton, no Docker, no account. You establish authenticity with your own tools before running anything we shipped.

  1. Fingerprint the signing key yourself, with your own openssl.
  2. Match it against the fingerprint we publish at a fixed public location. If they differ, stop.
  3. Verify the manifest signature with your own openssl.
  4. Confirm the verifier's own hash is in the now-trusted manifest.
  5. Run the verifier. It recomputes the cryptography and reports pass or fail.
Why the order matters. Any fingerprint the verifier prints is a convenience, not the source of trust: it ships inside the bundle, so a forger who re-signs could make it print anything. Steps 1 through 4 use your own tools and run first.

What the kit publishes

Archivezerovaultid-certseal-rung6.zip  (4.4 MB, reproducible)
Archive SHA-2563766af451d3fcb54698b35130044c80182bb3444d8ffc61e66d3f17749f51ef4
Verifiernode verify.js  (offline, 7 checks)
Authentic signing-key fingerprint, published independently of the bundle
e84ce01d300fef9427c979174068bf3d95d27b3c9bdaf58f5f2a3f2094a0d0e9
Published at
github.com/ZeroVaultID-Inc/evidence-signing-keys

Verify the file you received before trusting it. Its SHA-256 is
3766af451d3fcb54698b35130044c80182bb3444d8ffc61e66d3f17749f51ef4
On your machine, run sha256sum zerovaultid-certseal-rung6.zip (or shasum -a 256 on macOS) and confirm it matches.

Prefer to talk first? Contact ZeroVaultID and we will send the kit and walk your engineers through it.

What it proves

Exactly what the evidence supports, and where the edges are.

Independently reviewed. The kit was put through repeated adversarial review, every finding addressed and the artifact re-verified from scratch, before release.