Comparison with other systems
Eighteen products and platforms whose customers have problems that overlap with this stack, read from their own specifications, announcements and regulatory filings on 2026-09-05. The result is not a scorecard. It is a list of the axes on which a difference can be stated, the axes on which somebody else is ahead, and the sentences this project may and may not say as a consequence.
source: zkfmi-crypto/docs/research/COMPETITORS_EX_CANTON_2026-09-05.md · CANTON_NETWORK_2026-09-05.md · CANTON_FABLE_5_1_MAX_REVIEW_2026-09-05.md · COMPETITIVE_DECISIONS_2026-09-05.md (v1.2) · docs/strategy/ZKFMI_STRATEGY_2026-09-05.md · 54 distinct primary sources for the survey, 37 of 38 URLs re-opened for the Canton review
How to read the stage labels
| label | meaning here |
|---|---|
| commercial case announced | an operator or adopter says the target workflow ran. Not an independent operational audit. |
| mainnet / alpha announced | a network stage. Distinct from commercial delivery in a regulated market. |
| adoption / demonstration / planned | kept at the stage the announcement states. A planned date passing does not make it live. |
| specification confirmed | the operating model was checked in documentation. A particular deployment's status is unverified. |
| unverified | not confirmed in the materials read. Different from unimplemented or unsupported. |
zkFMI's own baseline, read the same day: research software on one host, with smoke evidence for two fills settled in one transaction and for two continuous trading rounds. Asset identifiers and settlement metadata on the native note path are public. Post-quantum hybrids were standalone at that date and have since passed a single-host integration acceptance; see Post-quantum migration. Aethel is excluded from the eighteen because it is an application on the stack, not a competitor.
All eighteen against zkFMI
One card per target, Canton included, and zkFMI last under the same four questions, the ones the comparison found decisive. Green means the property holds in the documented standard path, amber that it holds in part or depends on the application, grey that it does not or is out of scope. Under each card is the one sentence that distinguishes zkFMI from that target. It is a difference, not a ranking: on stage, every target is ahead of zkFMI.
Canton (in depth)
mainnet 2024, commercial repo platform, live Treasury trade, three Japanese PoCs- operator does not see the order
- no, own validator and application read plaintext views
- rules verifiable by an outsider
- relevant parties re-execute Daml; no portable proof in the standard path
- reservation → atomic settlement
- yes, Token Standard allocations, one transaction, in plaintext
- settlement hides amount and price
- from unrelated parties and synchronisers only
difference from zkFMI Canton limits who reads the plaintext; zkFMI withholds the complete order from every computing node under a 2-of-7 bound and lets an outsider verify the rule from a proof. Canton is ahead on everything else, and could host a zkPI verifier.
Renegade
mainnet, Arbitrum One- operator does not see the order
- the delegated relayer reads them; a self-run relayer avoids it
- rules verifiable by an outsider
- matching correctness is proved; the order set and admission order are not
- reservation → atomic settlement
- match settled on-chain; no advance reservation described
- settlement hides amount and price
- confidential wallet state
difference from zkFMI Midpoint crossing at an external price versus price-time priority or RFQ over a finalised admission order; a relayer boundary versus participant-side splitting; no eligibility or reservation leg.
Prime Match
live at J.P. Morgan, 2023 paper- operator does not see the order
- a semi-honest bank hub between two clients
- rules verifiable by an outsider
- no
- reservation → atomic settlement
- bank pipeline
- settlement hides amount and price
- bank sees it
difference from zkFMI Two-party inventory matching with the bank in the middle and no settlement leg; zkFMI is seven-node, provable and settled. Prime Match is the prior that refutes any "first" claim.
Penumbra
specification confirmed; sealed-bid batches are a future feature- operator does not see the order
- swap inputs and amounts are public in the current specification
- rules verifiable by an outsider
- chain-verified batch execution
- reservation → atomic settlement
- no reservation concept
- settlement hides amount and price
- transfers and claims yes, swaps no
difference from zkFMI A per-block batch auction with public swap inputs versus a continuous secret book or RFQ. Unlinkable wallets and secret prices are different rows and Penumbra has the first, not the second.
Dusk
mainnet specifications, NPEX collaboration- operator does not see the order
- model dependent; the exchange path uses public accounts
- rules verifiable by an outsider
- chain validation
- reservation → atomic settlement
- DvP designs described
- settlement hides amount and price
- confidential transfers optional
difference from zkFMI A confidential ledger for regulated assets without confidential market computation; zkFMI adds the venue and the proof of best execution. Neither has a licensed clearing house behind its clearing code.
Arcium
mainnet alpha- operator does not see the order
- MPC, confidentiality with one honest party
- rules verifiable by an outsider
- application defined
- reservation → atomic settlement
- application defined
- settlement hides amount and price
- application defined
difference from zkFMI A general MPC platform, dishonest-majority with abort; zkFMI is one specific workflow, admission to settlement, on honest-majority MPC. The same workflow could be built on Arcium, which is the alternative to evaluate.
Zama
mainnet 2025-12, a sealed-bid auction 2026-01- operator does not see the order
- FHE; decryption by a threshold KMS, t < n/3
- rules verifiable by an outsider
- input proofs of knowledge and coprocessor signatures, not a proof of the business result
- reservation → atomic settlement
- application defined
- settlement hides amount and price
- application defined
difference from zkFMI Encrypted-state computation with a separate decryption authority versus MPC with proofs; a platform versus a workflow. Cost and completion behaviour under one workload are unmeasured on both sides.
Aztec
alpha V5; proving-system vulnerability disclosed 2026-08- operator does not see the order
- client-side proving, the witness never leaves the client
- rules verifiable by an outsider
- for the client's own transaction
- reservation → atomic settlement
- application defined
- settlement hides amount and price
- private state
difference from zkFMI One party proving over its own secrets versus several firms computing over each other's; zkFMI's matching needs the second. Neither is audited.
Hyperledger Fabric
specification confirmed, widely deployed- operator does not see the order
- authorised peers read the private data
- rules verifiable by an outsider
- no
- reservation → atomic settlement
- chaincode
- settlement hides amount and price
- hidden from other organisations only
difference from zkFMI Access control decides which organisations see the data; zkFMI is for the case where the computing organisation itself must not. Where that case is absent, Fabric is the simpler answer.
R3 Corda
adopted for CSD Prague settlement- operator does not see the order
- participants see; a non-validating notary sees state references
- rules verifiable by an outsider
- participants validate, no outside proof
- reservation → atomic settlement
- contract state and uniqueness
- settlement hides amount and price
- from non-participants
difference from zkFMI Limited sharing among the parties to a contract, no confidential computation and no proof of a market rule; a large adoption record. An integration candidate for the zkPI.
Kinexys
commercial, JPM Coin on Base 2026-04- operator does not see the order
- the bank
- rules verifiable by an outsider
- no
- reservation → atomic settlement
- bank-run workflows
- settlement hides amount and price
- the bank
difference from zkFMI A bank's own payment and tokenisation service with customers; zkFMI has no cash leg and would need one like it.
Fnality
sterling system operating under Bank of England limits- operator does not see the order
- the system operator
- rules verifiable by an outsider
- no
- reservation → atomic settlement
- payment arrangements
- settlement hides amount and price
- operator
difference from zkFMI Central-bank-backed digital cash; the cash leg zkFMI lacks. No secret price formation is intended.
Partior
live payments- operator does not see the order
- participating banks
- rules verifiable by an outsider
- no
- reservation → atomic settlement
- PvP; a DvP proof of concept
- settlement hides amount and price
- banks
difference from zkFMI Bank-network PvP with plaintext among members; zkFMI's PvP passes a scalar by adaptor signature between ledgers that share nothing. Candidate cash leg.
Ownera / FinP2P
APIs and orchestration plans published- operator does not see the order
- each institution's router
- rules verifiable by an outsider
- signatures and receipts
- reservation → atomic settlement
- intents, holds, orchestration per ledger capability
- settlement hides amount and price
- routers
difference from zkFMI The closest to where zkPI sits: it coordinates instructions across ledgers in plaintext with signatures. zkPI binds a proof of hidden propositions to the instruction. "Connecting ledgers" is not the difference.
Swift shared ledger
ready for initial use 2026-07, pilots preparing- operator does not see the order
- Swift and the banks
- rules verifiable by an outsider
- no
- reservation → atomic settlement
- commitments between banks, final settlement in existing systems
- settlement hides amount and price
- banks
difference from zkFMI Interbank coordination of tokenised deposits at Swift's scale; nothing hidden from the banks, nothing computed. Monitor.
Chainlink
features described 2026-05- operator does not see the order
- plaintext inside a TEE
- rules verifiable by an outsider
- oracle-network signatures
- reservation → atomic settlement
- cross-chain messages
- settlement hides amount and price
- private tokens described
difference from zkFMI Trust placed in hardware enclaves and a signing network versus MPC and proofs; the word "verifiable" covers different things. A candidate carrier for a zkPI.
Progmat
commercial ST issuance; Avalanche L1 migration announced; JGB repo PoC on Canton- operator does not see the order
- issuer, trust and distributor
- rules verifiable by an outsider
- no
- reservation → atomic settlement
- ST practice on the platform
- settlement hides amount and price
- the roles
difference from zkFMI Japanese security-token issuance and administration in production; zkFMI would be an add-on for eligibility and collateral computation hidden from those roles. Priority Japanese comparison.
BOOSTRY / ibet for Fin
operating since 2021- operator does not see the order
- consortium members
- rules verifiable by an outsider
- no
- reservation → atomic settlement
- standard contracts
- settlement hides amount and price
- members
difference from zkFMI A member-run Japanese ST network with standardised contracts; the same add-on relation as Progmat.
zkFMI
research, one host, one administrator- operator does not see the order
- no node holds a complete order, at most two of seven malicious; traffic observable
- rules verifiable by an outsider
- zkPI verifier and quote proof, for the stated order set, not the whole market
- reservation → atomic settlement
- maker and taker reservations, batch DvP, smoke evidence
- settlement hides amount and price
- amount and price hidden; asset tag and metadata public on the native rail
difference from zkFMI The composition: secret from the computing nodes, rule proved to an outsider, reservation carried unopened into settlement. No production, no independent operators, no audit.
Read the first two questions across the cards and the shape of the field appears. The institutional rows are grey on both because they are built for a world where the operator is trusted; the infrastructure rows are green on the first and amber on the second because they leave the workflow to the application; the trading rows split. zkFMI is green on both, and grey on stage, which is the whole position in one line.
Nine decisions
The comparison closes on nine numbered decisions. They were reviewed a second time, at maximum effort, with Canton added; all nine were retained and several gained evidence.
| # | decision | why | consequence |
|---|---|---|---|
| C01 | MPC, ZK and a proof that fills were computed correctly do not make zkFMI unique | Renegade's VALID MATCH proves input validity and matching correctness. Canton has the relevant participants re-execute Daml rules. Prime Match ran financial MPC in 2023. | never market "only we can prove market rules" |
| C02 | The promising axes are who learns which secret and which rules and states are bound to the same transaction | Renegade's delegated relayer reads the wallets it serves. Canton's host validator reads all of its parties' data. OCLOB splits on the participant's side, so no single node holds an order, under a 2-of-7 collusion bound. | first establish which disclosure a customer accepts; target the projects that need secrecy from the computing entities themselves |
| C03 | Price formation differs, and that is not superiority | Renegade documents midpoint crossing at an external price. QOMM is RFQ over confidential pricing rules; OCLOB is price-time priority over a finalised admission order. | no "speed ranking" that mixes RFQ, continuous books and midpoint crossing |
| C04 | zkFMI is not uniformly stronger in secret-sharing security | Arcium's Cerberus keeps confidentiality with one honest party and aborts on deviation. Zama's KMS completes key operations with t < n/3. OCLOB assumes at most two of seven malicious. | state confidentiality, correctness, completion and operator independence as four separate claims |
| C05 | Instruction standards, DvP and cross-ledger coordination already exist | Ownera describes intents, holds and orchestration. Corda verifies contract state and uniqueness. Canton's Token Standard (CIP-0056) standardises allocations and one-transaction settlement of all legs. | propose zkPI as verification that can be added to existing contracts. Atomicity itself is not the claim. |
| C06 | zkFMI is a research MVP with real function and a maturity gap | Two fills in one transaction and two continuous rounds are smoke evidence on one host. Canton has a mainnet, a commercial repo platform, a multi-firm pilot, a live Treasury trade and launched PoCs. | next priorities are continued use, consistency under failure and independent operation. Do not understate the other side's maturity. |
| C07 | In Japan, connecting to existing securities workflows and to a cash leg may be a condition of adoption | Progmat, ibet for Fin, Kinexys and Fnality publish adoption records. MUFG and Progmat started a JGB repo PoC on Canton in August 2026; JSCC, Mizuho and Nomura a JGB collateral PoC in April. | the first adoption demonstration is an integration, not a replacement |
| C08 | System-wide quantum resistance is not yet a competitive advantage | Standalone hybrids and now the merged main branches of all eight repositories do not cover commitments, proofs, stored state or every transport. Competitors' PQC status is unverified, not absent. | offer PQC as a migration plan per boundary |
| C09 | Canton is at once the priority competitor and a candidate platform or integration destination | Daml holds business logic, authorisation and disclosure; synchronisers can be global or private. Wiring external MPC results or a zkPI verifier into a Daml app is a design inference, not a verified implementation. | keep the standalone DeFMI L1, QOMM, OCLOB and DeCCP objectives; evaluate a Canton integration at the second gate |
The shorthand used elsewhere on this site, "others prove circuits, we prove markets", is a description of what the quote proof states. It is not, on its own, evidence of novelty, and the comparison retired it as such.
Canton, the closest comparison
Canton is not one product. It is a protocol, a set of synchronisers, validators that host parties, and Daml applications written by third parties. Reading any Canton case as evidence for all Canton capabilities was the most common error found in the earlier drafts, so the layers come first.
| layer | what official materials confirm | keep separate from |
|---|---|---|
| Canton Network | independently operated applications, validators and several synchronisers connected together. Each validator stores only the ledger fragments of the parties it hosts. | one firm's Canton project as evidence that the whole network's capabilities are live |
| Daml application | contracts define business logic, signatory/observer/controller roles, authorisation and disclosure. They execute on validators. | properties of the foundation versus order, credit, reservation and clearing rules that each application implements |
| validator (participant node) | hosts parties, stores their contracts, decrypts and validates the transaction views addressed to them | the public-chain sense of "validator" in which every validator reads every transaction |
| synchroniser | the sequencer orders and delivers encrypted messages; the mediator collects confirmations from the relevant validators and declares commit or reject. Neither validates Daml contents. | ordering and confirmation versus validation of business logic and input correctness |
| Global Synchronizer | a public synchroniser run by Super Validators with CometBFT ordering, tolerance f = ⌊(n−1)/3⌋, traffic paid by burning Canton Coin, sponsorship required to join. Applications may instead use private synchronisers. | the assumption that every Canton application runs through it |
| application provider | supplies on-ledger Daml and off-ledger logic, authentication and submission | protocol guarantees versus trust that the provider admits, selects and submits inputs honestly |
Who reads what
Canton splits a transaction into views and encrypts each for the participants of its informees. Unrelated parties receive nothing and synchronisers cannot decrypt. That is sub-transaction privacy: plaintext shared only with the parties that need it. It is a different guarantee from the one this stack aims at, which is that no computing node holds a complete order within the tolerated collusion bound.
| entity | can read | cannot read |
|---|---|---|
| party (signatory, observer, controller) | views it is an informee of; divulgence may expose contracts it is not a stakeholder in | payload and party metadata of unrelated views |
| the party's own validator | the trust model states it "sees all your data and could block you". External party keys keep signing authority with the party but are not described as removing visibility. | |
| counterparty | plaintext of the shared views, trusted not to leak them | |
| application provider, off-ledger components | implementation dependent. An off-ledger matching engine may handle plaintext orders. | |
| sequencer | encrypted envelopes, recipients, order, size, timing | contents |
| mediator | each view's informee list, confirmation policy, each approve or reject | contents |
| unrelated parties and validators | nothing | |
| auditor | plaintext of the relevant views if designed in as an observer | a portable proof of a proposition without receiving the secrets is not part of the documented standard path |
This is a design choice with a stated reason, not a gap in documentation. The 2020 Canton whitepaper says advanced cryptography including MPC is computationally expensive and that Canton limits visibility under stronger trust assumptions instead; a 2025 official post calls zero-knowledge proofs for general privacy experimental. Nothing prohibits a Canton application from calling external MPC or verifying an external proof, so the difference is between the documented standard path and this stack's path, and cannot be written as "impossible on Canton".
Axis by axis
| axis | Canton, confirmed scope | zkFMI, current position | judgment |
|---|---|---|---|
| who learns the secret | hidden from unrelated parties and synchronisers; host validator and entitled parties read the relevant views | participant-side splitting, no MPC node holds a complete input; collusion of three or more nodes and traffic observation remain limits | a difference can be shown and it shrinks to nothing if the customer is content to disclose to its own validator |
| computation hidden from the computing entities | the standard path decrypts views and re-executes Daml in plaintext | seven-node MPC, at most two malicious, research implementation | candidate external MPC on Canton is a design option with no verified implementation; superiority undetermined until compared under one workflow, collusion bound, availability and cost |
| eligibility, credit, reservations | Daml can express and verify all three; reservation-based settlement is already standardised by CIP-0056 allocations, in plaintext | DeKYX eligibility, maker and taker reservations, guarantee capacity across the end-to-end path | not a feature difference the difference is whether the order-to-reservation correspondence is hidden from the matching nodes or read by registry, app and validator |
| market rules | parties validate deterministic Daml logic; an identical CLOB or RFQ application is unverified, the one documented trading app is an AMM that submits swaps off-chain | QOMM RFQ and OCLOB price-time priority computed in MPC, bound into the zkPI | buildable on Canton in principle; not shown to exist |
| input set | binds the contracts a submitted transaction references; completeness of off-ledger admission is at the application boundary | aims to bind admission order and order set into the proof; pre-admission censorship remains possible | neither proves "the whole market"; compare admission commitments and target sets |
| settlement atomicity | cross-application DvP in one Daml transaction on a common synchroniser; across synchronisers, reassignment then atomic settlement, with assets pending in between | smoke evidence for multi-fill batch settlement on the native rail | no zkFMI claim until compared with the same legs including external ledgers |
| third-party verification | relevant validators check their views; an auditor can be an observer | a zkPI verifier checks defined propositions without the secrets | potential value not exclusive, since a zkPI verifier could sit inside a Daml application |
| operational trust | own or outsourced validator, counterparties, application provider, synchroniser, Foundation governance | MPC nodes, coordinator, read-back service, DeFMI validators; independence of keys and operators not accepted | compare who is responsible for confidentiality, correctness, availability, censorship and recovery; not node counts |
| maturity, performance, legal frame | mainnet since 2024-07, protocol upgrades live, commercial repo platform, one live Treasury trade, three Japanese PoCs launched | single-host research MVP, smoke evidence | do not understate Canton performance under equal conditions, demand and authorisation are unverified on both sides |
| post-quantum | unverified | hybrid signatures and KEM on the merged main branches of all eight repositories; ZK relations classical | mark unverified, claim neither direction |
Cases, at the stage their sources state
| case | stage in primary sources | do not generalise to |
|---|---|---|
| Global Synchronizer | go-live 2024-07-01; Canton 3.5 logical synchroniser upgrade live 2026-06-29 | usage, SLOs or authorisation of any individual application |
| Canton Network Pilot | 2024-03-12: 22 dApps, more than 350 simulated transactions on TestNet; 45 participants in the summary, 36 in the role-by-role body | production assets or continuing commercial trading |
| Broadridge DLR | migrated to Canton in 2023 with cash off-chain (2024 customer story); self-reported average daily repo of $280bn in August 2025 | Global Synchronizer use, on-chain cash, a confidential order book |
| Tradeweb | 2026-07-01: one transaction, tokenised US Treasuries against USDCx, synchronised on-chain settlement | sustained capacity or a full lifecycle |
| DTCC | plan to mint a subset of DTC-custodied Treasuries on Canton; MVP planned for a controlled production environment in the first half of 2026, completion unverified | commercial launch |
| JSCC / Mizuho / Nomura | 2026-04-20: PoC for digital JGB collateral management, keeping JGBs' legal status under the book-entry transfer law; selected for the FSA's Payment Innovation Project | completion, end date, commercialisation |
| MUFG / Progmat / Secured Finance | 2026-08-13: PoC to bring JGB repo on-chain, account management institutions updating their transfer books alongside the chain, tokenised deposits or stablecoins as the cash leg | completion or legal delivery |
| Progmat / DCC working group | launched 2026-05, report targeted for 2026-10 | a platform choice |
The Japanese PoCs matter for this project specifically. They sit in the workflows the application survey ranks highest, collateral and repo, and they keep the JGB inside the book-entry system exactly as the regulation page says a Japanese deployment must. The strategy therefore does not propose replacing those workflows. It looks for the parts inside them that need an input hidden even from the computing entity: the order, the rate quote, the collateral allocation.
Group by group
The notes behind the table, for the seventeen other than Canton. Priority is a judgment of relevance to a build, buy or connect decision, not a market-share ranking. "Integration candidate" means a plausible destination for a zkPI, not an existing integration; none exists.
Institutional ledgers, cash legs and connectivity
| target | competing task | confidentiality and trust boundary | stage | treatment |
|---|---|---|---|---|
| R3 Corda | asset state and inter-institution workflow | sharing among relevant parties; a non-validating notary sees input-state references, not full contents | adopted for CSD Prague's DLT settlement; a separate "Corda protocol" for Solana was planned for H1 2026 and is not the ledger product | priority comparison, integration candidate |
| Kinexys (J.P. Morgan) | bank payments, tokenisation, fund flows | bank-operated; distinct from hiding inputs from the bank | JPM Coin on Base and a first fund-flow transaction announced 2026-04-28 | institutional comparison, cash-leg candidate |
| Fnality | institutional digital cash | backed by central-bank account funds; secret price formation not its focus | sterling system in the Bank of England's FMI report, operating under limits | cash-leg candidate |
| Partior | cross-border payments, FX PvP | network of participating banks; confidential market computation unverified | live payment cases; a DvP proof of concept | cash-leg and PvP candidate |
| Ownera / FinP2P | asset distribution and settlement instructions across ledgers | routers per institution, adapters, agreement among participants; depends on the underlying ledgers' hold and atomic capabilities | APIs and orchestration plans published | priority comparison, the reference for integration design; closest to where zkPI sits |
| Swift shared ledger | interbank payment coordination, tokenised deposits | a shared layer run by Swift, bank ledgers on the side, final settlement through existing systems | ready for initial use 2026-07-09, banks preparing live pilots | monitor |
| Chainlink CCIP, CRE, ACE | external data, policy and cross-chain execution | oracle networks, TEEs and distributed key generation; plaintext inside a TEE is a different trust placement from MPC or ZK, whatever the word "verifiable" is applied to | privacy features and cases described 2026-05 | integration candidate and comparison for zkPI |
| Progmat | Japanese security-token issuance and administration | issuer, trust and distributor roles; hiding inputs from all of them unverified | ST project list; provider announcement of a completed migration from Corda to a dedicated Avalanche L1; a tokenised investment-trust demonstration without external sales, chain unstated | priority Japanese comparison, integration candidate |
| BOOSTRY / ibet for Fin | Japanese STs, consortium operation | member-run network, standard contracts | operation launched 2021-06; body text of the consortium page could not be extracted | priority Japanese comparison, integration candidate |
The common lesson from this group: connectivity and customer relationships, not cryptography, are the barrier. A zkPI adds something only if the receiving ledger verifies the proof; a receiver that accepts a signature or a digest has turned the guarantee back into trust in the signer. The six problems every instruction source has to solve on the applications page is the list of what a destination must be able to do.
Confidential orders and confidential asset trading
| target | market and verification | confidentiality and trust boundary | stage | treatment |
|---|---|---|---|---|
| Renegade | pairwise MPC produces a collaborative SNARK (VALID MATCH: valid inputs, correct matching, encrypted outputs); midpoint crossing at an external price; balances updated on-chain | the relayer a customer delegates to reads that customer's orders and balances in plaintext; other relayers do not; a customer may run its own relayer | mainnet on Arbitrum One | priority comparison for OCLOB. The difference is the delegation boundary, price-time priority over a finalised admission order versus midpoint crossing, and continuity from fill to reservation to settlement. Whether Renegade proves that no eligible order was omitted was not audited and is not asserted. |
| Prime Match (J.P. Morgan) | MPC inventory matching between a bank and its clients | bank-and-client threat model set by the authors; not this stack's node topology | live operation reported in the 2023 paper; 2026 status unverified | prior work; refutes any "first financial MPC" claim. Full treatment on the prior-art page. |
| Penumbra | shielded pool, per-block batch swaps | swap input assets and amounts are public in the current specification; sealed-bid batches are a stated future feature | specification confirmed | monitor market design. Wallet unlinkability and pre-execution price secrecy are separate rows and must not be merged. |
| Dusk | ledger for regulated assets with confidential transfers and selective disclosure | model dependent; the exchange integration guide specifies a public account model | mainnet specifications; collaboration with NPEX | monitor securities workflow. A partner's licence does not extend to applications on the chain; the same standard applies to DeCCP, whose code is not a licensed CCP. |
Confidential computation and application infrastructure
| target | provides | confidentiality and trust boundary | stage | treatment |
|---|---|---|---|---|
| Arcium | general-purpose MPC execution environments on Solana | Cerberus: dishonest majority, confidentiality with one honest party, detect-and-abort; availability is a separate condition | mainnet alpha | priority comparison and a procurement option. "We have seven nodes, they are centralised" does not hold; building the same workflow on Arcium is an alternative to evaluate. |
| Zama | FHE over encrypted state, confidential tokens, threshold KMS | computation, decryption authority and key management are separate; the KMS assumes a strong honest majority t < n/3; the coprocessor separates input proofs of knowledge, FHE evaluation, commitments and signatures | mainnet 2025-12-31, a sealed-bid auction in 2026-01 | infrastructure comparison alongside Arcium. Do not read its input proofs as a proof of a whole business result, and do not claim only zkFMI has external verification. |
| Aztec | private and public applications on an Ethereum L2 with client-side proving | private witnesses stay on the client; not joint computation over several firms' inputs | Alpha V5; a critical proving-system vulnerability disclosed 2026-08-07 with a fix planned for V6, completion unverified | monitor. This stack has no independent audit either and gains nothing from a competitor's alpha status. |
| Hyperledger Fabric | permissioned ledger, private data collections | actual data to authorised peers, hashes to the channel; orderers receive no private data. Limits which organisations read; does not hide inputs from the authorised peers | specification confirmed | the in-house alternative. Where secrecy from everyone is not required, existing governance plus Fabric may be the clearer choice, and the case for zkFMI must be made from the boundary access control cannot reach. |
The same standard applied to this stack
The comparison read this project's own documents with the same rules, and fixed the results by SHA-256 in a baseline file so that later drift cannot improve them retroactively.
| item | judgment | evidence and limits |
|---|---|---|
| separation of orders from the MPC nodes | design and implementation of the participant-side path confirmed | seven nodes, coordinator never sees an order; the browser-compatible demo still holds plaintext |
| settlement of several fills | confirmed from existing artifacts | two fills, one transaction, fourteen confirmations, roots agree across five validators and a restart; not rerun for the comparison |
| continuous trading | smoke only | two rounds and three fills; cancellation, expiry, reuse of returned assets, restart of seven MPC nodes; the earlier rejected run is kept in the ledger |
| ledger finality | trust in the read service remains | each node reads back but does not verify an independent consensus proof |
| settlement confidentiality | not every field | asset identifiers and settlement metadata on the native rail are public |
| identity and eligibility | pseudonymous within a scope | DeKYX is not issuer-unlinkable and is not a certified KYC product |
| clearing | research state machine | DeCCP is neither a custodian nor a licensed clearing house |
| cryptographic security | fixed defects distinct from unaccepted guarantees | a note-proof defect was found and fixed; the Triptych dependency is experimental; no independent audit |
| QOMM economics | confirmation experiment not passed | synthetic-data smoke; no claim of price improvement or customer benefit |
| independent operation | false | one host, one administrator, no WAN |
Wording this project uses, and wording it refuses
| sentence | status | condition, or what to say instead |
|---|---|---|
| "a research implementation that connects confidential order admission, price-time priority matching, advance reservation and proof-carrying settlement" | used | with the path and the single-host scope stated |
| "two fills settled atomically in one transaction" | used | with the run's conditions and artifact; never as capacity |
| "aims to let an outsider verify that a stated order set, the rules and the settlement agree" | conditional | naming the propositions the verifier checks and the residual trust in signers and read-back |
| "the first financial MPC" / "the only MPC-plus-ZK settlement" | refused | Prime Match and Renegade precede it |
| "competitors prove circuits, we prove market rules", as evidence of novelty | refused | Renegade proves matching; Canton's participants validate Daml rules. Name the concrete function, set, authorisation and settlement that differ. |
| "Canton cannot do orders, eligibility or reservations" / "Canton has no atomic DvP" | refused | both exist; compare documented individual applications |
| "seven nodes, therefore stronger than Arcium" | refused | the honesty assumptions differ |
| "a confidential ledger hides everything, including asset types, traffic and identities" | refused | asset tags on the native rail are public; traffic is observable; DeKYX is linkable by its issuer |
| "production FMI or CCP" / "the whole system is quantum-resistant" / "faster than competitors" | not yet | needs institutional evidence, evidence covering every cryptographic path, and measurements under equal conditions respectively |
What zkFMI must show before claiming a difference
These are verification tasks for this project, derived from the comparison. They are not a list of anyone else's weaknesses.
| candidate proposition | evidence required | measured against |
|---|---|---|
| orders and pricing rules hidden even from the operator | the list of entities with visibility from participant-side share generation through MPC to settlement; collusion conditions; every plaintext point; key administrators | Renegade, Arcium, Prime Match, Canton |
| execution rules verifiable afterwards | propositions binding the order set, admission order, eligibility, price-time priority and partial fills, with an independent verification procedure | Renegade, Penumbra, market apps on Zama, Daml apps on Canton |
| computation result equals delivery | the same commitment bound through computation, instruction, reservation and consumption of both legs; state unchanged by retry or double spend | Ownera, Corda, Chainlink, Canton Token Standard |
| adoptable by an institution | issuance, custody, registration and cash-leg responsibilities; recovery; supervisory disclosure; entry and exit; legal finality | Kinexys, Fnality, Partior, Swift, Progmat, ibet for Fin, Dusk, Canton |
| long-term confidentiality and verifiability | a threat model separating signatures, KEM, commitments, proofs, TLS and stored data, with migration, revocation and re-verification paths | every adopted configuration |
What the comparison changed
The strategy that follows from the nine decisions is short. The first use case is institutional secondary trading of digital securities where an order must stay hidden from the computing entities, meaning the organisation's own validator, the application operator and the matching engine, until its order in the book is fixed. The first thing offered is an integration module: confidential matching, advance reservation and a zkPI verifier added to a ledger the customer already runs, with the standalone DeFMI L1 kept as the reference path. Canton and Renegade are the comparisons for markets and settlement, Arcium and Zama for confidential computation, Ownera for integration design.
Before any of that, the first gate is a customer question, not a build: does at least one organisation document that it needs inputs hidden from its own validator and matching engine? If the answer everywhere is that disclosure to one's own validator is acceptable, a Canton-style design suffices for those customers and the initial use case is wrong. The comparison names that as the condition under which the strategy is revised, and it has not been tested.
When these conclusions change
- acceptance receipts for continuous trading, cancellation, expiry, contention, recovery and independent operation (C02, C06);
- an explicit mapping of the same admission set, ordering, eligibility, reservations and settlement onto Canton or Renegade (C01, C03, C09);
- the same end-to-end path run on Arcium or Zama with measured differences in output, confidentiality scope, cost and failure behaviour (C04);
- a destination ledger confirming APIs, hold, commit, abort and read-back and the allocation of legal responsibilities (C05, C07);
- migration receipts covering components beyond signatures and key exchange (C08);
- any change in a vendor's version, stage or fix notice, which requires rereading the source before reuse.
What this comparison did not do
It did not run a Canton node, use a competitor's application, benchmark anything, audit anyone's code, interview a customer or write to any external system. Some sources could not be read in full: the Renegade whitepaper returned a server error, the Canton pilot PDF exceeded the retrieval limit and was replaced by the official announcement of the same content, the Tradeweb investor page timed out and was replaced by Canton's republication, and the ibet for Fin consortium page yielded only its search summary. Each substitution is recorded in the source documents, and nothing unread is treated as read. The comparison is dated; a stage label from 2026-09-05 describes that day.