Mint assets with the API
Issue new asset units to eligible wallet addresses with the DALP API.
Minting assets with the DALP API creates new units and assigns them to specified wallet addresses. This guide is for developers and integrators building issuance flows. Console users should follow the console guide for minting assets.
The mint route checks supply-management permission for every request. Non-API-key user sessions must include wallet verification, while API-key sessions authenticate with the API key and skip the wallet-secret check. The route also rejects paused assets, validates positive amounts, and enforces one amount per recipient before submitting the on-chain transaction. Use an Idempotency-Key for each business instruction so retries do not create a second mint request.
API minting issues new asset supply only after caller permissions and token compliance checks pass.
For retry, replay protection, and supply controls, see Replay protection and mint controls.
Prerequisites
- Platform URL (e.g.,
https://your-platform.example.com) - API key from a user with Supply Management role on this asset (see Getting Started for API key setup)
- For non-API-key user sessions, a wallet verification method enabled on your account (e.g., pincode or 2FA)
- Asset must be unpaused
- Recipients must have registered identities with required compliance verifications
- The issuer or treasury wallet that receives newly minted units must be registered as a participant wallet before it can receive supply
Minting assets
Prepare API request
Construct the API request with recipient address and amount:
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", 18]
}'Asset address in path
The asset contract address is part of the URL path: /api/token/{tokenAddress}/mint
Execute mint transaction
When you execute the request, the platform:
- Validates your permission - Confirms the request executor has the supply-management role on this asset
- Applies session-specific signing checks - Verifies wallet secrets for non-API-key user sessions; API-key sessions skip wallet-secret verification
- Checks mint inputs - Rejects paused assets, non-positive amounts, and mismatched recipient and amount arrays
- Submits the mint transaction - Uses the single-recipient mint call for one recipient and the batch mint call for multi-recipient requests
Amount formatting
Asset amounts depend on the asset's decimal configuration. See Asset Decimals for formatting guidance.
Handle response
A successful response returns the updated asset data (showing key fields):
{
"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]"
}
}The response includes the full asset object with the updated totalSupply reflecting the newly minted units, along with additional fields like identity, accessControl, complianceModuleConfigs, userPermissions, and stats.
Batch minting
Issue units to multiple wallets in a single request. The API accepts up to 100 recipients and 100 amounts, and the two arrays must have the same length. DALP validates the full request before submitting the batch transaction.
Prepare batch request
Construct the request with arrays of recipients and amounts:
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", 18],
["300000000000000000000", 18],
["200000000000000000000", 18]
]
}'Array length must match
The recipients and amounts arrays must have the same length. Each
recipient gets the corresponding amount at the same index.
Execute batch mint
The platform validates the request shape before execution. If a recipient or amount cannot be accepted by the token contract or its controls, the transaction is rejected rather than partially minting the batch.
Batch limits:
- Maximum 100 recipients per API call
- For larger batches, split into multiple calls
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:
- The wallet is registered to an identity in the active system.
- The wallet has the compliance claims required by the asset, such as KYC or asset-specific claim topics.
- 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
| Parameter | Type | Required | Description |
|---|---|---|---|
recipients | string or array | Yes | Recipient wallet address(es) (0x...) |
amounts | string or array | Yes | Amount(s) as dnum tuple [scaled_value, decimals]. See Asset Decimals |
walletVerification | object | Conditional | Required for non-API-key user sessions; omit for API-key sessions |
walletVerification.secretVerificationCode | string | Conditional | Your 6-digit PINCODE or TOTP code |
walletVerification.verificationType | string | Conditional | "PINCODE", "OTP", or "SECRET_CODES" |
Troubleshooting issuer and treasury mints
| Error or symptom | What it means | How to fix it |
|---|---|---|
DALP-3027 / NoClaimFallback | The price resolver tried claim fallback, but the token has no fallback claim for the requested topic. It is not a wallet-role error. | Add or refresh the token's configured price feed. If claim fallback is enabled for the deployment, issue the required token claim before retrying. |
| Recipient fails compliance | The wallet exists, but the asset's compliance modules reject the recipient. | Register the wallet to the intended participant identity and issue the required claims from a trusted issuer. |
| Caller can view the asset but cannot mint | The caller does not have the asset-level Supply Management role. | Grant Supply Management on the asset, or have a supply operator submit the mint. |
| Claim issuer cannot add trusted issuers or claim topics | Claim issuance and claim-policy administration are different permissions. | Use a Claim Policy Manager account to manage topics and trusted issuers, then use a Claim Issuer account to issue the approved claims. |
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 exact 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
Yes, a bank-originated mint flow must validate the signed core banking instruction before DALP mints. The signed-instruction check belongs at the integration entry point that accepts core banking messages. The public mint API receives the already validated mint request 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 dnum amount list including decimals, timestamp, sequence number, and instruction identifier. For fiat-backed assets, include the bank ledger amount and currency in the signed payload 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 when a user session signs, queued transaction execution, signer or custody policy, and the EVM asset contract's mint rules.
| Control question | DALP deployment mechanism | Evidence or deployment boundary |
|---|---|---|
| Is the instruction signed by the originating core banking system? | The integration entry point validates the signature before calling the DALP mint API. | The signature check runs on the bank-originated instruction, not on an unsigned public mint body. |
| What does the signature bind to? | The signed payload binds the source ledger reference, asset, complete recipient list, exact dnum amount list with decimals, timestamp, sequence number, and instruction identifier. | Any mismatch between the signed payload and the mint request is rejected before execution. |
| How are forged or tampered middleware instructions rejected? | Signature, timestamp, sequence, and payload-binding checks must pass before the request reaches the mint route. | Failed checks stop the request before DALP authentication, authorization, custody policy, or on-chain minting. |
| How are duplicate retries handled? | DALP uses Idempotency-Key to attach retries to the same accepted or queued mint transaction. | Use one key for one approved core banking instruction, and use a new key when any signed business field changes. |
| What platform controls still apply after validation? | DALP checks API authentication, Supply Management permission, wallet verification when required, queued execution, signer or custody policy, and token contract mint rules. | The bank reconciles the transaction hash, indexed supply, and source ledger record after execution. |
For the broader retry and replay model, use Replay protection and mint controls with this mint API reference.
Troubleshooting
| Issue | Solution |
|---|---|
401 Unauthorized | API key is invalid, expired, or disabled |
403 USER_NOT_AUTHORIZED | Ensure your account has supplyManagement role on this asset |
Asset is paused | Unpause the asset first (see Pause/Unpause) |
Recipient identity not found | Recipient must create an account and register their identity |
Exceeds supply cap | Asset has reached maximum supply |
Insufficient collateral | Deposit more collateral before minting |
Recipient not compliant | Recipient missing required claims (KYC, accredited investor, etc) |
Recipients and amounts mismatch | Array lengths must be equal |
Amount must be positive | All amounts must be greater than 0 |
Related guides
- Pause/Unpause Assets - Enable/disable transfers
- Forced Transfer - Transfer assets administratively
- Replay protection and mint controls - Understand retry and replay controls