Mint and burn
Increase or reduce an asset's token supply from its management workspace.
Mint and burn are the two controls that change the number of units of an asset that exist. Mint creates new units and assigns them to one or more recipients, which raises total supply. Burn permanently removes units already sitting in a holder's balance, which lowers total supply. Neither one moves value between two holders the way an ordinary transfer does. Both change the total count of units in existence, not who holds a fixed pool of them.
Reach for one of these two controls only when the number of units in existence needs to change. If tokens need to move from one holder to another with total supply unchanged, that is a transfer, covered on Transfers, not mint or burn. If a holder's tokens need to stop moving without changing supply at all, that is a freeze, covered on Pause and freeze. Mint and burn also differ from each other in what happens next: a minted unit lands in a recipient's balance, where it can be held, transferred, or burned later. A burned unit has no recipient and goes nowhere. Minting the same amount back to the same address afterward creates new units; it does not restore the ones that were destroyed.
Mint and burn sit at the opening and closing edges of an asset's asset lifecycleAsset Lifecycle is the whole working life of a regulated tokenized instrument, from issuance through servicing to redemption, governed on one platform.Read the concept. Minting is how units first exist, most often to fund a primary distribution before any holder has a balance to trade. Burning is how units leave for good, most often at redemption, when an asset's life ends and its supply needs to shrink to match. Transfers preserve total supply. Offerings and corporate actions can also mint or burn units as part of their execution, so review the supply effect of the operation you select.
Minting adds units to the recipients and, when a fee applies, to the fee recipient. It adds units and, on a capped or collateral-backed asset, spends part of the room left before whichever limit binds. Each burn allocation removes units from its named balance and lowers total supply by that same amount. The one exception is a burn fee: when the organization charges one on the transaction, the balance still loses the entered amount, but total supply falls by a smaller net figure.
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; it never checks that the reserve the claim describes actually exists. Minting stops once the claimed amount is used up, so this bounds supply against an issuer's attestation rather than against verified backing. A compliance-module cap comes from a compliance rule attached to the token and enforced on-chain: the Console shows the room left when it can compute one, and otherwise leaves the check to the chain.
Steps
Open mint or burn
Open "All assets" and select the asset. For a mint, open "Manage Asset" and choose "Mint tokens". For a burn, open the "Holders" tab, find the address in the table, open its row menu, and choose "Burn". The burn form opens with that address already filled in; the amount field starts empty, and the row shows the address's available balance as its cap, covered next.
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; it is not limited to repeating the address it opened from.
Screen equivalent: the "Manage Asset" menu shows the supply controls allowed for the asset and signed-in account; 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; an address that is not blocks its own row with an ineligibility message until you enter one that qualifies. The form checks the running total against whichever supply ceiling applies and blocks continuing once the total would cross it. If a compliance-module cap cannot be read at the moment you submit, because that check is still loading or failed, the Console does not block you on that account. It lets the mint proceed and relies on the chain to reject it if the real on-chain cap would be exceeded; a fixed cap or collateral limit that is already known is still enforced client-side either way. 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 available balance, shown beside the field; the Console does not offer frozen units. The underlying administrative burn can consume frozen units through another authorized route, so a partial freeze is not protection against all burns. The asset's own configuration sets whether a burn fee applies, its rate, and who receives it; none of that is chosen 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.
Screen equivalent: the form contains one or more address and amount rows, the requested total, and the previewed transaction fee.
Confirm the supply change
Select "Confirm mint" or "Confirm burn". In the review dialog, compare the operation, addresses, amounts, and fees once more; when a fee applies, the dialog also names the account it goes to, not only the amount deducted. Select the final confirm control. The chain updates total supply and the affected balances in one transaction.
Burn cannot be undone from the Console. Once confirmed, the burned units are gone; there is no recall control and no way to restore them to the holder short of a fresh mint, which creates new units rather than returning the ones destroyed. A mint sent to the wrong address has no recall control either. Correction needs a separately authorized operation, such as a burn or custodian transfer, with the required role and sufficient balance.
Screen equivalent: the review repeats the operation, address rows, amounts, total, and fees before the final confirmation.
Mint adds to total supply from a ceiling: whichever of the three caps, a fixed supply cap, collateral-backed capacity, or a compliance-module cap, is smallest binds first. Burn removes from the balance in the opposite direction and, unlike mint, sends the removed units nowhere: a burned unit stops existing.
Troubleshooting
Continue stays blocked with no invalid row in sight
Signal: on a mint or a burn, every address and amount row looks valid, no cap warning shows, and "Continue" still will 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 available balance of every address in the form; while that read is loading or has failed, no row shows an available balance. Fix: wait for the fee preview and each row's available 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: "Manage Asset" opens but has no "Mint tokens" entry at all, not even a greyed-out one. Cause: your account holds no role on this token, so the Console does not show any supply, pause, or corporate-action control for it, mint included. An entry that appears disabled has a separate cause, covered next. Fix: confirm your account has any role granted on this token before assuming a mint-specific permission problem; a role added elsewhere makes the entry appear.
Mint tokens cannot be selected
Signal: the "Mint tokens" entry is visible in the "Manage Asset" menu but greyed out. Cause: one of three gates is closed. The asset is paused, your account lacks the supply management role, or, on a collateral-backed asset, collateral capacity is exhausted or its status 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, covered next. Fix: read the message the menu shows next to the entry, it names which gate applies. A paused asset needs unpausing first, a missing role needs granting elsewhere, and a collateral gate needs more collateral filed or the status to finish loading.
The requested mint total is rejected inside the form
Signal: the address and amount rows look valid, but 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 compliance-module cap the Console could read. 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 will 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 mint went through despite an unclear compliance cap
Signal: the mint succeeded even though you were unsure a compliance-module cap was being checked. Cause: while that cap's query is loading or fails, the Console does not block the mint on it; it relies on the chain to reject an over-cap mint instead. A fixed cap or collateral limit already known to the Console is still enforced before you submit. Fix: nothing to fix if the mint succeeded, the chain accepted it within the real limit. If it reverted instead, the on-chain cap caught what the form could not confirm in advance.
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 available balance is zero, or your account has no permissions on this token at all. Fix: confirm the asset supports burning, confirm the holder has an unfrozen balance above zero, and confirm your account has any role on the token before assuming a burn-specific permission problem.
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 paused, or your account has a different permission on the token but not the supply management role specifically. Fix: the disabled message names which one applies; a paused asset needs unpausing, a missing role needs granting elsewhere.
A burn amount is unavailable
Signal: the amount field caps out below the holder's total balance. Cause: only the available (unfrozen) balance can be burned. If 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 available balance, not each row on its own. Fix: lower the amount, or combine multiple rows for the same address into one row so the total is clear before submitting.
Frequently asked questions
Why does the mint form show "Subject to compliance limits" instead of a number?
The Console can only turn two compliance modules (capped and capped-v2) into an exact remaining amount, because their maximum is a single token-denominated total exposed directly on the module's own configuration. Other supply-limiting modules, such as a capital-raise 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" rather than a number it cannot back up. The chain still enforces those modules the same way regardless of what the form displays.
Is the supply management role the same role that controls pause and freeze?
No, they are separate roles. Mint and burn both check for the supply management role specifically, while pause and unpause check the emergency role and freeze and forced transfer check the custodian role, described on Pause and freeze. An account can hold any combination of these on a given asset, so having one does not carry over to the others. If a control you expect to use stays disabled, confirm which specific role it needs before assuming your access is broken.
Does burning a holder's tokens need that holder's approval?
No. Burn is an administrative control: an account with the supply management role opens it from the holder's row in the "Holders" tab and confirms it with their own wallet, and the affected holder does nothing inside the Console. The role check and the available-balance cap are what stand between an account and this control, not consent from the address being burned from.
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 available-balance cap covered above.