VTE - Veridex Threshold Evidence
One mechanism, four answer shapes, one cross-checked package.
Harbour Point Fund II keeps its money with Northbridge Custody Bank. A lender about to release funds needs to know the fund really has enough behind it. Today that leaves two bad choices.
Northbridge asks a shared ledger one narrow question, and the ledger answers it.
Does this account hold at least $10 million?
They are four shapes of answer that one mechanism produces about one attested position, so whoever is asking gets the shape they need. Because all four describe the same case, the mechanism can compare them against each other and refuse to assemble a set that contradicts itself.
Pick a mode below. A real answer comes back in about a minute, from the ledger, not from this page.
One case, asked four ways. The only thing that changes is how much crosses. The grid shows what the asking party sees. In VTE Policy and VTE Trade Check the governance parties of the ledger also see the values; only VTE Reveal and VTE Match hide values cryptographically.
| Exact total | Category mix | Per-source split | Pass / fail | Band |
|---|
The asking party sees the answer, not the account.
Six fields, all optional. They label the evidence; they do not change what the ledger is asked.
Which parties a deployment accepts as an attesting source is decided when that deployment is configured; the mechanism shown here does not itself check whether a source is a custodian or the subject. All names and amounts on this page are fictional example data.
Each row is a custodian reporting what it holds for the subject. Two custodians reporting separately is the point: the total exists without either of them, or the subject, being the sole word on it.
Same VTE fact in a demo semt.002-shaped rendering (an institutional mapping preview). It is not validated against the real XSD and it is not an ISO 20022 export.
In this demo the balance is sent to the integration API, and the governance parties of the ledger can see it. The record shared with the counterparty is a pass/fail and a salted digest of the value.
In this demo the balance goes no further than the band calculation. What is sent onward is a tier index, not the value.
This step does not exist if the four modes are used separately.
Six more Daml choices layered on the case above. They are not four more answer shapes; they are what makes the four above safer to rely on.
Each card below calls its own real endpoint against the same Canton participant. Most need the case above to have run at least VTE Reveal and Compose first.
A composed package can sit unused while the subject's books move on. This re-checks the package against the subject's CURRENT book commitment, right now, and issues a time-boxed receipt - instead of a third party trusting a package that may already be stale.
Several signers is not the same as several separate controllers - one operator can hold every key. This attests whether the parties behind a registry really sit on distinct topology roots, or share one, using the same identifier Canton itself uses to tell participants apart.
Honest expectation: this demo runs every party on ONE shared participant, so a strict check here is expected to reject - that is the mechanism correctly detecting this deployment's own single-root Sybil residue, not a bug.
Composing a package is the step that travels to a third party, and until today it was the only one of the three provisioning surfaces with no cap. This gives it one: a budget the composer must claim a slot from before it can compose, same pattern already audited twice for VTE Match and VTE Trade Check.
The rule says the decision to rely on this evidence stays with the client, never VERIDEX. Until today that lived only in a string and a contract clause. This is a receipt signed ONLY by the client (VERIDEX cannot even gate its creation) recording that decision, under the client's own responsibility.
What each mode discloses has lived in code comments and audit PDFs, never in something a third party could cite. This publishes it on the ledger, co-signed by governance and versioned - the fixed reference a real leak-vs-declared comparison needs to exist against.
VTE Reveal and VTE Policy are attested, not proven - the real cryptographic proof is future work. This reserves the exact field names a future cryptographic verifier would bind to, on a real fact, so nothing needs to migrate if such a proof is ever added.
Honest limit: proofSystemId stays "ATTESTED_SECP256K1_QUORUM" today - this is a nomenclature reservation, not a claim that a proof exists yet.