Skip to main content
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

Your client’s JPYSC0 leaves your custody and the market maker’s USDCx is delivered to the receiver custodian — all in one atomic transaction.
LegMovementYour Role
1JPYSC0: Your custody -> MusubiYou release
2USDCx: Market maker -> Musubi
3USDCx: Musubi -> Receiver custodian
4JPYSC0: 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).

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 modelBalance in a contract’s storage mappingHolding contract where you’re the sole signatory
Transfer mechanismapprove + transferFrom (allowance pattern)Exercise Transfer choice on the Holding contract
Who can move assetsAnyone with an allowanceOnly you (sole signatory) — no allowance/approval pattern
VisibilityAnyone can read balances on EtherscanOnly you and authorized parties see your holdings
Double-spend preventionEVM nonce + contract stateDAML contract consumption — used Holding is archived, new one created
AtomicityTransaction-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

EventBalance Change
Order createdNo change (JPYSC0 is not locked during quoting)
Quote acceptedNo change (commitment is recorded, not yet executed)
Settlement executesJPYSC0 decreases by target_amount
Settlement fails/rolls backNo change (nothing was released)

Receiver Custodian

EventBalance Change
Settlement executesUSDCx increases by source_amount_actual
Settlement fails/rolls backNo 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:
FieldPurpose
intent_idCorrelate with the institution’s payment reference
transaction_hashSingle settlement proof — covers all four DvP legs
settled_atSettlement timestamp for your accounting records
target_amountJPYSC0 released (sender) or sender’s original amount (receiver)
source_amount_actualUSDCx delivered (receiver)
fx_rateExecuted exchange rate

Failed Settlement

If any leg of the DvP fails, all four legs roll back atomically:
ScenarioImpact on Sender CustodianImpact on Receiver Custodian
Market maker lacks liquidityNo JPYSC0 releasedNo USDCx received
Settlement network errorNo JPYSC0 releasedNo USDCx received
Any party fails to signNo JPYSC0 releasedNo USDCx received
Order expires before settlementNo JPYSC0 releasedNo 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.