A token, part 3: caps and burning

A maximum supply is a promise. Enforce it in code, because that is the only place anyone can verify it.

A token that claims a fixed supply and enforces it only in its README has not promised anything. The cap belongs in mint:

abi.require(_uget(K_TOTAL) + amt <= _uget(K_MAX), b"cap_exceeded")

Burning is the reverse of minting: take units out of the caller's balance and reduce total supply by the same amount.

Burn must reduce total supply. A burn that deducts a balance without lowering the total leaves the contract claiming more tokens exist than the sum of all balances. Nothing breaks immediately — which is why this bug survives into production and then makes every downstream calculation subtly wrong.

A cap of 0 conventionally means "uncapped" in the Animica token standard. That is a design decision you should state in your ABI documentation, because the alternative reading — a token that can never mint anything — is equally plausible to someone reading only the code.

Your turn

Add a cap and burning. init(max_supply) sets the cap (0 means uncapped). mint must reject anything that would exceed it with b"cap_exceeded". burn(amount) removes the caller's tokens and lowers total supply.

Hints

Stuck? Ask

Answered by Animica's own free inference network. It is donated GPU capacity, so give it 20-30 seconds.