Settlement on Musubi is an atomic Delivery-vs-Payment (DvP) swap. As a custodian, you either release assets (sender side) or receive assets (receiver side) — both within a single transaction that completes in ~4 seconds.
DvP From Your Perspective
Sender Custodian
Receiver Custodian
Your client’s JPYSC0 leaves your custody and the market maker’s USDCx is delivered to the receiver custodian — all in one atomic transaction.| Leg | Movement | Your Role |
|---|
| 1 | JPYSC0: Your custody -> Musubi | You release |
| 2 | USDCx: Market maker -> Musubi | — |
| 3 | USDCx: Musubi -> Receiver custodian | — |
| 4 | JPYSC0: Musubi -> Market maker | — |
Key guarantee: Legs 1-4 are atomic. Your JPYSC0 only leaves your custody if all four legs succeed. If the market maker fails to deliver USDCx (leg 2), your JPYSC0 is never released (leg 1 rolls back). USDCx arrives in your custody from Musubi as part of the atomic settlement.| Leg | Movement | Your Role |
|---|
| 1 | JPYSC0: Sender custodian -> Musubi | — |
| 2 | USDCx: Market maker -> Musubi | — |
| 3 | USDCx: Musubi -> Your custody | You receive |
| 4 | JPYSC0: Musubi -> Market maker | — |
Key guarantee: The USDCx arriving in your custody is fully settled — not pending, not provisional. The atomic DvP means the sender’s JPYSC0 was simultaneously released.
How Canton Holdings Differ from EVM Tokens
If you’re used to ERC-20 or UTXO-based custody, the Canton model has some important differences:
| ERC-20 (EVM) | Canton Holding (DAML) |
|---|
| Ownership model | Balance in a contract’s storage mapping | Holding contract where you’re the sole signatory |
| Transfer mechanism | approve + transferFrom (allowance pattern) | Exercise Transfer choice on the Holding contract |
| Who can move assets | Anyone with an allowance | Only you (sole signatory) — no allowance/approval pattern |
| Visibility | Anyone can read balances on Etherscan | Only you and authorized parties see your holdings |
| Double-spend prevention | EVM nonce + contract state | DAML contract consumption — used Holding is archived, new one created |
| Atomicity | Transaction-level (single contract call) | Sub-transaction-level (4-leg DvP in one transaction) |
The key difference: on EVM, you grant an allowance and a smart contract pulls tokens. On Canton, you exercise the Transfer choice directly — there’s no allowance pattern, no approval that could be exploited. You are the sole signatory on your Holding contract.
Asset Movements
Sender Custodian
| Event | Balance Change |
|---|
| Order created | No change (JPYSC0 is not locked during quoting) |
| Quote accepted | No change (commitment is recorded, not yet executed) |
| Settlement executes | JPYSC0 decreases by target_amount |
| Settlement fails/rolls back | No change (nothing was released) |
Receiver Custodian
| Event | Balance Change |
|---|
| Settlement executes | USDCx increases by source_amount_actual |
| Settlement fails/rolls back | No change (nothing was delivered) |
Assets are not locked or escrowed during the quoting phase. Your client’s JPYSC0 balance remains fully available until the atomic settlement actually executes. This is different from EVM approve patterns where an allowance could be consumed at any time.
Client Balance Updates
After settlement, update your client’s balance records:
Sender custodian — debit the sender institution’s account:
- Amount:
target_amount (e.g., 100,000 USDCx)
- Reference:
intent_id + transaction_hash
- Timestamp:
settled_at
Receiver custodian — credit the receiver institution’s account:
- Amount:
source_amount_actual (e.g., 11,200,000 USDCx)
- Reference:
intent_id + transaction_hash
- Timestamp:
settled_at
Reconciliation
Match settled orders against your internal records using:
| Field | Purpose |
|---|
intent_id | Correlate with the institution’s payment reference |
transaction_hash | Single settlement proof — covers all four DvP legs |
settled_at | Settlement timestamp for your accounting records |
target_amount | JPYSC0 released (sender) or sender’s original amount (receiver) |
source_amount_actual | USDCx delivered (receiver) |
fx_rate | Executed exchange rate |
Failed Settlement
If any leg of the DvP fails, all four legs roll back atomically:
| Scenario | Impact on Sender Custodian | Impact on Receiver Custodian |
|---|
| Market maker lacks liquidity | No JPYSC0 released | No USDCx received |
| Settlement network error | No JPYSC0 released | No USDCx received |
| Any party fails to sign | No JPYSC0 released | No USDCx received |
| Order expires before settlement | No JPYSC0 released | No USDCx received |
There is no partial settlement. Your client’s assets remain in your custody in every failure scenario. No “stuck in transit” state to investigate or manually resolve — unlike EVM transactions that can fail mid-execution with gas consumed.