TALON test transactions on Canton MainNet: four on September 17 and 18, 2026, and one on October 14, 2026 whose clearance object was signed with keys held in AWS KMS. In each, a signed clearance object and its zero-knowledge proof were checked offline before the test transaction was submitted.

Read this before quoting anything from this page.

• Test-only. Every party was a test party ZeroVaultID created. The issuer, the recipient and the spend-once keys are specimen fixtures, not real institutions or records. No real person was screened, no third party took part, and no value moved.
• No negative controls ran in any of the four runs. Nothing altered was submitted, so none of these runs refused anything, and this page claims no refusal.
• The proof was verified off the ledger, before submission. The ledger does not check the proof and cannot. The zero-knowledge circuit is not claimed sound and has not been independently audited.
• Run 1's record says no proof was verified. That sentence is wrong, and section 3.1 says why and what the correction rests on.
• Two ledger read-back results are withdrawn for runs 1 to 3. Section 4 says what was wrong, what still stands, and what the September 18 run changed.
• In the four September runs, the signing key is a development key whose seed is a fixed value and not a secret, so a valid signature shows internal consistency, not who signed (section 7.7).

What the October 14, 2026 run does not show.

• Test-only. The identities in the object are specimen values, not real institutions or people. This is a technical milestone, not a settlement between counterparties.
• One participant. Every party in the test transaction was created by ZeroVaultID and hosted on one participant, so the run supports no claim about privacy between participants and no claim that any other institution took part.
• Custody is not production. The AWS KMS keys are held by one operator, ZeroVaultID, and their custody is recorded as not production.
• Not every key is on AWS KMS. The AWS KMS keys signed the clearance object. Some other keys used in this run are not on AWS KMS.
• The KMS signing rests on ZeroVaultID's records. The ledger does not check that AWS KMS made the signatures.
• Sanctions snapshot. The sanctions-screening proof used in this run was made against the August 2026 snapshot of the sanctions lists, not the newer one.
• Limits carried from the September runs. No negative controls ran on the ledger. The circuit is not claimed sound. The limits in sections 7.2, 7.3, 7.4, 7.5, 7.8, 7.9, 7.10, 7.11, 7.12 and 7.13 apply to this run as well.

What was wrong. After each test transaction, ZeroVaultID's software read the spend-once accumulator shard back from the ledger with an active-contract query and took the first contract with the expected shard number. A read-only census of ZeroVaultID's ledger on September 17, 2026 found five active contracts with that shard number and byte-identical consumed lists. The spend-once keys are specimen values inside the signed object, so they are the same in every run, and the other fields are the same too. No filter could have told the five apart.

Which runs. Five run records name the same contract, which none of them created. They are runs 1, 2 and 3 on this page, and the runs of September 4, 2026 and September 14, 2026. In those five records, two gates are not supported as claims about the run, and ZeroVaultID withdrew them on September 18, 2026. The records themselves are unchanged, so both gates still read true inside them.

What still stands. Every other gate and every off-ledger fact: the object digests, the verifier digests, the proof result, the window and recipient checks, the registry read-backs and the update ids. Each earlier run's run-tagged rail nullifiers were present on the ledger in the September 17, 2026 census, so those test transactions did consume on the ledger. That is weaker than the withdrawn gates appeared to claim, and the census is ZeroVaultID's own query, not something a reader can repeat.

What changed on September 18, 2026. The active-contract query was removed. The read-back now comes from the test transaction's own tree, asserts exactly one terminal successor, and fails closed on zero or more than one. A tree read that does not complete records the tree-derived gates as null, so the run reports not green. The gates were renamed because their mechanism changed.

The September 18, 2026 run's terminal successor is not the contract the five earlier records name. Do not read runs 1 to 3 as having been checked the way the September 18 run was. They were not. The fix changed which shard the gate reads; it did not change the limit in section 7.3.

One caution for a reader comparing records across pages: the two-leg test of September 4, 2026 still records a gate under its old name and with its old meaning, a comparison of two constants. The same gate name in two records does not mean the same check.

ZeroVaultID records this finding internally as a disclosure. The record for the September 14, 2026 run carries the same correction on its own page.

5.1 What the proof result does not establish

