Who Can Change the Supply Rule?
Move mint authority to a multisig, test why the wrong actor is rejected, and see why revocation is a terminal commitment.
- Explain the difference between a supply cap and approval authority
- Observe handoff from a single signer to a multisig
- Judge which balance-changing actions remain after revocation
- PREVIOUSWho Gets Diluted, and Who Gets the Choice?
- CURRENTWho Can Change the Supply Rule?
Move mint authority to a multisig, test why the wrong actor is rejected, and see why revocation is a terminal commitment.
- NEXTFree sandbox
Think about these questions first.
Choose an answer before opening the explanation. You can add anything unexpected to your review list.
Q01Does renouncing ownership prove nobody can change supply?＋
Not necessarily. Mint roles, proxy upgrades, pausers, and multisigs may be separate powers. Security requires enumerating every state-changing path, not reading one owner label.
The hard part of a supply rule is not only the maximum; it is who can approve a change. Move mint authority from one creator to a 2/3 multisig, try the wrong actor, and then inspect why revocation is a terminal promise.
Authority is an executable boundary
An address label can say “multisig,” but only an authorization check can enforce it. The lab distinguishes three states: creator single-signature, 2/3 multisig, and revoked. Each state accepts a different mint actor—or no actor at all.
LAB / Virtual token
Every action changes a public state table. Ask who can change supply, who can claim, and who absorbs dilution.
The supply rule needs an approver, not just a cap
Move mint authority from the creator to a 2/3 multisig. A lone creator can no longer mint; revocation is permanent.
Locked units count toward total supply but cannot transfer yet. Color is secondary; numbers and labels are the state.
Start with the supply map: liquid balances, locked balances, and the mint authority are separate state variables.
- 02
Initial allocation recorded：创建者、社区、国库余额可用；另外 400,000 LAB 处于锁仓.
- 01
LAB created：总供应 1,000,000, 供应上限 1,200,000, 创建者保留增发权限.
Use the slider to return to an earlier step. Continuing from there replaces the later history with a new sequence.
Expand: how this step works
require(authority == msg.senderRole)
require(totalSupply + amount <= maxSupply)
transferAuthority(multisig)
revokeAuthority() // terminal state
Production systems add timelocks, proposal hashes, execution delays, and upgrade administrators. This lab compresses governance into a replayable authority transition so you can separate “who may execute” from “whether the payload is sensible.”
After mint authority moves to a 2/3 multisig, what should happen when the creator submits mint alone?
Four governance questions
- Are maximum, current total, and liquid supply recorded separately?
- Do mint, transfer, claim, and burn leave distinct events?
- Can handoff and revocation be deterministically replayed?
- Does the multisig reduce key risk, or are you mistakenly treating it as an economic decision-maker?