TEST DEPLOYMENT: all 4 modes submit live through an integration API to a Canton participant operated by the VTE team. Synthetic data, demonstration sources. Not a pilot, not a production system.
VTE · Veridex Threshold Evidence Team-operated Canton participant
checking backend…

VTE · Veridex Threshold Evidence

Check a borrower's covenant without seeing the portfolio.

VTE answers one narrow question about a private position on Canton, and records the answer and its evidence on the ledger.

  • Is there enough collateral? The lender learns the collateral meets the 5,000 minimum, not the 5,600 behind it. (VTE Match)
  • Is there enough behind the drawdown to proceed? The counterparty reads pass or fail on the ledger itself, and never sees the value. (VTE Trade Check)
How the mechanism works
  1. Held by the custodian Ask The fund's balance sits with its custodian.
  2. Held by the custodian Consent Does it reach the amount asked for?
  3. Held by the custodian Answer Canton tests the attested amount.
  4. Goes to the counterparty Evidence Yes or no, checkable on the ledger.
Read the full explanation

What you're actually looking at

  1. The problem today

    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.

    Hand over the whole statement Reveals everything, including what nobody asked about.
    Take the fund's word for it Verifies nothing.
  2. The third option

    Northbridge asks a shared ledger one narrow question, and the ledger answers it.

    Does this account hold at least $10 million?

    • The asking party gets the answer, not the account.
    • The lender does not have to take Northbridge's word for it: it can read the recorded answer on the ledger itself. The ledger records what was attested and checks it for consistency. It does not verify that the figure is true.
  3. Four modes, not four products

    They are four shapes of answer that one mechanism produces about one attested position, so whoever is asking gets the shape they need. All four describe the same case, and the mechanism checks that they share subject, scope, epoch, governance parties and book. It compares values across modes only in a strict mode, which the full case does not use.

  4. Try it

    Pick a mode below. A real answer comes back in about a minute, from the ledger, not from this page.

What each answer gives away

One case, asked four ways. The only thing that changes is how much crosses. The grid shows what the asking party sees. In VTE Match the value never reaches the ledger. The ledger records one yes-or-no fact (above the lowest band or not) and the demo service names the band. In VTE Reveal the governance parties see the total and a random split of it, and the requesting party receives only the total. In VTE Policy and VTE Trade Check the governance parties of the ledger see the values.

What each answer gives away
Exact total Category mix Per-source split Pass / fail Band

The asking party sees the answer, not the account.

Each button opens a fresh case, runs the four ceremonies against the Canton participant in order, and composes the result.

Ask

Case

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.

Consent

The same case, asked four ways

The position
Who holds it -
What it is made of -

Does the total reach the amount we require?

Each row is a custodian's figure for the subject. In this demo one demonstration source reports every row, so the sum shows no independence between custodians.

-
disclosed total (factTotal)
view raw response
not submitted
LIVE: real Canton participant

What is that total made of?

-
disclosed total (grandTotal)

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.

Demo semt.002-shaped rendering, not validated against the XSD

              
view raw response
not submitted
LIVE: real Canton participant

Is there enough behind this trade to proceed?

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.

-
view raw response
not submitted
LIVE: real Canton participant

Which band does it sit in?

In this demo the balance goes no further than the band calculation. What is sent onward is a tier index, not the value.

-
view raw response
not submitted
LIVE: real Canton participant
Answer

Cross-mode composite result

This step does not exist if the four modes are used separately.

Strict value coherence
    view raw response
    New, 2026-08-26

    Five mechanisms layered on the case above

    Five more Daml choices layered on the case above. They are not four more answer shapes; they are extra checks and records around the four above.

    What each one adds, and what to run first
    • P1Re-checks a composed package against the subject's book as it stands now, not as it stood when the package was made.
    • P2Tests whether "several signers" really are several parties, or one controller holding every key.
    • P3Meters how many evidence packages get issued, so they cannot be minted without limit.
    • P4Gives the client its own record of its own decision, on the same ledger.
    • P5Publishes what each mode discloses, so the leak is stated rather than inferred.

    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.

    P1

    Revalidate at reliance

    P1
    not submitted

    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.

    view raw response
    P2

    Topology diversity

    P2
    not submitted

    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.

    Strict (reject if namespaces collide)
    Off checks and records the namespaces without rejecting; on enforces distinctness.
    view raw response
    P3

    Evidence issuance budget

    P3
    not submitted

    Composing a package is the step that travels to a third party. This gives it a budget the composer must claim a slot from before it can compose.

    Strict value coherence
    view raw response
    P4

    Client reliance decision

    P4
    not submitted

    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.

    view raw response
    P5

    Leak baseline declaration

    P5
    not submitted

    What each mode discloses has lived in code comments and an evidence package, 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.

    view raw response