Mint and burn permissions

EN source master · P08-L03 · 45 minutes estimated · needs_review

“Mint disabled” and “burn enabled” sound simple, but they describe specific operations under specific authorization rules. A token holder burning their own units is different from an administrator affecting another holder's balance. A cap constrains quantity only if the relevant path actually enforces it.

Your task is to enumerate supply-changing capabilities, conditions and scope. You are evaluating permissions, not teaching token issuance or making a prediction about whether an authority will act.

Ask who can do what to which balance

A permission record should name operation, controlling account or role, target scope, quantity constraints and changeability. “Admin present” omits the most useful information. Minting to a recipient, burning one's own balance and burning a third party's balance are different capabilities.

For each path ask whether the check concerns the caller, an allowance, a role or a program-mediated condition. Record the condition literally enough to reproduce the reasoning. A function name is not its implementation: a method named burn might internally transfer units, and a method named distribute might mint them.

Use a capability table with evidence pointers. If an operation was observed historically, it supports that event; it does not alone prove every present permission. If a permission exists in a snapshot, it supports availability under conditions; it does not prove it has been exercised.

Distinguish standard burn paths

Solana's standard burn reduces the account balance and mint supply. Authorization can come from the token-account owner or approved delegate; Token Extension Program permanent delegation adds a mint-level route [S08-BURN]. An ordinary approval is scoped to the relevant account and amount, so do not describe it as general administrative ownership.

The PermanentDelegate extension can authorize transfers and burns across accounts of its mint; token-account owners cannot revoke it locally [S08-DELEGATE]. This is a concrete reason to inspect extension state rather than concluding that all authority disappears when mint authority is absent. Do not infer that the extension exists merely because the token uses an extension-capable program.

OpenZeppelin ERC20Burnable distinguishes own-balance destruction and allowance-based burnFrom. Capped behavior constrains minting under that implementation [S08-OZERC20]. Library documentation supports these patterns, not a finding that any particular deployed contract includes them. Inspect actual code and state.

Treat supply caps as conditional claims

A cap has a unit and a context. A maximum of 1,200 displayed tokens with six decimals represents 1,200,000,000 raw units. Comparing a displayed current total with a raw cap can create a false headroom estimate.

The cap is meaningful only for paths enforcing it. If other paths bypass the check, or if an upgrade can change the rule, report those boundaries. In this fixture the supplied rule covers all listed mint calls under the current implementation. Future implementations are explicitly outside the complete-path assumption.

Burns can reduce total supply and create headroom under a total-outstanding cap. A lifetime issuance limit is a different policy. Never assume one from the word “cap.” State whether the rule counts outstanding supply, cumulative issuance, an epoch budget or something else.

Inspect role administration

Role membership and role administration are distinct. An account able to grant a minter role can indirectly create future minters even if it cannot mint under its current membership. OpenZeppelin AccessControl uses role-specific checks and administration; Ownable is a different pattern [S08-ACCESS]. A generic owner field cannot summarize every authorization path.

Follow the chain far enough to describe who can alter the permission. If an administrator is a contract, its signers, threshold and delay need separate evidence. A label saying multisig is not a threshold proof. If those details are unavailable, retain the contract role and mark its controlling arrangement unknown.

Supply-changing authority and upgrade authority are related but separate. This lesson identifies a supplied upgrade gap; P08-L04 analyses it directly. A “fixed under current rules” conclusion cannot silently become “fixed forever” when the logic can change.

Separate potential behavior from completed events

A successful supply-changing operation requires more than a submitted transaction or event-like label. Check execution result, affected asset, accounting delta and context. Failed attempts should not be added to supply. Transfers to an inaccessible address may reduce accessible inventory without reducing protocol total supply.

Even a verified burn says nothing about price appreciation. Quantity and market execution are different measurements. Likewise, an available mint privilege is not proof of malicious intent. A professional finding states scope and conditions, then asks what evidence would resolve gaps.

Write a bounded permission finding

Prefer “At S0, M can increase supply up to the outstanding-total cap under the supplied current rule; G can grant that role” to “the token is inflationary and unsafe.” The former is reproducible; the latter bundles an undefined economic classification with an unsupported recommendation.