• The circuit is not claimed sound, and it has not been independently audited. A verified proof shows the proof checks under the pinned key, not that the statement behind the key is the right one.
• The proof was checked off the ledger. Its result reached the ledger as a recorded fact. The ledger has none of the hash functions this proof relies on, and checks no proof.
• This page makes no claim about what the proof shows about any person, list or screening result. The documents behind it are synthetic. The verifier on this path does not read the sanctions-list snapshots or their expiry dates.
• The proof cannot be re-checked from this page. The proof file and the object are not published, so a reader cannot repeat the check.
• The proof names no one. That its holder is the other party to a test transaction is asserted off the ledger, not proved.

7.1 No negative controls ran

Not one altered object or command was submitted in any of the four runs. Every statement here about what the verifier or the ledger refuses describes the code, not anything these runs observed. Nothing here shows that a bad object would have been caught.

7.2 Spend-once is asserted by the issuer, not proved

The offline verifier holds no record of spent objects and performed no uniqueness check. A repeat presentation to the same recipient is caught only by that recipient's own state, and a presentation to two verifiers that share no state is caught by nothing.

7.3 The ledger shard is one each run created

Each run creates the three accumulator shards it then uses, each with an empty consumed list. So the ledger's check offers no protection against replay from another run: a key spent by an earlier run is not in this run's list. Single-use protection is per storage partition, not across a whole period. The September 18, 2026 gate reads the right shard; it is still a shard that run wrote, and it is not evidence the keys were unspent beforehand. Creating a shard needs two authorizations, the operator and the epoch's cosigner, and ZeroVaultID holds both, so it could create a duplicate.

7.4 Rail Open Checks 1 and 2 are checked off the ledger

Check 1, an inclusion proof, and Check 2, an aggregate signature, are verified by ZeroVaultID's software before submission, and their results are passed to the ledger as yes-or-no values. The ledger verifies neither. No ledger template stores the source root, so Check 1 verifies a real path against a root whose authenticity is assumed. All three Check 2 signing keys are held by ZeroVaultID, so the check shows possession of three keys, not three institutions.

7.5 The ledger does not compare who verified the object

This is an open defect on this path, found by review and not by test: the ledger never compares who verified the object.

7.6 Every identity is a specimen fixture

The issuer and the recipient are not real institutions. The spend-once keys are specimen values carried unchanged in every run, which is why five records could not be told apart (section 4). Every party was created by ZeroVaultID in one namespace on one participant, and the submitting party is ZeroVaultID. This supports no claim about privacy between participants and no claim that any institution took part.

7.7 In the September runs, every key is a development key

One signing key id, identical in all four runs, covers both algorithm slots. Its seed is a fixed, documented value with no entropy and is not a secret, so anyone who has it could produce a valid signature. A valid signature therefore shows internal consistency, not authorship. Nothing here was signed by a key in production custody.

7.8 The clock is ZeroVaultID's

The window checks compare the object's signed window with a clock ZeroVaultID supplied. Nothing makes that clock truthful, and a false clock defeats the checks for an object not yet valid or already expired. The verifier prints the clock and the ceiling on its gate line, so the assumption is written down, not defended.

7.9 The epoch is declared by ZeroVaultID

The epoch is a label ZeroVaultID set, compared against a registry ZeroVaultID created. Both sides of that comparison are ZeroVaultID's.

7.10 The object is not tied to a particular test transaction

The object carries a settlement reference base inside its signed bytes. The verifier parses it and confirms the signature covers it, then compares it against nothing. Nothing checks that an object was minted for this test transaction rather than another of the same shape at the same recipient. Recipient binding does not close this.

7.11 Untested behavior of the verifier

Whether the verifier opens network connections, since it began verifying proofs, has not been tested.

7.12 MainNet is ZeroVaultID's identification of the network

The records carry a network identifier different from the DevNet one in ZeroVaultID's earlier runs, and a party namespace ZeroVaultID's own records document as its MainNet namespace. The records do not name the network, and the identification rests on ZeroVaultID's records, not on anything a reader can check from these files alone.

7.13 No value moved, and four runs are four runs

What these runs show is a ledger state change gated on an offline check of a signed object. No value moved and no balance changed. Each is a single test transaction on one participant, with no concurrency or load test.