Issue assets

CWS integrates first-party with DA Utility — the Canton registry app that backs asset issuance and administration. The cws utility command tree exposes mint and burn flows plus the provider and registrar onboarding flows that back them. Single-signer and multisig wallets are both supported for every flow.

The sections below are in the order you'll typically run them: onboard a provider, onboard a registrar, register the instrument, then issue and burn against it.

Onboard a provider

Mint and burn flows depend on a service-provider relationship. Before you can issue against a counterparty's holdings, the operator opens a ProviderServiceRequest and the provider accepts with the credentials they will operate under:

# Operator creates the request
cws utility provider request create \
  --provider provider::1220bbbb

# Provider accepts — one or more credential ids are required
cws utility provider request accept <requestId> \
  --credential-id <cid> \
  --operator-configuration-id <cid>

# Either side can reject (with reason) or cancel
cws utility provider request reject <requestId> --reason "scope mismatch"
cws utility provider request cancel <requestId>

Onboard a registrar

Issuance also needs a registrar — the party that maintains the registry for an instrument. The lifecycle mirrors provider onboarding: an operator opens a RegistrarServiceRequest against a candidate registrar and the registrar accepts with the credentials they will operate under.

# Operator creates the request
cws utility registrar request create \
  --registrar registrar::1220cccc

# Registrar accepts — one or more credential ids are required
cws utility registrar request accept <requestId> \
  --credential-id <cid> \
  --operator-configuration-id <cid>

# Either side can reject (with reason) or cancel
cws utility registrar request reject <requestId> --reason "scope mismatch"
cws utility registrar request cancel <requestId>

Register the instrument

Once a registrar is onboarded, it registers each instrument it will operate. The registrar exercises the registry's instrument-creation choice, picking a code, display name, and decimal precision. The resulting instrument id — <code>::<registrar-party-id> — is what every subsequent mint, burn, and transfer references.

# Run as the active registrar profile
cws utility instrument create \
  --code USDC \
  --name "USD Coin" \
  --decimals 6 \
  --description "Send-issued USDC on Canton"

# Inspect the result — instrument id is printed on success
cws instruments list --json

Use cws instruments list to see every instrument the registry knows about. Existing instruments operated by other registrars (for example amulet::<splice-registrar>) show up here too.

Issue

Mint new units of an instrument. As the issuer offering to mint:

cws utility mint offer create \
  --instrument USDC::<registrar> \
  --receiver alice::1220aaaa \
  --amount 1000 \
  --reference "treasury-q3-grant" \
  --execute-before-ms 1717000000000

Or, as a counterparty requesting the issuer to mint to you:

cws utility mint request create \
  --instrument USDC::<registrar> \
  --amount 1000

# The issuer reviews, then approves the request
cws utility mint request accept <requestId>

Reject with a reason; cancel without:

cws utility mint offer reject <offerId> --reason "out of policy window"
cws utility mint request cancel <requestId>

Burn

Retire units of an instrument. Burn needs the holding contract id you are burning from — pass it with --holding-contract-id. Repeat the flag to burn across multiple holdings:

# Issuer offers to burn from one of your holdings
cws utility burn offer create \
  --instrument USDC::<registrar> \
  --counterparty alice::1220aaaa \
  --amount 250 \
  --reference "redemption-2026-05"

# Counterparty accepts with the holdings they're contributing
cws utility burn offer accept <offerId> \
  --holding-contract-id <cid> \
  --holding-contract-id <cid>

Or, as a counterparty requesting the issuer to burn from your holdings:

cws utility burn request create \
  --instrument USDC::<registrar> \
  --amount 250 \
  --holding-contract-id <cid>

# Issuer accepts
cws utility burn request accept <requestId>

Every command runs through the existing CWS prepare/verify/sign loop, so the multisig story is identical: if the acting party is a multisig, pass --multisig <partyId> and the prepared submission enters the queue for threshold approval before anything submits to Canton.