When revocation is supplied, name the exact role. Solana authority removal is role-specific [S08-SET]. Removing a mint role does not logically remove an independent delegate, freeze role or implementation-change path.

• Mint permission: capability to increase accounting supply.
• Burn permission: capability to reduce balances and supply under a rule.
• Allowance: amount-scoped permission associated with a holder and spender.
• Permanent delegate: mint-level Token Extension Program authority.
• Outstanding cap: maximum present supply under the supplied rule.
• Role administrator: account able to change membership.

ILLUSTRATIVE — FIX-P08-03. Two separate fictional assets at S0; labels are invalid and not execution instructions.

E3's hypothetical burn of 40 precedes a hypothetical mint of 220. H has sufficient balance and both operations succeed under supplied rules. No other supply changes occur.

OBSERVED in fixture: MINT-P has no mint authority but has D; TOKEN-C has a constrained mint path and role administrator.

INFERRED: TOKEN-C has 200 initial cap headroom; after burn 40 it has 240, so mint 220 fits and leaves total 1,180.

UNKNOWN: D's controlling human, omitted extension behavior, TOKEN-C upgrade control and future rule changes.

INSUFFICIENT EVIDENCE: Absent mint authority does not prove MINT-P balances cannot be burned. A cap does not establish immutable supply policy or a price outcome.

Equating mint revocation with all-privilege removal; treating own burn as arbitrary third-party burn; ignoring role-grant paths; mixing raw/display caps; and assuming burns guarantee appreciation.

Write a capability table for S1/S2 and E1–E4. Calculate initial and post-burn headroom and final supply. Assess whether G can affect future minting and whether J can burn 100 from H under the supplied allowance.

• Name operation, target and condition.
• Verify amount units and current total.
• Distinguish current role from role administration.
• Inspect relevant extensions.
• Separate completed supply changes from available powers.
• State unresolved implementation-change paths.

Permissions are conditional capabilities. A useful review distinguishes supply creation, balance destruction and the power to change who may act.

No mint role does not mean no other controls. A cap needs a definition and enforcement scope. Authority availability is not evidence of intent.

Create two separated permission matrices for MINT-P and TOKEN-C with actor,operation,target,condition and evidence row. Add current cap arithmetic200→240→20 remaining headroom. Show upgrade gap as unknown, not absent.

Illustrative authority scope and outstanding-supply cap; no deployed-token finding.

Use deterministic SVG/HTML or charts with text alternatives, dark navy/black and restrained cyan, electric blue and violet. Label every quantity and uncertainty. At 390px stack panels; 768px/desktop and Arabic RTL verification remain future asset work. Keep identifiers LTR and factual axes/edge directions unchanged. Use only the official supplied ZECOIN mark if branding is added. Both records are specifications, not delivered assets.

Use RADAR for the lesson's bounded educational purpose only if network support, exact identity, fields and provenance are verified. No runtime endpoint or provider capability is asserted by this content. Use the embedded offline fixture without paid access. Missing data stays unknown; no wallet connection, transaction signature, token launch or live trade is required. Academy progress, payments and referrals never change Radar evidence. A Diagnostic Passport preserves observations and limits, not a price prediction or safety certificate.

• Solana Burn Tokens — Standard burn authorization and effect on account balance and mint supply. Checked 2026-09-30.
• Solana Permanent Delegate — Token Extension Program mint-level transfer/burn authority. Checked 2026-09-30.
• OpenZeppelin 5.x ERC20 — Burnable, capped and pausable extensions; library behavior is not proof of deployed code. Checked 2026-09-30.
• OpenZeppelin 5.x Access Control — Ownable and role-based privilege patterns; inspect actual deployed authorization. Checked 2026-09-30.
• Solana Set Authority — Role-specific changes and revocation; not a global safety verdict. Checked 2026-09-30.

Documentation supports mechanisms, not fictional dataset values. All examples and exercise records are original ILLUSTRATIVE material, frozen in this file. S0/S1 are synthetic context labels; observedAt is null because no live or historical ledger measurement was collected. Re-review documentation and actual deployed behavior before any publication or integration.

P08-L04 after the worked exercise and quiz review.