betterERC
Docs/Verification

Which tier is this token in

Three tiers, one bytecode read to tell them apart, and a precise account of what each one is worth.

All docs

Everything on the reference pages is produced by the token's own code. That makes each answer a claim, and a token declaring nothing while charging two percent of every transfer is simply a token that lied. Answering the second question first is what turns the rest of these pages from information into something you can put money behind.

TierHow you establish itWhat its declarations are worth
verifiedThe bytecode is a minimal-proxy clone of a runtime you knowGuaranteed. The answers come from the runtime you vetted, and the token's author had no way to alter it.
self-declaredIt answers behaviorFlags(), but the bytecode is its ownA claim. Far better than silence, and worth nothing if the author chose to lie.
unknownIt does not answer, or the code is unrecognisedNothing. Apply whatever policy you already use for arbitrary tokens.

What verification does not tell you

The word invites a stronger reading than the mechanism supports, so it is worth stating the limit before the mechanism. A verified token can charge the maximum fee. It can be paused. It can have every holder frozen and an authority able to burn any of their balances.

Verification tells you the rules are the published ones. It does not tell you that you will like them. Read the flags afterwards — the point is that now you can believe them.

Unknown is a real answer, not a fallback

The third row is the one integrators collapse, because there is a convenient way to make it disappear: catch the revert, call it zero, carry on. That turns "I could not classify this token" into "this token is ordinary", and the two differ in exactly the direction that costs money.

Silence is not a denial
A token outside this framework can still charge a fee. Its behaviorFlags reverts because the function is not there, not because the answer would have been zero.
An uninitialised clone reverts too
Nothing has sealed its extension set, so every discovery view refuses to answer. It is inert rather than dangerous — but anyone can initialise it afterwards, with a fee, and a zero you cached today would then be wrong.

Map the revert to unknown and hand it to the policy you already have. Every token on chain was in that category before this framework existed, so the policy exists whether or not you have named it.