Applications beyond venues
QOMM is one instruction source: a venue that decides a price and issues an instruction. Any other business system that decides who may move what, under which conditions, can put that decision on a zkPI and let DeFMI settle it without reading the inputs. No secret quoting, no MPC pricing, no maker and taker required.
source: defmi/doc/ja/DEFMI_ZKPI_USE_CASES.md (survey dated 2026-08-30)
When the shape fits
Three conditions together make a business a fit.
- Before settlement, eligibility, limits, collateral or contract terms must be checked.
- The personal data, holdings, amounts or internal decisions used in that check must not be shown to every settlement participant.
- Once conditions are met, neither leg may execute alone and no instruction may be used twice.
flowchart LR
F["fund administrator
eligibility and units"]
C["collateral and risk engine
required margin"]
B["bank and sanctions check
authorises a cross-border payment"]
R["registrar, issuer, custodian
approves a transfer of rights"]
F --> Z["zkPI
carries the decision and its proof"]
C --> Z
B --> Z
R --> Z
Z --> D["DeFMI
verifies once, settles once"]
D --> A["cash, deposits, securities, units, collateral
two rights updated together"]
Ranked
| # | use | who issues the zkPI | nearest prior art | the difference to test |
|---|---|---|---|---|
| 1 | Fund subscription, redemption, capital calls | transfer agent, fund administrator and KYC provider jointly: eligibility valid, amount within rules and per-investor cap, cash reserved, units available, NAV point fixed | Project Guardian (MAS) has automated subscription and payment on DLT | eligibility, individual caps and amounts hidden from settlement participants; a one-time instruction from a separate fund system settled by an operator-less ledger |
| 2 | Collateral and margin: pledge, substitution, return | a collateral engine with approved eligibility, haircut and concentration circuits; proves the portfolio covers the requirement without showing it | tri-party collateral, CCP margin calls | coverage proved over a secret portfolio; ordering of concurrent calls and per-entity caps in authoritative state |
| 3 | Interbank and cross-border PvP | two issuers and two cash reservations bound in one instruction; sanctions and authority checks carried as proofs | Fnality, Partior, mBridge, Project Agorá | adaptor-signature PvP with unrelated signatures per ledger; exposure window set by finality, not proofs |
| 4 | Issuance, redemption, coupons, dividends | issuer and paying agent | digital bond programmes (SDX, eWpG registers) | holder set and amounts hidden; conservation across a corporate action |
| 5 | Real estate and high-value asset transfer | registrar and escrow agent | title tokenisation pilots | DvP where the register is external and DeFMI mirrors it |
| 6 | Government and multilateral promissory notes, contributions, subsidies | treasury and disbursing agent | — | conditional disbursement with eligibility hidden |
| 7 | Receivables and invoice finance | Aethel-style receivable system | supply-chain finance platforms | see the Aethel page |
| 8 | Environmental and commodity certificates: issue and retire | registry operator | carbon registries | retirement as a one-time nullifier; holder hidden |
| 9 | Insurance claims and benefit payouts | insurer and adjudicator | parametric insurance | claim conditions proved, claimant data withheld |
The first is the most practical product: two things move together, which is DeFMI's DvP unchanged, with few roles. The second is the strongest research topic: coverage proofs over a secret portfolio. The third is the largest long-term business.
Two cross-border scenarios that must not be confused
- Intra-group PvP/DvP. Parent, subsidiaries and an in-house bank share rules and an authority hierarchy, so one participant module can connect accounting, treasury and custody and pass approved instructions to DeFMI. It needs an encrypted durable queue so instructions survive an MPC outage: no local computation instead of MPC, no unproved send, idempotent resend by request id, original order preserved, no automatic extension of expired requests, and a return to fixed cadence with cover slots after recovery so the burst does not announce which requests were real.
- Independent parties with a stablecoin cash leg. Seller and buyer share nothing, so internal approval is not a trust basis. Each party's module binds its own KYB and signing authority, its own pre-reserved asset or USDC, the stablecoin's chain, contract, issuer, freeze and finality conditions at trade time, and one transaction id, amount and expiry across both legs. The stablecoin ledger is a swappable cash rail with its own failure state machine (reorg, expiry, issuer freeze), not a configuration change to intra-group settlement.
Six problems every instruction source has to solve
- Whose decision counts: which keys, which quorum, which governance.
- Making the proved condition and the settled object the same thing.
- Preventing concurrent instructions from exceeding a shared cap.
- Aligning failure with an external ledger: which fault breaks atomicity, and refusing to call the broken configuration DvP.
- Letting only the right party check later: scoped disclosure for dispute, audit and supervision.
- Defining the legal moment of finality.
What may be claimed
DvP on DLT, tokenised deposits and securities, pre-payment compliance checks, ZK compliance proofs and automated collateral or subscription are each individually not new. The combination to test is: separation of business decision from settlement across different instruction sources issuing one instruction type; settlement that does not reconstruct the source data; one-time rights that cannot be reused across instructions; cash, deposits, securities, units, collateral and certificates under one instruction boundary; distributed operation that still preserves issuer, registrar and clearing authority in the proof; and selective after-the-fact verification. "World first" is not claimed; the claim, if any, is the integrated construction and its security definition once the feature-by-feature comparison is finished.
Implementation order
- Fund subscription and redemption. Separate keys for issuer, administrator, investor and KYC. Eligibility, subscription cap, cash reservation and issuable units bound to the zkPI; cash notes and unit notes updated together; tests for concurrent over-subscription, expiry, replay and one-leg failure.
- Collateral and margin. Eligible collateral, haircuts and concentration limits as approved circuits; coverage proved without showing the portfolio; top-up, substitution, return; ordering of multiple calls and per-entity caps.
- Two-currency PvP. Two issuers and two reservations in one zkPI; issuer outage, expiry, restart and resend tests; ISO 20022 mapping in an external adapter so DeFMI's types are not fixed to one bank's message.
- External ledger connection. Mock fund, collateral and bank ledgers as independent processes; signed reservations and confirmed receipts; an explicit list of which faults break atomicity.
What exists today: typed zkPI, signature and proof verification, one-time identifiers, a note ledger that does not publish account names, same-ledger DvP and PvP, issuer authority, pre-reservation and reconciliation. All callable from an application other than QOMM. What does not exist: connections to a real fund administrator, CCP, bank, CSD or registrar; external KYC; physical HSMs; seven-site operation; legal finality; third-party audit.