The flags that name an authority

The behaviour word started as seven bits, and every one of them described a transfer. Value withheld, balances moving without an event, a call into another contract, a pause, a freeze, transfers that never work, code that can be replaced. It was a coherent vocabulary and it had a hole in the middle of it.

The third round of review found it by asking a question the design had never been pointed at: what does a token with no extensions installed report? Zero. And the specification defines zero as indistinguishable from a plain ERC-20.

Except it was not indistinguishable. Mint and burn live on the shared base, beneath every module, so that token still had a key that could create supply out of nothing and a key that could destroy any account's balance. It declared itself ordinary in the framework's own vocabulary, truthfully, by the rules as written.

The word was complete about transfers and silent about power. Those are not the same thing, and the second one is what surprises people.

Two kinds of bit

Fixing it meant admitting the word had been describing one thing while pretending to describe everything. The bits now fall into two groups, and the division is not cosmetic.

Bits 0 to 5

What the token itself does. Five of them change what a transfer does, so they show up in a simulation if you run the right one. Rebasing shows up instead as a balance that moved with no transfer event naming the account.

Bits 6 to 8

What an authority can do. Upgradeable, mintable, seizable. Nothing reveals any of these until they are used — which is exactly what makes them the ones an integrator discovers late, and usually at the worst moment.

So both reference tokens set mintable and seizable unconditionally. Not because those powers are always exercised, but because the functions are on the shared base and neither is optional. The rule that governs the rest of the vocabulary governs these too: a flag names what is installed, not what is switched on.

Seizable is not blocklist

The two get conflated, and the difference decides what a lender should do. A freeze stops value moving and leaves it where it is; it is reversible, and the account still owns what it owns. A seizure takes the value. The balance is gone, and no later transaction restores it.

For a protocol holding a position against a counterparty, that is the difference between a stalled loan and a loan whose collateral evaporated. It is why a frozen counterparty belongs in a liquidation model rather than only in a pre-transfer check — the freeze is often the step immediately before the burn.

And then the roles had to follow

Naming the two powers separately in the word made a single supply role indefensible. One key that could both dilute and seize, described by two independent bits, meant the vocabulary was finer-grained than the authorities behind it — and a specification that draws distinctions its implementation cannot hold is a specification that misleads.

So the role split too. Minting and seizing are separate keys, which bounds the damage from one compromised operator to one of the two powers. It is worth being exact about what that does and does not buy.

The split is operational, not structural. The admin role can grant itself anything, so separate keys limit an operator, never the owner.

Which makes the first question about any deployment not which key holds what, but who holds the role that can rewrite that answer — and whether it sits behind a timelock. Every other separation is downstream of that one, and a framework that let you skip it would be selling the same comfortable silence it was built to end.