Musubi enforces privacy at the settlement network protocol level — not through field masking or access control, but by limiting which data reaches each participant’s infrastructure. Each participant receives only the contracts and transactions it is entitled to.
Two boundaries are worth stating precisely up front, because the rest of this page depends on them.
The guarantee is payload confidentiality, not metadata confidentiality. Order amounts, FX rates, currencies and settlement terms reach only the parties entitled to them. The shape of a settlement — which parties confirmed it and when — is protocol metadata that the network’s mediator handles in order to collect confirmations. Operators of that infrastructure, and anyone they publish it to, can therefore reconstruct who traded with whom and at what time, without seeing any amount or rate.
Market-maker anonymity is a quoting-phase guarantee. Through the whole RFQ and quoting phase a market maker receives no counterparty identity at all. Once it co-signs settlement it becomes a party to the settlement transaction, and the settled order — including both institutions and both custodians — is disclosed to its node as a consequence. See Post-Settlement Visibility.
Data Visibility by Role
Anonymized Quote Requests
When an institution creates an FX order, Musubi broadcasts a quote request to market makers. This request is deliberately stripped of identifying information:
Market makers price based on flow characteristics (currency pair, size, market conditions) — not client identity. That anonymity holds for as long as the trade is a quote:
- Before quoting: anonymous request
- During quoting: the MM does not know who is asking, how many others are bidding, or what they bid
- After winning: the MM’s own records and console show swap amounts, rate and settlement proof — no counterparty identity
- At settlement: the MM co-signs the settlement transaction. It is therefore a party to it, and the settled order is disclosed to its node with both institutions and both custodians named.
This is protocol-level privacy, not application-level masking — but read the boundary literally. Nothing identifying reaches the market maker’s node during quoting. At settlement the market maker is one of the four required co-signers, so the settlement transaction, including the settled order it completes, is delivered to its node. Musubi’s market-maker API and console are built on a separate, identity-free view of the won order and expose none of it; the underlying disclosure is a property of co-signing, and it is a design decision rather than an open defect: after a quote is accepted, the parties to the deal may know each other. What the model protects is the competition — no market maker learns who is asking or what others bid, and a losing market maker never learns either.
No Shared Ledger
Unlike public blockchains, there is no global state that all participants can read:
- Each participant’s node stores only the contracts it is a party to, plus contracts disclosed to it as a consequence of transactions it takes part in
- There is no shared transaction history and no global state to query
- Each participant’s database contains only its own view
An institution cannot see another institution’s orders. A market maker cannot see another market maker’s quotes or win rate. A custodian cannot see orders it does not custody.
What this does not cover is the network’s own confirmation metadata. A settlement’s participating-party set is visible to the operators of the synchronizer that orders and confirms it, which is what makes trade timing and the counterparty relationship — though not amounts, rates or currencies — observable to that infrastructure layer. On the public DevNet that metadata is served by a third-party network explorer without authentication. Establishing who holds it on production networks is an open pre-launch item; it is not something Musubi’s contracts can close on their own.
No Backend-to-Backend Communication
All cross-party coordination flows through the settlement network protocol:
No participant’s backend makes direct API calls to another participant’s backend. There is no service mesh, no message queue, no shared database between participants. The settlement network is the only communication channel, and it enforces visibility rules at the protocol level.
Post-Settlement Visibility
After settlement completes, each party has a scoped view of the result:
The market-maker row is the one place where the product view and the ledger view differ, and we would rather state it than let you discover it.Settlement is a single atomic transaction co-signed by four parties, one of which is the market maker. Completing the order is part of that transaction, so the settled order is disclosed to every co-signer’s node, the market maker’s included — with the sending institution, the receiving institution, and both custodians on it. This is a consequence of requiring the market maker’s signature for atomic delivery-versus-payment; removing it would mean giving up single-transaction atomicity, which is the stronger guarantee.In practice: the market-maker product surface is built on a separate identity-free record of the won trade, so no Musubi API and no market-maker screen returns a counterparty identity, and no other market maker sees the trade at all. But the disclosure to the winning market maker’s own infrastructure is real, it survives into backups and exports of that infrastructure, and it is not something an access-control setting removes.Sender and receiver anonymity toward the market maker is therefore a guarantee up to and including quote selection, and a matter of the market maker’s own data handling after settlement. This is a design decision, not a known defect awaiting a fix: after a quote is accepted, the parties to the deal may know each other. If your risk model needs anonymity to hold post-trade as well, raise it during onboarding — the cost of closing it has been measured and is on record, but it is not planned.
