Mint and burn are the Console controls that add or remove units of an asset on request. Mint creates new units and assigns them to one or more recipients, which raises total supply. Burn permanently removes units from a holder's balance, which lowers total supply. A minted unit lands in a recipient's balance. A burned unit has no recipient. Offerings, corporate actions, a management fee collection, a fund's subscription settlement, a holder's redemption at maturity and a supply delegate that a Governance holder registers change supply too.
To move units between holders with total supply unchanged, use Transfers. To stop a holder's units from moving, use Emergency halt and freeze.
The “Details” step shows one row with “Recipient” and “Amount”.
Below the row come “Add recipient”, then the requested total with “Max mintable (applies to entire transaction)” and “Subject to compliance limits”. When a fee applies, the previewed fee shows in the same summary.
Steps
Open mint or burn
Open “All assets” and select the asset. For a mint, open “Actions” and choose Mint tokens.
For a burn, open “Actions” and choose Burn tokens, then pick the holder.
From the “Holders” tab you can also open a row menu and choose Burn. The burn form then opens with that address and its whole balance filled in. For a burn, the row shows the address's balance as its cap. Under an amount, a line shows its fiat equivalent at the token's price, for example “≈ $2,000.00”. When the token has no price, the line says that no price is set for the token, so there is no fiat equivalent.
Each form opens on its own page under the asset, with a breadcrumb back to the asset, and Cancel returns you to where you came from. Both forms accept more than one row. A mint can name multiple recipients in the same operation, each with its own address and amount, added or removed before you submit. A burn opened from one holder's row can still add rows for other addresses in the same submission.
The “Actions” menu lists “Mint tokens” and “Burn tokens” among the other controls the asset and the signed-in account allow.
The “Holders” tab carries the per-address burn control.
Enter the allocations
For a mint, add each recipient address and amount. Each address must be a verified holder of the token, and the chain refuses a mint to an address frozen on the token. An address that is not verified blocks its own row with an ineligibility message until you enter one that qualifies. Max mintable (applies to entire transaction) shows the lowest of the room left under the token's own cap, under a maximum-supply compliance rule that applies to every transfer, and under the collateral claim. The form blocks continuing with “Total amount exceeds allowed limit” once the running total would cross it. Other compliance rules that limit supply, such as a capital-raise, token-supply or issuance-volume limit, have no figure the Console can compute, and the form relies on the chain to reject a mint over them. On an asset with any compliance rule that limits supply, a maximum-supply rule included, the form adds “Subject to compliance limits”. With no limit of any kind, the form reads “No minting limit”. When a mint fee applies, total supply still rises by the full amount you entered, but the recipient's own balance rises by less. The review screen names the net amount the recipient keeps and the fee amount.
For a burn, each row is capped at the address's total balance, frozen units included, as the form hint “The total balance, including frozen units, can be burned.” says. When the address holds frozen units, the row adds “of which” the frozen amount “is frozen”. A partial freeze does not stop the burn, but a full freeze does: the chain refuses a burn from an address frozen on the token, so a custodian forced-transfers the units out or lifts the freeze first. The asset's own configuration sets whether a burn fee applies, its rate, and who receives it. You choose none of that here. When a burn fee applies, the amount you enter is what leaves the holder's balance, but total supply falls by a smaller net figure. The one exception is a row whose holder is also the fee recipient: no fee applies on that row, and the full amount comes off supply. Review the total requested across all rows and the fee the Console previews before continuing.
Confirm the supply change
Select “Review”. The review step names the account the transaction runs from and its signing key, then shows the supply before and after and each recipient, or for a burn each address, with its amount. Check the operation, addresses, amounts and fees. When a fee applies, the review also names the account it goes to. A confirmed burn cannot be undone, and a fresh mint creates new units without returning the destroyed ones. Select Confirm mint or “Confirm burn” and confirm with your wallet verification. The chain updates total supply and the affected balances in one transaction, so every row applies or none does.
A mint sent to the wrong address has no recall control. To correct it, burn the units from that address, which needs Supply management, or move them with a forced transfer on Transfers, which needs the Custodian role.
The “Review” step shows “This transaction will execute from:” with the account and its “Signing key”, then “Review mint” with “Current supply” and “New supply”, then “Recipients” with each amount.
The “Confirm mint” button sends the transaction.
What limits a mint
A fixed supply cap is a flat maximum set on the token itself. Collateral-backed capacity ties the ceiling to a collateral claim a trusted issuer has signed and filed. What the chain checks is that such a claim is present, correctly formed, and unexpired, and it takes the amount from the claim. The chain does not check that the reserve the claim describes exists. Minting stops once the claimed amount is used up, so the cap follows the issuer's attestation. A compliance-module cap comes from a compliance rule attached to the token and enforced on-chain. The Console computes the room left only for a maximum-supply rule that applies to every transfer, and leaves every other rule that limits supply to the chain.
Mint adds supply up to the smallest of a fixed cap, collateral-backed capacity and a compliance-module cap, and burn removes units with no recipient.
Mirror tokens
A mirror token stands for a holding kept off chain. On one, the Mint and Burn sheets show where the holding sits and require the external reference, the custodian's or registrar's transaction id. Each mint or burn takes one movement, and a burn takes only your wallet's own units.
Troubleshooting
Continue stays blocked although every row is valid
Signal: on a mint or a burn, every address and amount row looks valid, no cap warning shows, and Continue still does not respond. Cause: checks outside the row data itself can hold it closed. The fee preview at the bottom of the form reads “unavailable” while the token's fee configuration is still loading or failed to load, and “Continue” waits for a definite fee before it lets you proceed. When fees use a different token, the Console checks the paying wallet's fee-token balance and allowance. The operation stays blocked until the check succeeds and both cover the fee. The panel identifies any shortfall. On a burn, “Continue” also waits until the Console has read the balance of every address in the form. While that read is loading or has failed, no row shows a balance. Fix: wait for the fee preview and each row's balance to resolve and retry. If either keeps reading “unavailable” or stays empty, reload the form. If a separate fee-token panel names an insufficient balance or allowance, fund or approve that token for the paying wallet, then reopen the form.
The Mint tokens entry is missing from the menu entirely
Signal: “Actions” opens but has no Mint tokens entry at all, not even a greyed-out one. Cause: none of your wallets holds any role on this token. A wallet that holds another role but not Supply management sees the entry greyed out instead. Fix: ask an administrator to grant the Supply management role on this asset to the wallet that signs your actions, which is the wallet of the participant you are working as.
Mint tokens cannot be selected
Signal: the Mint tokens entry is visible in the “Actions” menu but greyed out. Cause: one of these gates is closed. Your wallets hold a role on the asset but not Supply management, and the menu then shows no message. The asset is halted, the role sits on another of your wallets, a corporate action that changes the asset's units is in progress, the asset has matured and minting is closed, or, on a collateral-backed asset, no collateral is recorded, collateral capacity is exhausted, or its status is still loading or failed to load. A fixed supply cap and a compliance-module cap never grey out this entry. Both are checked only once you open the form and enter an amount. Fix: read the message the menu shows next to the entry. It names the gate, for example “Token operations are halted. Resume token operations to perform this action.” or a message that the corporate action “is in progress on this asset. Minting waits until it finishes.” A halted asset needs resumed operations first, a role on another wallet needs that wallet, a corporate action needs to finish or be aborted, and a collateral gate needs more collateral filed or the status to finish loading. The collateral messages read “Minting is blocked until sufficient collateral is added.”, “Reading collateral…” and “Collateral could not be read.”
The requested mint total is rejected inside the form
Signal: the address and amount rows look valid, the form shows “Total amount exceeds allowed limit”, and continuing stays blocked. Cause: the running total across all recipient rows exceeds whichever supply ceiling binds, the fixed cap, the collateral-backed capacity, or a maximum-supply compliance rule that applies to every transfer. Fix: reduce the total requested, or split it into a smaller mint now and a second one once more capacity is available.
A mint recipient address does not clear
Signal: the address field shows “This recipient is not a verified holder of this token.” and Continue stays blocked. Cause: the address has not completed the eligibility check this token requires. This is separate from your own role and from any supply cap. Fix: confirm the address has completed whatever verification this token requires before it can receive tokens, or enter a different, already-eligible address.
A holder row has no burn control at all
Signal: the row's menu has no Burn entry, not even a disabled one. Cause: the asset does not carry the burnable feature, the holder's balance is zero, your wallet does not hold the Supply management role on the token, or the table shows a past date. Fix: confirm the asset supports burning, confirm the holder has a balance greater than zero, switch the register back to the current day, and confirm the role on the wallet that signs your actions.
A holder row shows Burn but it is disabled
Signal: the Burn entry appears on the row but cannot be selected. Cause: the asset is halted, or a corporate action that changes the asset's units is in progress. Fix: the message on the entry names which one applies. A halted asset needs resumed operations, and a corporate action needs to finish or be aborted.
A burn amount is capped below the balance
Signal: the amount field caps out below the amount you want to burn. Cause: the same address appears in more than one row in the same submission. The Console totals those rows and checks the sum against that one balance, not each row on its own. Fix: lower the amount, or combine the rows for that address into one row.
Mint or burn is blocked while a corporate action runs
Signal: the Mint tokens entry, or a holder row's “Burn” entry, is disabled and the menu shows “Stock split is in
progress on this asset. Minting waits until it finishes.” or “Stock split is in progress on this asset. Burning waits
until it finishes.”, with the name of whichever corporate action is running. Cause: an asset takes one corporate
action that changes supply at a time, and a run that has not completed or been aborted also blocks a direct mint or
burn. A mint or burn sent over the API in that window is refused with HTTP 409 CORPORATE_
(DALP-12067), and data.corporateActionId names the run that holds the asset. A run that has ended and is only
releasing the custody it froze (status “Releasing custody”) does not block a mint or burn, and neither does an action
whose approval was rejected, cancelled or lapsed before it ran. Fix: wait until the run completes, or abort it from
the Corporate actions screen, then mint or burn again.
Frequently asked questions
Why does the mint form show Subject to compliance limits instead of a number?
The Console can turn only the maximum-supply compliance rule into an exact remaining amount, because its maximum is a single token-denominated total on the module's own configuration. The Console counts it only when they apply to every transfer. Other modules that limit supply, such as a capital-raise, token-supply or issuance-volume limit, cap minting on-chain too. Nothing the Console reads exposes enough to compute a reliable remaining figure for them, so the form shows Subject to compliance limits in place of a number. When an asset with any module that limits supply also has a computable limit, the form shows that number and adds “Subject to compliance limits” beneath it. The chain enforces those modules on a mint whatever the form shows.
Is the Supply management role the same role that controls emergency halt and freeze?
No, they are separate roles. Mint and burn both check for the Supply management role, while emergency halt and resume check the emergency role and freeze and forced transfer check the custodian role, described on Emergency halt and freeze. An account can hold any combination of these on a given asset, so having one does not carry over to the others.
Does burning a holder's tokens need that holder's approval?
No. An account with the Supply management role opens the burn from the holder's row in the Holders tab and confirms it with their own wallet verification. The holder does nothing and is not asked.
Does a burn need the same eligibility check a mint recipient does?
No. A mint recipient must already be a verified holder of the token because minting can hand tokens to an address that has never held them before. A burn never introduces a new address. It only reduces a balance that is already listed on the Holders tab, so there is no equivalent eligibility gate to clear, only the balance cap from the burn form.