Canton swap integration and settlement

PartyLayer supplies wallet connection, supported approvals and transaction lifecycle. Your chosen protocol supplies liquidity, quotes, execution rules and settlement. A message signature, allocation approval or confirmed deposit alone does not prove a completed swap.

Keep wallet and protocol responsibilities explicit

Bind the server-authenticated user to the intended party and network. Obtain a current quote and present both issuer/id pairs, exact amounts, fees, minimum output and expiry. Store the accepted intent server-side, prepare its precise commands and fresh disclosures, then request one supported wallet action.

Use transaction lifecycle to correlate the original command with the ledger. Track the protocol separately until its output or refund is known, and refresh an authorized complete holdings snapshot. Reconcile lost responses; never replay a deposit merely because a read timed out.

Concrete example: OneSwap's deposit workflow

The official OneSwap SDK guide documents a deposit workflow. Keep its integrator key server-side and select Devnet explicitly for tests. The server quotes and creates a user-bound swap; PartyLayer requests the wallet's exact input transfer to that swap's deposit party before its deadline.

Monitor the stored swap id through an owner-authorized backend endpoint. A returned output, a refund and an in-progress recovery are different outcomes. Recover the existing open swap and original deposit before allowing a new attempt. Verify supported instruments and the vendor's current limits in its lifecycle guide.

Acceptance evidence

Record the accepted quote, wallet approval or rejection, original command id, actual ledger update, protocol output/refund and refreshed holdings. Test reload and account/network changes without duplicate writes. Live acceptance needs a valid vendor transaction, supported network, funded test accounts and user approval.

Full integration and acceptance guide ·Token transfers · Wallet balances