# Mint assets in the console Source: https://docs.settlemint.com/docs/operators/asset-servicing/mint-assets Issue new units of a security to investor accounts from the web console, with eligibility checks and safe retry guidance. Minting assets in the DALP console creates new token units and credits them to eligible recipient wallets. Use this guide when you issue securities from the web interface, including shares, bonds, and fund units. If you automate minting, use the [API guide for minting assets](/docs/developers/asset-servicing/mint-assets). For the retry and supply-control model, see [mint replay, idempotency, and supply controls](/docs/compliance-security/security/replay-idempotency-mint-controls). Common use cases include: * Primary issuance after a new offering closes * Subscription settlement after payment confirmation * Stock dividends paid as additional shares * Capital calls where funded commitments receive fund units ## Prerequisites [#prerequisites] * `SUPPLY_MANAGEMENT_ROLE` for the asset (check **Permissions** tab) * Each recipient wallet must be registered to an OnchainID in the identity registry * Each recipient identity must hold the claim topics required by the asset's compliance rules, such as KYC and AML when the asset uses identity verification * The issuers that signed those recipient claims must be trusted for the matching topics in **Claim Topics & Issuers** * For capped assets: sufficient headroom under supply cap * For collateralized assets: sufficient [collateral backing](/docs/operators/compliance/collateral) * For assets with a capital-raise limit: a base-price feed for the asset, or an asset identity claim that the price resolver can use as fallback * If the asset charges an external transaction fee and you mint to your connected wallet, that wallet must hold enough fee token and approve the external fee feature for the mint fee. For collateralized assets, minting remains unavailable until a collateral verification is issued by a trusted issuer. If you do not have collateral permissions, ask a claim policy manager to add you as a trusted issuer in **Claim Topics & Issuers**. The mint form's protocol limit reflects remaining collateral after the current supply is backed, so it may be lower than the total collateral amount shown on the asset. ## Prepare an issuer or treasury recipient [#prepare-an-issuer-or-treasury-recipient] An issuer, treasury, transfer agent, or exchange vault can receive minted units only when DALP models the wallet as a regulated recipient. Create the participant, register the wallet in the identity registry, and issue the required claims before you mint to that wallet. For a vessel or special-purpose company structure, model the legal entity that owns the instrument as the recipient identity. Each vessel or SPC that can hold minted units should have its own participant record, OnchainID, registered wallet, country code, and verification claims. The parent sponsor, supply manager, or servicing operator can keep the console permissions needed to submit the mint, but those operator roles do not make the vessel or SPC wallet eligible to receive tokens. A practical setup uses this split: | Role | Purpose | Required setup before minting | | ------------------------------------------ | ---------------------------- | ---------------------------------------------------------------------------------------- | | Supply manager | Submits the mint transaction | Asset-level `SUPPLY_MANAGEMENT_ROLE` and console access | | Compliance or claim operator | Issues verification claims | Claim-issuer permission and trusted-issuer configuration for the relevant claim topics | | Vessel, SPC, issuer, or treasury recipient | Receives the minted units | Registered wallet, OnchainID, country code, and the asset's required verification claims | Before minting to a vessel, SPC, issuer, or treasury wallet, check the recipient in **Participants**. The wallet should show as registered, and the identity should have the required verification claims from trusted issuers. A registered identity without the required claims can still fail the asset's compliance check. If the asset uses a capital-raise limit, check the asset price setup as well as the recipient setup. DALP converts the minted token amount into fiat value during mint validation. The capital-raise module reads the asset's base price from the configured price resolver. If no feed exists and claim fallback is enabled, the asset token itself must have a registered identity with the configured base-price claim. ## What the console checks [#what-the-console-checks] Before the console lets you continue, each row must have a valid EVM recipient address and a positive amount. The form totals all rows, compares the request with the active protocol limit when a positive remaining limit is available, and shows the projected supply change on the confirmation step. The mint dialog shows a **Minting limit** row that reads one of three ways: | Minting limit row | What it means | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A numeric value | A cap or collateral limit the console can calculate applies. For a capped asset, the value is the remaining cap. For collateral controls, the value is the remaining collateral-backed mintable supply. When both apply, the lower value is shown. | | **Subject to compliance limits** | A supply-limiting compliance rule caps minting on-chain, and the console cannot calculate the remaining headroom. This covers capped, capital-raise, token-supply, and issuance-volume limits. | | **No minting limit** | The console found no cap, collateral, or supply-limiting compliance rule it can read. A capped or collateralized asset whose remaining headroom is already zero can also read this way, because the console only shows a number while the remaining amount is positive. Verify the asset's cap and collateral headroom before minting a large amount: an exhausted cap still reverts the mint on-chain. | When a numeric cap and a compliance limit both apply, the console shows the number and adds a **Subject to compliance limits** note beneath it. A **Subject to compliance limits** qualifier, or the absence of a number, does not mean minting is unconstrained. The compliance rule is enforced on-chain at submission, so a mint above the active limit reverts even when the console cannot show the exact remaining amount. When you see this qualifier, check the asset's active compliance rules and recent issuance before minting a large amount. The console can also show the mint fee and the net amount each recipient receives when the asset has a mint transaction fee. For self-mints, the form checks the connected wallet's fee-token balance and allowance before submission. For third-party recipients, confirm their fee-token readiness before you submit. ## Steps [#steps] ### Open mint dialog [#open-mint-dialog] Navigate to **Asset Management**, select the asset, click **Manage Asset** > **Mint tokens**. ![Manage Asset menu with Mint tokens](/docs/asset-servicing/mint-menu.webp) ### Enter recipient rows [#enter-recipient-rows] Select a recipient address and enter a positive mint amount. Add one row per recipient when the issuance should credit multiple wallets in one submission. ![Mint tokens form](/docs/asset-servicing/mint-form.webp) The recipient picker lists participants and contacts that have a **wallet registered to their identity** for this asset. It shows each one by that registered wallet, so when a participant has more than one wallet, for example after enabling account abstraction or after adding a smart wallet later, the picker selects the registered wallet. The address you mint to is then the one the registry resolves for that identity. A registered wallet appearing in the picker is not a guarantee of full compliance. The filter confirms registry presence only. A shown recipient can still be missing required claims or trusted issuers and revert the mint on-chain. Confirm each recipient meets the asset's compliance rules before you submit. Participants without a registered wallet are filtered out, and the picker shows a hidden-count notice, such as "2 participants hidden". Choose **Show all** to reveal every participant and contact, including those that have no registered wallet yet. Minting to an address that fails the asset's compliance check reverts on-chain. A holder stays hidden when no wallet is registered to its identity. The picker checks for an active, not-lost registered identity; it does not check claims or trusted issuers. A holder with a registered wallet but missing KYC still appears in the picker, while a KYC-approved holder without a registered wallet remains hidden. To make a hidden holder visible in the picker, register a wallet to the holder's identity first. See [Register user](/docs/operators/user-management/register-user) and [Claims and identity](/docs/architecture/concepts/claims-and-identity). After the holder appears in the picker, confirm compliance before minting. A KYC-gated asset still requires the holder to hold an approved KYC profile and an on-chain KYC verification, issued by a trusted issuer, before the mint succeeds on-chain. To resolve a compliance gap after the holder is visible: 1. The holder submits a KYC profile from their account profile and selects **Submit for review**. See [Provide KYC data](/docs/operators/user-management/provide-kyc-data). 2. An Identity Manager approves the submitted profile. See [Manage KYC data](/docs/operators/compliance/manage-kyc-data). 3. A trusted issuer issues the KYC verification on the holder's identity. See [Verify KYC](/docs/operators/compliance/verify-kyc#before-you-can-issue-a-kyc-verification) and [Configure trusted issuers](/docs/operators/compliance/configure-trusted-issuers). The picker suggests holder accounts only. Deployed token contracts, claim issuers, and add-on identities each register their own on-chain identity, but they are not mint recipients, so the picker leaves them out of the suggestion list. This keeps real holders visible instead of crowded out by contract entries, and stops a contract address from being minted to by accident. To mint to a contract address on purpose, switch the field to manual entry and paste the address. A saved address-book contact whose wallet is a contract address can still appear, because the holder filter applies to the suggestion list, not to contacts you curated yourself. ### Confirm and submit [#confirm-and-submit] Review the recipients, total mint amount, projected total supply, fee preview, and wallet verification challenge. Submit only when the recipient setup, protocol limit, and fee readiness match the intended issuance. If you mint to your connected wallet and the asset charges an external transaction fee, the confirmation screen checks your fee-token balance and allowance before you submit. If the balance is sufficient but the allowance is too low, use **Approve fee allowance** from the confirmation screen, then return to the mint confirmation. If you mint to another wallet, confirm that recipient's fee-token balance and allowance before submitting because third-party wallets are not checked in the confirmation screen. ## If the submission result is unclear [#if-the-submission-result-is-unclear] Treat a submitted mint as pending until DALP shows a transaction status, an indexed supply change, or a webhook outcome. A browser refresh, network timeout, or delayed wallet approval is not proof that the mint failed. Before submitting another mint for the same business instruction: 1. Check the asset activity, transaction status, and indexed total supply. 2. Confirm whether the original recipient rows and amounts already appear in the asset state. 3. Use a new mint submission only after reconciliation shows the previous instruction did not create the intended supply. For API integrations, reuse the same `Idempotency-Key` only when retrying the same mint payload and signing route. If the recipient, amount, asset, executor, or wallet route changes, use a new key. For the full retry model, see [mint replay, idempotency, and supply controls](/docs/compliance-security/security/replay-idempotency-mint-controls). ## Troubleshooting [#troubleshooting] | Issue | Solution | | -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Mint button disabled | Verify `SUPPLY_MANAGEMENT_ROLE` assignment and confirm collateral backing for collateralized assets | | Recipient not eligible | Check that the recipient wallet is registered to an OnchainID, has the required verification claims, and received those claims from trusted issuers. To resolve a missing claim, follow the [recipient eligibility resolution path](#enter-recipient-rows): the holder submits a KYC profile, an Identity Manager approves it, and a trusted issuer issues the verification. See [Verify KYC](/docs/operators/compliance/verify-kyc#before-you-can-issue-a-kyc-verification) and [Configure trusted issuers](/docs/operators/compliance/configure-trusted-issuers). | | Expected recipient missing from picker | The picker hides participants without a registered wallet. Confirm the participant has a registered wallet in the identity registry. If the wallet is registered and the participant still does not appear in the picker, verify the registered identity is active and not marked lost. The picker does not check claims or trusted issuers, so a holder with a registered wallet but missing KYC still appears in the normal picker; the mint later reverts on-chain for compliance reasons. To register a wallet, see [Register user](/docs/operators/user-management/register-user) and [Claims and identity](/docs/architecture/concepts/claims-and-identity). To resolve a missing claim or issuer, see [Verify KYC](/docs/operators/compliance/verify-kyc#before-you-can-issue-a-kyc-verification) and [Configure trusted issuers](/docs/operators/compliance/configure-trusted-issuers). | | Need to mint to a contract address | The picker suggests holder accounts only, so token contracts, claim issuers, and add-on identities do not appear. Switch the recipient field to manual entry and paste the contract address. Confirm the address is the intended on-chain recipient before you submit, because a mint into a contract is rarely the goal. | | No claim fallback | For assets with a capital-raise limit, add a base-price feed for the asset or issue the configured base-price claim to the asset token identity before minting | | Exceeds supply cap | Reduce amount or request cap increase | | Mint reverts under a compliance limit | The mint exceeds an active [capital-raise](/docs/operators/compliance/capital-raise-limit), [token-supply](/docs/operators/compliance/token-supply-limit), or [issuance-volume](/docs/operators/compliance/issuance-volume-limit) limit. Reduce the amount or review the limit configuration. The mint dialog shows **Subject to compliance limits** when one of these rules applies. | | Insufficient collateral | Issue a new [collateral verification](/docs/operators/compliance/collateral#issue-a-collateral-verification) with higher amount | | External fee warning | Fund the connected wallet with the fee token, or approve the external fee feature to collect the mint fee | | Unclear submission outcome | Reconcile transaction status, asset activity, and indexed supply before submitting another mint for the same instruction |