One test transaction. One signed clearance object carrying both legs, verified offline against a sealed verifier before anything was submitted. What this page puts on the record is the temporal assumption: the object carries a validity window of its own, the verifier was handed a presentation clock, and the run writes down both, so the assumption a counterparty is asked to accept is stated in named parameters rather than left unwritten. Section 4 is exact about what that does and does not demonstrate, and the answer is less than it first sounds. Every value on this page is copied from the run evidence. Two of those values are withdrawn; see the correction below. Canton MainNet
Correction, issued 2026-09-18 and applied to this page on 5 October 2026. One result on this page is withdrawn. Two of the eleven gates this run recorded were computed from a ledger contract this run did not create. The software read the spend-once accumulator shard back with an active-contract query and took the first match on the expected shard number. A read-only census of our node's ledger on 2026-09-17 found five active contracts with that shard number and byte-identical consumed lists, so no field could have told them apart. The contract this record names as the shard after settlement is one of those five, is not the shard this run created, and is named identically by four other run records. The run's statement that both of the object's spend-once keys are recorded exactly once, the two gates that rest on it and the text of section 8.7 are therefore not supported as claims about this run, and we withdraw them. The same defect affected the five runs before 18 September 2026 (4, 14 and 17 September). What is not affected: every other gate and every off-ledger fact, including the object digest, the verifier digests, the window check, the recipient check and the update id. What survives independently: this run's run-tagged rail nullifiers were observed on the ledger in the 2026-09-17 census, so the test transaction did consume on-ledger; that is weaker than the withdrawn gates appeared to claim. The fix removed the active-contract query and reads the shard from the settling transaction's own tree; it was first used in the run of 18 September 2026, whose record is not yet published. The run evidence is preserved byte for byte as the run wrote it and has not been edited; the two withdrawn gates still read true inside it. This correction changes the record's claims. It does not revise the run.
Read section 8 before quoting anything from this page. Two things in particular. No negative controls ran. This was a positive-only settlement: nothing forged was submitted, so this run refused nothing and this page claims no refusal. And the object's spend-once property is asserted by its issuer, not proved by this run.
The claim under test was narrow. A clearance object is minted once, carries its own validity window and its own named recipient inside the bytes its issuer signed, and is then presented to a deployment that holds the trusted key out of band. The deployment's verifier either accepts the object against its own configuration, at its own clock, or refuses to let the settlement be submitted at all. Only if the verifier exits clean does a settlement command reach the ledger.
The design sentence behind the window, stated plainly: the clearance object carries a validity window that the verifier caps at twelve hours, which fits instruments that open and close within a single trading day. Twelve hours is the cap the verifier holds, not the window this object carried. This object's window was eight hours, and section 4 has both numbers side by side. What was not claimed is section 8, and it is the more important half of this page.
| Network | Canton MainNet global synchronizer. See the caveat on this identification in section 8.9. |
| Epoch | a single epoch label |
| Outcome | eleven run gates recorded, all true as recorded. Two of them were withdrawn on 2026-09-18; see the correction at the top of this page. |
| Negative controls | None. The run evidence records no negative controls, because this run submitted no forged variant and refused nothing. |
One object served both legs. It carries two members, so the verifier ran twice over the same bytes, once for the open leg and once for the close leg. The run records the same object digest and the same payload-level commitment for both.
| Signature | hybrid, two slots, all must pass: a classical signature and a post-quantum signature. The post-quantum algorithm's standards reference is the library vendor's description of its own build. No conformance testing is claimed here, and none was performed for this run. |
| Gate lines recorded, per leg | 42 |
The object carries one signing key id, and it is the same on both legs. The driver that mints the clearance refuses outright if the two legs disagree on it. Section 8.3 is about that single key and about what a count of keys here does and does not mean.
Both legs committed in one transaction, creating two anchors and resuming two heads.
The two anchor labels are the values this run realized and recorded. They are run-tagged labels, not digests. Nothing on the ledger recomputes them, so the binding equality is exercised exactly as written, and no digest construction should be inferred from the way the strings are spelled. The run records this limit itself.
The claim in this section is a disclosure claim, not a control claim. A TALON object carries a validity window inside the bytes its issuer signed, and the verifier prints, on the gate line that records the check, the presentation clock it was handed, the skew tolerance it applied and the duration ceiling it holds. The effect is that the temporal assumption a counterparty is being asked to accept is written down as named parameters, in evidence that cannot be revised afterwards. It becomes legible, and it becomes falsifiable. That is what this artifact offers and the delivery-versus-payment artifact does not: a settlement gate can bind a clearance to the settlement in front of it, but nothing in its record says when that clearance was good for, or against what clock anyone decided it was.
What this run did not do is exercise that window as a control. The clock was supplied by the operator, to a verifier the operator ran, over an object the operator had minted 2026 seconds earlier by that object's own issue time. It landed 1426 seconds into an eight-hour window. No object was presented outside its window, none was presented with an over-long window, and no negative control ran. This run exercised exactly one path through the window checks, the one where everything fits. Section 8.1 is the section to read before treating any of it as a tested control.
| Window opens | 2026-09-14T03:09:55Z |
| Window closes | 2026-09-14T11:09:55Z |
| Issued at | 2026-09-14T02:59:55Z |
| Window duration | 28800 seconds, 8.00 hours |
| Presentation clock, supplied by the deployment | 2026-09-14T03:33:41Z |
| Skew tolerance | 0 seconds |
| Duration ceiling, held by the verifier | 43200 seconds, 12 hours. This is the cap, not the window. The object used 28800 of it, and the ceiling is not a property of this object or of this run. |
All three window fields are identical on both legs, because there is one object. The presentation clock sits 1426 seconds after the window opened and 27374 seconds before it closed.
The ceiling is the verifier's, not the issuer's. It is not carried in the object, not read from the object, and not driven by the profile.
A window that does not fit under the ceiling is not a gap in this design. It is a threat the clock design logs as "a multi-day window presented as intraday", and the mitigation is precisely that the ceiling refuses it. The 8-hour window this run presented fits with room to spare.
The limit on all of it, in the verifier's own words: the clock came from the deployment and never from the object, and nothing in the window checks makes that clock truthful. No offline check can. An operator who lies to their own verifier about the clock defeats all five window checks together. What the design changes is that the clock, the skew tolerance and the ceiling are all named parameters printed on the gate line, so a counterparty can read the assumption off the evidence instead of inheriting it unwritten. The clock design carries the same point, and records that no check trips on it: it is disclosed, not defended.
The object names its recipient inside the bytes the issuer signed. The deployment names itself independently, through its own configuration.
The qualifier travels with the claim, and the verifier states it itself on the gate line: what is not established here is that the party presenting the object is the party named. This compares a configured string to a signed field, and it authenticates neither presenter. It closes the case where an object minted for another counterparty is replayed at this one, because such an object is internally self-consistent and passes every check before this one. It does not close the case where this counterparty's own configuration is presented by someone else.
The corroborating query ran on the day of the settlement. ZeroVaultID queried its own MainNet participant for the active contract set and checked this run's own contracts against what came back.
The match is by contract id, and this matters more than it sounds. The contracts checked are this run's anchors, heads and settlement, each looked up individually in that response. The accumulator shard it also looked up is the foreign contract described in the correction at the top of this page, so that one match establishes nothing about this run. A count of contracts bearing a template name would establish nothing here. An earlier TALON run on 2026-09-04 left its own contracts active on the same participant, and its parties are still visible in this run's own rights read-back. A template count cannot tell those contracts from these. A contract id can.
The general public cannot run it, and this page will not pretend otherwise. Canton contract contents are private to their stakeholder parties, so the active contract set of ZeroVaultID's parties is not reachable from outside ZeroVaultID. The response body is not published and will not be: it is a full active contract set for the operator party, most of it from other work and unrelated to this settlement.
ZeroVaultID recorded a digest of that response. It does not let a reader check the match; a reader does not have the file and cannot obtain it. What it does is fix ZeroVaultID's own record of what that 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 into a commitment fixed in ZeroVaultID's own record. It is not independent verification and it does not become any: it is the operator querying the operator's own participant, on the operator's own run.
The run records are available on request by email to peter@zerovaultid.com.
The run evidence is a curated copy. The digest and size of the uncurated original are recorded inside it, so every removal is auditable against a file that cannot be revised afterwards. The curated file is larger than the original because the redaction markers and the curation record are longer than the text they replace.
The delivery-versus-payment page published four removal classes. This page adds a fifth: the settlement reference base, which no earlier page had to remove, and which is the one that deserves a reader's attention. Counted across the two pages that is the fifth class in the series. Counted inside this file it is one of the four entries that the file itemises, listed here in full:
A reader who later obtains the object should not read that removal as an alteration hiding a mismatch. The payload commitment was never recomputable from this file in the first place, with or without the removed field, because it covers the whole member payload including a public-inputs blob that appears nowhere here. The run evidence says so in the same words.
No ledger fact was altered. Contract ids, the update id, anchors, nullifiers, gates, party ids, the network identifier, the package id, the object's digest, the verifier and manifest and parse digests, the object's validity window, and the caveat texts are byte-identical to the original. Two of the delivery-versus-payment removal classes have no counterpart here and nothing was invented to match them.
Everything here is a real limit on the claim, not boilerplate. Most of it the run records about itself, in its caveat fields.
This is a positive-only settlement. Not one forged variant was submitted, so the run evidence records no negative controls and this run refused nothing. Every statement on this page about what the verifier refuses is a statement about what the code does, read from the code, and not a statement about anything this run observed. Nothing here is a demonstration that a bad object would have been caught. That demonstration exists elsewhere in the control suites and is not what this page publishes.
The object carries a settlement reference base inside its signed bytes. The verifier parses it, bounds it and confirms the signature covers it, and then compares it against nothing. There is no check in this run that the object was minted for this settlement as opposed to another settlement of the same shape at the same recipient. That check is deferred to a later version.
This is stated here whether or not the field appears anywhere on this page, because this is the only place a reader who never opens the evidence file will learn it. Recipient binding in section 5 does not close it and must not be read as closing it. The two are different checks against different fields.
The evidence records exactly one distinct signing key id, identical on both legs, and the clearance minter refuses if the two legs disagree on it. That one key id covers a hybrid signature with two algorithm slots, one classical and one post-quantum, under an all-must-pass combiner, so two algorithm keypairs are exercised under one anchored key identity. The verifier resolves that identity from an out-of-band anchor and never from the object, which is the property that matters; the count is one.
The key that signed here is a development stand-in. Its seed is a documented text label padded to the library's seed width, with no entropy involved. Nothing was signed by a production issuer key, and no claim on this page should be read as one.
Separately, the Rail Open path underneath this settlement uses a three-signer aggregate, and the run's own residual text says all three of those keys are held by one operator, so proof of possession proves possession and never authority. This run's evidence records none of that key material: no public keys, no key commitments, no signer roles. A reader should take the figure three as a statement about the design, not as something this record exhibits.
The verifier states it on its own gate lines: no proof was verified. The object carries a verification key id and a proof digest, and the verifier checks that the key id equals its own pinned value. It does not run a proof. Nothing on this page is evidence that the underlying circuit statement holds.
Check 1, an inclusion proof of the leg's commitment against the source-rail accumulator root, and Check 2, an aggregate signature with proof of possession, are both computed in the driver process before submission, over real cryptography, fail-closed: verification failure means the driver does not submit at all. Their results are then asserted into the transaction as booleans. The ledger never verified either one and cannot. The ledger's built-in cryptography covers only a small set of common hash and signature functions, and none of the functions these two checks use. No cryptographic verification in this protocol executes on-ledger, and any statement that it does is wrong.
A second limit stands on Check 1 and is not closed by this run: no template on this ledger stores a source-rail root, so the check proves a genuine path against a root of unproven provenance. The root and path are recorded on-ledger, so the run is auditable and non-repudiable, but the root's authenticity is assumed.
The offline verifier holds no consumed-set state and performed no uniqueness check. The residual, stated as the verifier states it: repeat presentation to the same counterparty is caught only by verifier-local state, and that state is the counterparty's own, not a property of the artifact; concurrent presentation to two instances sharing no state is caught by nothing. The ledger side records each spend-once key once, which is section 8.7, and is a different and weaker thing than the artifact being single-use in the world.
The run's own words follow, and they should be read with the correction at the top of this page: the gate described below was computed from a foreign contract, so the sentence that it reports against a list this same run created is false for this run. What remains true from the run's own text is the residual: the accumulator shards are created by the run, so Check 4 provides no cross-run replay protection, and operator and cosigner acting together can mint a duplicate shard.
This run creates the three accumulator shards it then settles against, each with an empty consumed list, so Rail Open Check 4 is evaluated against an accumulator this run minted seconds earlier. Check 4 therefore provides no cross-run replay protection here: a nullifier spent by an earlier run is not in this run's consumed list, and re-presenting it would not trip. The gate reports against a list this same run created and must not be read as evidence that the clearance ids were unspent beforehand. Within the run there is no contention either: the two legs route to different shards, so even identical rail nullifiers would not collide. The residual is named on-ledger in the accumulator source: operator and cosigner acting together can mint a duplicate shard at the same epoch and shard id, and this driver signs as both.
The counterparty and the issuer are fixtures. The object names the counterparty and the issuer, and neither is a real institution. Seven parties were allocated fresh by ZeroVaultID for this run, all in a single party namespace, all on a single participant, and the submitting party is the operator. No third party participated, no real person was screened, and no personal data is recorded.
This bears on the two-authorization property. Creating an accumulator shard requires two distinct authorizers, the operator and the epoch's cosigner. Both are held by ZeroVaultID. What is demonstrated is a two-authorization requirement in the ledger's contract model. It is not an independent witness, and nothing here should be read as two or three institutions signing anything.
The evidence records a network identifier distinct from the DevNet one used in ZeroVaultID's earlier published runs, and a participant namespace that ZeroVaultID's source tree documents as its MainNet namespace. Both are consistent with this being MainNet. 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.
What this run evidences is a ledger state transition gated on an offline verification of a signed object. It is not an observed transfer of value and no balance change is claimed. It is a single settlement of demonstration scale, on one participant, with no concurrency test and no load test. The registries it reused were created under an earlier package version and are upgraded at fetch time, so the template ids the evidence records for them name the creating package and not the executing one.
The settlement gate this object is presented to, with its own scope statement and its own seven refusals: a compliance-gated atomic delivery-versus-payment settled on Canton MainNet on 2026-09-04. That page can show refusals, which this one cannot. This page can put the temporal assumption on the record as named parameters, which that one cannot.
The earlier public DevNet runs of the settlement design: the Canton DevNet delivery-versus-payment runs of 2026-07-23, 2026-07-30 and 2026-07-31.
The compliance attestation line this work builds on: a zero-knowledge compliance attestation gating a live settlement.