Mint assets with the API

Use the Platform API mint route to create new asset units and assign them to specified wallet addresses. If you are using the Console, follow the console guide for minting assets instead.

The mint route checks your supply-management permission before processing. Your non-API-key session must include wallet verification; API-key sessions authenticate with the key and skip the wallet-secret check. The route rejects paused assets, validates positive amounts, and enforces one amount per recipient before submitting the on-chain transaction. Send an Idempotency-Key with each business instruction so retries attach to the same accepted request instead of creating a duplicate mint.

The platform issues new supply only after validating caller permissions and token compliance. For retry behavior, replay protection, and supply controls, see Replay protection and mint controls.

Prerequisites

• Platform URL (e.g., https://your-platform.example.com)
• API key for a user with Supply Management role on this asset (see Getting Started)
• For non-API-key sessions: wallet verification (pincode or 2FA) enabled
• Asset is unpaused
• Recipients hold the required compliance verifications and registered identities
• Issuer or treasury wallet registered as a participant wallet
• For assets with an initial token price feed: an organisation feed submission signer configured

Minting assets

The steps below cover a single-recipient mint. For multi-recipient mints, see Batch minting.

curl -X POST "https://your-platform.example.com/api/token/0x9459D52E60edBD3178f00F9055f6C117a21b4220/mint" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Idempotency-Key: mint-acme-2026-05-15-001" \
  -H "Content-Type: application/json" \
  -d '{
    "recipients": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb",
    "amounts": "1000000000000000000000"
  }'

{
  "id": "0x9459D52E60edBD3178f00F9055f6C117a21b4220",
  "type": "equity",
  "createdAt": "2025-01-15T10:30:00.000Z",
  "name": "ACME Holdings Common Stock",
  "symbol": "ACME",
  "decimals": 18,
  "basePrice": "[\"10000\",2]",
  "basePriceCurrencyCode": "USD",
  "totalSupply": "[\"1000000000000000000000\",18]",
  "pausable": {
    "paused": false
  },
  "capped": {
    "cap": "[\"1000000000000000000000000\",18]"
  }
}

Batch minting

Issue units to multiple wallets in one request. The API accepts up to 100 recipients and 100 amounts. The two arrays must be the same length. The platform validates the full request before submitting the batch transaction.

curl -X POST "https://your-platform.example.com/api/token/0x9459D52E60edBD3178f00F9055f6C117a21b4220/mint" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Idempotency-Key: mint-acme-batch-2026-05-15-001" \
  -H "Content-Type: application/json" \
  -d '{
    "recipients": [
      "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb",
      "0x8e5F72f6E5b3B4D1234567890AbCdEf1234567890",
      "0x1234567890AbCdEf1234567890AbCdEf12345678"
    ],
    "amounts": [
      "500000000000000000000",
      "300000000000000000000",
      "200000000000000000000"
    ]
  }'

Issuer and treasury wallets

For vessel, SPC, treasury, or nominee structures, model the issuer or treasury account as a wallet that can hold the asset. Register that wallet to the right participant identity before you mint. DALP checks the recipient wallet, not the business label.

A supply operator also needs the asset-level Supply Management role to submit the mint. That role is separate from system-level claim roles. The Claim Issuer role can issue or revoke identity claims, while the Claim Policy Manager role manages claim topics and trusted issuers. Register the claim issuer as a trusted issuer for the claim topics required by the asset before you rely on those claims in a minting flow. For the underlying model, see Claims and identity and Configure trusted issuers.

Before minting to an issuer or treasury wallet, confirm three things:

1. The wallet is registered to an identity in the active system.
2. The wallet has the compliance claims required by the asset, such as KYC or asset-specific claim topics.
3. Any pricing or collateral controls used by the asset have a current feed or a valid claim fallback value for the asset.

This separation supports different people for supply operations, claim issuance, and claim-policy administration. You do not need to give every operator every system role.

Request parameters

Troubleshooting issuer and treasury mints

If the same business entity acts as issuer and treasurer, keep the wallet and claim setup explicit. The platform still evaluates the wallet address, participant identity, claim topics, trusted issuer registration, and asset permissions separately.

Retry safety

Use one Idempotency-Key for each business mint instruction. If the network drops or the client times out, retry with the same key and the same request body. Do not reuse that key for a different recipient list, amount list, token address, or wallet route.

An idempotent retry tells DALP to reattach to the same accepted request or queued transaction. It does not replace transaction status checks or webhook reconciliation.

See Replay protection and mint controls for the full control model.

Core banking-originated mint instructions

When you integrate a bank-originated mint flow, validate the signed core banking instruction before DALP mints. Place the signed-instruction check at the integration entry point that accepts core banking messages. Your integration then passes the validated mint request to the public mint API with the authenticated caller, target asset, recipients, amounts, executor route, and one Idempotency-Key.

The signature must bind the full business payload: source ledger reference, asset, complete recipient list, exact amounts in the asset's smallest unit, decimal precision, timestamp, sequence number, and instruction identifier. For fiat-backed assets, include the bank ledger amount and currency too. The integration entry point rejects a forged, replayed, reordered, or tampered instruction before calling the mint route. DALP then checks API authentication, Supply Management permission, wallet verification for user sessions, paused state, and positive amounts. After those checks pass, the platform queues the mint transaction. The EVM asset contract enforces recipient compliance during execution, so a non-compliant recipient can still cause the transaction to revert.

For the broader retry and replay model, use Replay protection and mint controls with this mint API reference.

Troubleshooting

Related guides

• Pause/Unpause Assets - Enable/disable transfers
• Forced Transfer - Transfer assets administratively
• Replay protection and mint controls - Understand retry and replay controls