A two-leg test transaction committed as a single ledger transaction, with no customers, no securities and no assets behind it. Each leg carried its own clearance record from a zero-knowledge proof checked off-ledger, bound to its own realized anchor; our software's read-back after the transaction recorded each single-use value as spent once, using a query that could match another record (section 7.11); and seven altered variants were each refused by the submitting node at a named assertion and rolled back before anything reached the network. Every value on this page is copied from the run evidence, and section 6 says what a reader outside ZeroVaultID cannot check. Canton MainNet
Read section 7 before quoting anything from this page. This run demonstrates a settlement gate, not a cleared counterparty. The proof was verified off-ledger; the subject of the clearance is not named by any public input; and both counterparties are test parties operated by ZeroVaultID.
The claim under test was narrow and mechanical: that a two-leg delivery-versus-payment can be made to commit on the Canton MainNet synchronizer, in a test with no customers, securities or assets, only when each leg presents a clearance that is bound to that specific leg of that specific settlement, under a compliance suite the ledger itself recognizes, and that every way of breaking that binding is refused before anything is sequenced.
What was not claimed is set out in section 7, and is the more important half of this page.
| Date | 2026-09-04. The seven control submissions are ledger-timestamped from 00:56:01.872074Z to 00:58:20.056090Z; the positive settlement followed them, and the run did not record a submission timestamp for it. |
| Network | Canton MainNet global synchronizer. This is the Canton MainNet global synchronizer, not DevNet; the transactions were test transactions for ZeroVaultID's own testing. See the caveat on this identification in section 7. |
| Epoch | a single epoch label |
| Outcome | all true |
Five run-level gates and thirteen settlement gates were recorded, all true. The thirteen settlement gates are listed in the run record.
Both legs committed atomically in one transaction, creating two anchor contracts.
| Anchors created | 2 |
The transaction id is recorded in the run log, not in the run record. See section 6 for what can and cannot be done with this id.
This page makes no claim about how the two anchor labels this run realized and recorded are constructed, and no digest construction should be inferred from them.
The settlement is all-or-nothing across both legs. A failed bind on either leg, after both legs have opened in-transaction, aborts both opens and both consumes, so no anchor is created and no nullifier is spent. The seven controls in section 4 are the evidence for that.
Seven forged variants were submitted against the same bound choice, each with a freshly sealed scenario of its own, and each was refused. All seven ran before the positive settlement. The assert text below is quoted verbatim from the ledger error message recorded for that control.
| Control | What it forged | Named assert, verbatim |
|---|---|---|
| Delivery not bound | delivery attestation not bound to the delivery envelope | attestation not bound to this envelope |
| Payment not bound | payment attestation not bound to the payment envelope | attestation not bound to this envelope |
| Uncleared | an attestation that is not cleared | recipient is not cleared (KYC / sanctions) |
| Wrong leg | a clearance valid for one leg, presented for the other | clearance is not for the buyer leg of this settlement |
| Legs swapped | the two legs' attestations swapped | attestation not bound to this envelope |
| Unregistered suite | a compliance suite id that is not in the registry | requested compliance suite is not registered |
| Mismatched policy | a policy commitment that does not match the registered suite | clearance policy commitment does not match the registered suite |
Rollback was not assumed. For each control the driver re-read ledger state afterwards and recorded four separate observations. All four are true for all seven controls.
Seven controls, five distinct assert messages.
The delivery-not-bound, payment-not-bound and legs-swapped controls are three different forgeries
that all halt at the identical assertion, attestation not bound to this
envelope. What this run shows is that each of the three is refused. It does not
show that the ledger distinguishes them from one another, and this page does not claim
seven independent reject lines.
The run recorded, per leg, the exact claim its clearance stands for.
The two recorded claims are identical except for the destination context and the nullifier. That difference is what makes the legs distinct and non-interchangeable, and it is what the wrong-leg and legs-swapped controls attack.
The final sentence of each claim is the run's own statement of the limit in section 7.4: no party identity is asserted.
The proof covers two government-ID document numbers only. It does not screen names or dates of birth, so "non-membership" in each claim means that the two document numbers are absent from the three signed snapshots, and nothing more.
The run records are available on request by email to peter@zerovaultid.com.
The run record and the run log are curated copies. Four classes of content were removed before publication: the operator's participant network address, the driver's environment configuration, absolute filesystem paths on the machine that ran the settlement, and the sixteen per-leg nullifier derivation labels. No ledger fact was altered. Every contract id, nullifier, anchor, gate result, party id and verbatim ledger error payload is byte-identical to the original. The removals are itemized inside the file itself, together with the digest of the uncurated original.
One check the operator ran, which a reader cannot. On 2026-09-12, eight days after the run, ZeroVaultID queried its own MainNet participant for the active contract set, once as each party, and counted the active anchor contracts.
That response body is not published, and will not be. It is a full active contract set for the operator party: 128 contracts across ten templates, most of them from other work and unrelated to this settlement. Publishing it would disclose ledger state far beyond what this page is about. ZeroVaultID recorded a digest of it for one narrow purpose, and it is worth being exact about what that purpose is. It does not let a reader check the count; a reader does not have the file and cannot obtain it. What it does is fix ZeroVaultID's own record of what the query returned, at a value that cannot be revised afterwards. If the snapshot is ever produced, to an auditor or under diligence, it either hashes to the recorded value or it is not the response this page was written from. That turns an unfalsifiable assertion about a count into a commitment fixed in ZeroVaultID's own record. It is not independent verification and it does not become any.
The count for the operator party is two, which is the number of anchors section 3 records this run as having created. The query counted contracts by template, so it corroborates that count and not the identity of the two contracts.
Read the provenance of this check before relying on it. It is the operator querying the operator's own participant, eight days after the settlement. It is not an independent check, and no third party performed it. A reader cannot repeat it, for the same reason the bullets above give: Canton contract contents and transactions are private to their stakeholder parties, so the active contract set of ZeroVaultID's parties is not reachable from outside ZeroVaultID. It stands as corroboration of ZeroVaultID's own record by ZeroVaultID, and nothing more than that.
The other three parties queried, the witness party and the two source parties, each returned a count of zero. Those zero counts are the scoping property, and they are not evidence that nothing happened for those parties. An anchor is visible only to the operator party. A party that is not a stakeholder on a contract does not see that contract in its own active contract set, so a zero for the witness party or for either source party carries no information about what did or did not occur for that party.
Everything in this section is a real limit on the claim, not boilerplate. Several of these are recorded by the run itself.
Each leg's proof was verified in the off-ledger bridge, before the settlement command was submitted. The ledger never verified it and cannot. The ledger's built-in cryptography covers only a small set of common hash and signature functions, and not the hash function this circuit uses in-circuit. So the proof check runs off-ledger and its result is asserted into the atomic transaction. No cryptographic verification in this protocol executes on-ledger, and any statement that it does is wrong.
What the ledger does enforce natively, by recomputing the value and refusing a mismatch, is the destination context, the leg tag, the settlement reference, the epoch and the policy commitment. Those recomputations are real, and four of the seven controls in section 4 exist to demonstrate them.
What the ledger does not do is establish that the counterparty is cleared. The cleared flag arrives as a yes-or-no value that the off-ledger bridge set, and the ledger asserts on that value. The uncleared control proves the ledger refuses a "not cleared"; it does not prove the "cleared" in the positive run was earned. That is the trusted-verifier seam, and it is by construction, not by oversight.
The ledger checks that the requested suite id is registered ACTIVE and that the clearance's policy commitment matches the commitment the registry holds. It does not evaluate the suite's contents. That the suite means OFAC, UN and EU non-membership plus a government-ID issuer binding is an assertion carried in the registry row, written by the operator.
The proof's public vector binds no subject identifier. The run says so itself, in both leg claims it recorded: NO party identity is asserted. Nothing in this settlement ties the clearance to the Canton party that received the delivery or made the payment. What was proved is that the two government-ID document numbers of some holder of two issuer-signed government-ID credentials are absent from the three signed snapshots. Names and dates of birth are not screened, so a person whose name is listed, but whose document numbers are not, passes. That the holder is the counterparty is asserted off-ledger by the verifier, not proved.
Rail Open's inclusion check proves a path against a source-rail accumulator root. No template on this ledger stores that root. Nothing on-ledger, and nothing in this run's evidence, establishes where the root came from or that it is the right one. The check proves a genuine path against a root of unproven provenance.
Every party in this run was allocated fresh by ZeroVaultID for this run, in a single party namespace, and every submission the run recorded acted as the operator party. The demo material is marked as test-only and not production. No third-party institution participated, no real person was screened, and no personal data is recorded.
This bears directly on the co-signature property. Creating a nullifier accumulator shard requires two distinct authorizers. Both are held by ZeroVaultID. What the run demonstrates is a two-authorization requirement in the ledger's contract model. It is not an independent witness, and nothing here should be read as three institutions, or two, signing anything.
The run recorded both the before and after wallet readings as unavailable, with the reason that the wallet service was unreachable, and noted the caveat itself. What this run evidences is a ledger state transition under a compliance gate. It is not an observed transfer of value, and no balance change is claimed.
The two legs are data labels and denote no asset, amount or instrument; each leg was a set of compliance records.
Relatedly, the destination authority address in this run is a literal placeholder. It is not a real destination-chain authority.
All seven controls were refused at command interpretation on the submitting participant and rolled back. None reached the sequencer. This is the correct and expected behaviour, and it is why nothing was written. It also means the controls demonstrate that the ledger's contract model refuses these forgeries. They demonstrate nothing about the synchronizer, about consensus, or about behaviour under concurrency.
The evidence records a network identifier that is distinct from the DevNet one used in ZeroVaultID's earlier published DvP runs, and a participant namespace that ZeroVaultID's source tree documents as its MainNet namespace. Both are consistent with this being MainNet. But the evidence file nowhere names the network, and the identification rests on ZeroVaultID's own records rather than on anything a reader can check from the run artifacts alone.
This is a single test transaction of demonstration scale, with one positive case and seven controls, on one participant. It is not a load test, a soak test, or a concurrency test, and the concurrent-open case is not exercised here.
Correction of 5 October 2026. The run's "consumed once" results and the three consumed-once gates were computed by our software's read-back after the transaction, which found each shard by first match on cosigner, epoch and shard id among active shards. The same read-back pattern was later found wrong for the signed-object (TALON) runs of 4 to 17 September 2026, where it read a contract the run had not created, and that result was withdrawn on 18 September 2026. This run's read-back has not been re-derived from the transaction's own tree. These results therefore record what our software read back, not an established property of this transaction. The evidence files are unchanged.
The earlier DevNet runs of the same settlement design, with their own scope statements: the public Canton DevNet DvP runs of 2026-07-23, 2026-07-30 and 2026-07-31. Those runs are on a different network, a different synchronizer and earlier packages, and they are superseded by this page as the current record.
The Passport line this work builds on: a zero-knowledge compliance attestation gating a DevNet test transaction.