A zero-knowledge compliance attestation gated a live settlement on the public Canton DevNet global synchronizer.
A test run committed a full Passport chain on the public Canton DevNet: seal a 13-field envelope, open it through the Cert Seal Rail's five checks, verify the pinned zero-knowledge proof off-ledger, bind a cleared attestation to the anchor, and settle a deposit to the recipient. Every value below is copied from the run evidence. Canton DevNet
What the five checks cover. Three of the five Rail Open checks are enforced by the ledger: verifying key admissibility, nullifier uniqueness, and destination context recompute and compare. The other two, inclusion proof and signature with proof of possession, are yes-or-no results the submitting driver supplies, and this run supplied yes for both. The envelope's inclusion-proof and signature fields carry asserted-in gate tokens, not real inclusion proofs or signatures. Nothing in this run computed or checked either one. The three ledger-enforced checks, the pinned proof verification, and the attestation bind are what this run demonstrates.
The four claims
- The Passport proof proves the policy predicate holds. The pinned zero-knowledge proof verifies under the pinned verifying key, so the policy predicate is satisfied.
- The bridge binds that proof to the on-ledger envelope via three equalities, all checked this run.
- One clearance is valid for exactly one envelope. The negative
control proves a re-point is rejected: a cleared attestation bound to a different digest
is refused on-ledger with
attestation not bound to this envelope. - The Passport's destination context binds the 3-part rail identity only; epoch and one-time replay are enforced separately, by the forward-secure nullifier (on-ledger Check 4, per-shard uniqueness) and the on-ledger epoch gate, not by the Passport destination context.
Environment
| Network | Public Canton DevNet global synchronizer (DevNet, not MainNet and not production) |
| Package | the original Passport gate package |
Transactions and contracts on the public ledger
The committed transactions (four), plus the two negative-control attempts, which were rejected at interpretation and therefore have no committed update id:
| Step | Status |
|---|---|
| seal | committed |
| rail open | committed |
| attestation | committed |
| settlement | committed |
| negative control: re-pointed attestation | rejected at interpretation (no committed update id) |
| negative control: uncleared attestation | rejected at interpretation (no committed update id) |
The ledger rejecting forged attempts
Negative control 1: a cleared attestation bound to a different digest
Rejected on-ledger with
attestation not bound to this envelope.
Negative control 2: an uncleared attestation, correctly bound
Rejected on-ledger with
recipient is not cleared (KYC / sanctions).
Run records
The run records are available on request by email to peter@zerovaultid.com.
Independent confirmation
Canton contract contents are private to their stakeholder parties by design, so independent confirmation of the transactions requires DevNet access. The ZeroVaultID validator and party are publicly visible on the Lighthouse DevNet explorer.
ADDENDUM — 2026-07-22
The runs documented above executed under an earlier package. Its Check 4 enforced nullifier uniqueness per accumulator shard, not epoch-globally: the accumulator's sole signatory could recreate it empty, and the same nullifier settled in two runs in the same epoch, on 2026-07-21 and 2026-07-22. Every value above remains accurate for its own run.
A successor package was deployed on 2026-07-22 to the same public global synchronizer (DevNet, not MainNet, not production). Accumulator creation now requires two distinct party authorizations, the operator plus the epoch's registered cosigner, and the destination authority acting alone cannot create or reset an accumulator. This was demonstrated publicly: the participant refused a single-party accumulator creation at command interpretation. On DevNet both parties are held by the same operator; the demonstrated property is the two-authorization requirement, not an independent witness.
Full evidence pack and claims: ./accum/
Run of 2026-07-31, later package version
A later Passport run committed the same chain under a later version of the successor package. It is a separate run from the one documented above; every value in this section is copied from that run’s own evidence. The run recorded all 10 named gates true.
| Network | Public Canton DevNet global synchronizer (DevNet, not MainNet, not production) |
| Package version | a later version of the successor package |
What the proof established, and where it was checked
The holder’s credential presentation was verified off-ledger, by the bridge, before submission. The run records that check as a precondition. The ledger did not verify the proof. The run records no on-ledger verification step, and none of the four committed transactions performs one.
The proof was checked under this run’s own pinned verifying key, recorded in the sealed envelope. The compliance predicates it carried are recorded as KYC and sanctions, so the holder established a KYC and a sanctions predicate under that key. This run’s evidence does not record the sanctions list roots, the issuer root, or a policy commitment, and no claim about which lists were screened is made here.
What the ledger enforced is the binding: the three ledger-enforced rail open checks, the 13-field envelope, the equality of the computed and on-ledger anchor, and the refusal of any attestation not bound to that anchor or not cleared. Those refusals are below and are on-ledger facts.
The anchor
The anchor digest computed by the bridge, the value read back from the on-ledger anchor, and the value carried by the anchor itself are all equal.
Committed transactions
| Step | Status |
|---|---|
| seal | committed |
| rail open | committed |
| attestation | committed |
| settlement | committed |
The ledger refusing forged attempts
Negative control 1: a cleared attestation bound to a different digest
Refused with
attestation not bound to this envelope.
Negative control 2: an uncleared attestation, correctly bound
Refused with
recipient is not cleared (KYC / sanctions).
Single-party accumulator creation
The destination authority acting alone cannot create an accumulator shard that needs two signatories. This refusal is a different kind from the two above: it is an authorization error for missing cosigner authority, not a business assertion.
All three refusals were raised synchronously at command interpretation on the submitting participant. None was sequenced, and none has a committed update id.
Scope of this run
- Public Canton DevNet global synchronizer: DevNet, not MainNet, not production, demonstration scale.
- No real person was screened. The recipient is the allocated demo party; the sender, customer and recipient were all allocated fresh for this run. The run evidence records no name, date of birth, document number or any other personal data.
- All parties are operated by ZeroVaultID. The two-authorization property shown by the single-party refusal is two distinct party authorizations under one operator, not an independent witness.
- The proof was verified off-ledger. The ledger enforced binding, clearance and one-time use, not proof validity.
ADDENDUM 2026-07-24: this Passport gate now extends to a two-leg atomic delivery-versus-payment settlement on the same public Canton DevNet global synchronizer, each leg bound to its own realized anchor and cleared attestation. Evidence and re-verification: /dvp-verify.