Skip to main content
Updated 2026-06-19 for the member-owned / operator-less pivot. Musubi is a member-owned, operator-less, atomic & private settlement rail with no on-ledger compliance layer (per-participant compliance is off-ledger). Content below verified current as of this date; for the governance model see ADR-0024.
Musubi enforces trust through a multi-party signing model. No single party can move assets or execute settlements unilaterally. Every settlement requires cryptographic agreement from four independent parties. Musubi is operator-less: the Core coordinator co-submits on every settlement (a protocol mechanic — see ADR-0001), but no standing operator owns or unilaterally controls the network (a governance property — see ADR-0024). The network is member-owned; Core coordinates, it does not govern. Musubi carries no KYC/AML or compliance data on-ledger — it is entirely each participant’s own off-ledger concern.

​
Four-Party Settlement Signing

Before any atomic DvP executes, all four parties must authorize:
PartyWhat They AuthorizeTradFi Parallel
Core coordinatorCoordinates the 4-party settlement and co-submits — does not own or control the networkExchange/CCP coordinating a trade
Sender CustodianReleases sender’s source stablecoinCustody bank releasing funds
Market MakerCommits target stablecoin liquidityCounterparty committing to delivery
Receiver CustodianConfirms receipt capabilityCustody bank accepting inbound
If any party refuses or fails to respond, settlement does not proceed and no assets move. This is more conservative than most traditional settlement systems — CLS Bank requires only the two commercial banks to pre-fund; Musubi requires all four participants to explicitly authorize.

​
Dual Control: Institution + Custodian

Every trade requires two independent authorizations from the sending side:
StepWhoWhatEnforcement
1. Select quoteInstitutionReviews competing quotes, picks the best rateAPI call
2. Authorize movementCustodianCo-signs the quote acceptance, authorizing asset releaseCryptographic co-signature
Neither party can act alone:
  • The institution cannot move assets without the custodian’s co-signature
  • The custodian cannot initiate a trade — only authorize one the institution requested
This maps directly to the maker-checker / four-eyes principle used in institutional operations, enforced by the settlement protocol rather than by internal procedure. The custodian’s co-signature is cryptographic — it cannot be forged, bypassed, or retroactively granted.

​
Who Holds What Authority

AuthorityHeld ByPurpose
Intent signingInstitutionProves the institution authorized the payment (non-repudiation)
Asset movementCustodianControls when and how much stablecoin leaves custody
Liquidity commitmentMarket MakerCommits target currency for the swap
Settlement coordinationCore coordinatorCoordinates settlement and co-submits the atomic DvP (coordination only — no ownership or control of the network)
The institution proves intent. The custodian controls assets. These are separate keys held by separate organizations — neither can impersonate the other.

​
Musubi: Coordinator, Not Counterparty

What Musubi DoesWhat Musubi Does NOT Do
Co-submits on the order and verifies party signaturesHold or custody any assets
Broadcasts anonymized RFQs to market makersSet or influence FX rates
Coordinates the 4-party settlement signingMove assets without custodian authorization
Executes the atomic DvP transactionAccess participants’ internal systems
Provides settlement confirmationsAct as counterparty to any trade
Own, govern, or unilaterally control the network
TradFi parallel: Musubi is to stablecoin settlement what CLS Bank is to FX settlement — it coordinates simultaneous delivery of both currency legs without ever taking ownership. The critical difference: settlement completes in seconds, not hours.

​
Comparison to Traditional Settlement

AspectTraditional (CLS/Correspondent)Musubi
Who authorizesBank’s internal approval chainCryptographic co-signatures from 4 parties
Settlement guaranteeCLS PvP within settlement windowAtomic DvP — single transaction
Pre-fundingRequired during CLS windowNot required — instant atomic execution
Counterparty riskMitigated by CLS, not eliminatedEliminated — no time gap between legs
Authorization bypassPossible via internal process failureImpossible — cryptographically enforced
Audit trailSWIFT messages + internal logsSingle transaction_hash covering all legs