Skip to main content
Musubi settles cross-border stablecoin FX (JPYSC0 ↔ USDCx) between institutional participants. The hard parts of that problem are structural: deliver both currency legs with no timing or counterparty risk, keep each party’s data on its own infrastructure, and require no trusted operator to move assets. Canton provides all three as native primitives — which is why Musubi is built on it rather than on a transparent permissionless chain.

​
Atomic multi-party DvP

ExecuteSettlement exercises all four settlement legs inside a single Canton transaction. Either every leg moves or none do — there is no partial state, no pre-funding window, and no moment where one party has delivered and another has not. Counterparty risk is eliminated, not merely mitigated. Approximating this on a transparent ledger means escrow contracts, hash-time-locked swaps, or an external coordinator — each of which reintroduces a timing gap and a new trust assumption. On Canton, atomic delivery-versus-payment across independent parties is the base settlement model, so a single transaction_hash covers all four legs and is independently verifiable by any party to the trade.

​
Sub-transaction privacy

Canton enforces privacy at the protocol level: each participant’s node stores only the contracts it is a party to. There is no shared global state to read, no way to enumerate other participants, and no shared transaction history. This is what lets a market maker price an anonymized RFQ — currency pair, amount, and expiry only — and win a trade without ever receiving the sender’s or receiver’s identity. The identity data is not masked at the application layer; it is physically never transmitted to the market maker’s node. Approximating this on a transparent chain requires zero-knowledge proofs plus off-chain coordination plus new trust assumptions. On Canton it is a base primitive.

​
Operator-less, minimal-trust authorization

Settlement requires cryptographic co-signatures from the independent parties. No single party — including the network operator — can move assets unilaterally. The operator coordinates the four-party settlement and co-submits the transaction; it never custodies tokens, sets FX rates, or acts as counterparty. Authorization is split by design: the institution proves intent (its intent_signature is verifiable off-chain, even by a party with no network access), and the custodian co-signs the asset movement. This is the maker-checker / four-eyes model, enforced cryptographically by the settlement protocol rather than by internal procedure — a rogue actor cannot back-date or reconstruct a co-signature.

​
Built for institutional finance

Canton is the substrate institutional finance already runs tokenized settlement on. Representative deployments of the same multi-party-atomic-settlement model:
  • Digital Asset × DTCC Project Ion — US securities clearing and settlement
  • Goldman Sachs DAP — tokenized bond issuance
  • HSBC Orion — tokenized gold
  • Deutsche Börse Clearstream D7 — tokenized securities
  • Progmat (Mitsubishi UFJ Trust / Datachain) — Japanese stablecoin settlement platform
The pattern they share is exactly what Musubi builds on: multi-party DvP with atomic settlement, observer visibility scoped per sub-transaction, and gate logic in the settlement choice that runs before any tokens move. Where Musubi makes a stronger-than-default choice: the custodian co-signs the FXOrder itself rather than merely observing and signing off out-of-band. That cryptographically enforces custodian authorization of every intent, which is the property a cross-border settlement rail between independently-owned custodians needs.

​
When this model isn’t right

The privacy and authorization model assumes known, bilateral or small-set counterparties — independently-owned institutions that co-sign each settlement. It fits institutional cross-border settlement well. It is less appropriate for anonymous-pool retail payments or permissionless DeFi, where the participant set is open and a transparent shared ledger is the accepted model. Those workloads have a different architecture, with its own valid reasons. Related reading: FXOrder Reference for every on-ledger field; Trust Model for the party authority boundaries; Privacy Model for the data-visibility rules.