A freeze that survives the burn
Pausing a token does not stop it minting. Burning works on a frozen account. Both asymmetries read as bugs until you ask what the authority pulled the lever for.
The restriction module gives a token two levers: a global pause and a per-account freeze. Both are aimed at transfers, and neither behaves the way a first reading would suggest.
- Transfer
- Rejected if the token is paused, if the sender is frozen, or if the recipient is frozen.
- Mint
- Allowed while paused. Rejected into a frozen account.
- Burn
- Allowed while paused. Allowed from a frozen account.
Why a pause does not freeze supply
A pause is an emergency brake on circulation, pulled by somebody who has just discovered that something is wrong. If it also stopped minting and burning, it would remove the authority's ability to correct whatever caused it — the token would be bricked at exactly the moment it most needs intervention. A brake that also welds the steering column shut is not a safety feature.
Why a burn works on a frozen account
Freezing is what an issuer does immediately before seizing. If burning from a frozen account reverted, the freeze would have to be lifted first, and that window is precisely what the freeze exists to close. Minting to a frozen account stays rejected, because crediting an account nobody may transact with is a mistake with no upside at all.
Reported the way the ecosystem already reads it
The module answers through the two functions ERC-1404 defined for restricted transfers: a numeric code, and a human-readable message for that code. Reusing an interface that already exists costs nothing, and it means a wallet that already handles restricted tokens gets a usable error string without knowing anything about this framework.
A bespoke error type would have been marginally more expressive and would have started the integration story from zero. There is enough new surface in a specification like this without inventing a replacement for something that already works.