Forty-five bytes with nowhere to hide

Everything written here so far asks the token. What extensions do you have, what is your fee, may this account transfer. Each answer is better than the silence a plain ERC-20 gives you, and each answer is a claim.

A claim is enough for discovery. It is not enough to put money behind, because the failure mode is not subtle: a token that reports zero while withholding two percent of every transfer has told an integrator exactly what they wanted to hear, and the code that told them was written by the party who benefits.

A declaration is only worth the code that produces it.

Removing the token's opinion

So the second question is not asked of the token at all. Every canonical token here is a minimal proxy — the EIP-1167 pattern, forty-five bytes of runtime code that do nothing but forward every call to one shared implementation. Ten bytes of fixed prologue, twenty bytes naming the implementation, fifteen bytes of fixed epilogue.

That shape is the whole argument. There is no room in forty-five bytes for behaviour, no branch, no storage, nothing conditional. If the prologue matches, and the epilogue matches, and the twenty bytes between them name a runtime you reviewed and pinned, then the token's code is that runtime's code. Not similar to it. It.

if (BERCVerification.isClonedFrom(token, BERC_RUNTIME_V1)) {
    // Every answer below comes from the one runtime you vetted.
    // The token's author had no way to alter it.
}

One EXTCODECOPY. No external call, so nothing can reenter and nothing can lie by reverting. No registry, so nothing to govern. The check is a pure function over bytes that are already on chain.

Why not a registry

A registry answers the same question with a single call, and it is the obvious design. It is also strictly worse, and the reason is worth being precise about: a registry is only as honest as its write path.

Give it an owner

and the owner can forge entries. The question becomes whether you trust that key, which is the same question you started with, moved one contract to the left.

Give it none

and it can never learn about a second runtime. The design is then frozen at whatever was true on the day it was deployed.

Either way

verification becomes a call to an address you also had to obtain from somewhere trustworthy, and it stops working the moment that address is unreachable, misconfigured, or hostile.

Bytecode has none of those problems. It needs no governance, it cannot be rewritten, and it answers the same at every block from any caller. There is a factory in this repository, and it does keep an index of the tokens it deployed — but that index is for enumerating tokens in a UI, and the code says so in as many words. It is not a thing to trust.

Provenance is not the claim

A clone deployed by somebody who never touched the factory verifies exactly the same, and that is correct rather than a gap. The guarantee is about which code runs. It was never about who deployed it. A design where the factory conferred legitimacy would be a registry again, wearing a different name.

Cache it and never look again

A minimal proxy contains no self-destruct, and since EIP-6780 an account can only be destroyed in the transaction that created it. A token that verifies at one block therefore verifies at every later block, forever. Resolve a token once, store the answer beside the address, and the check never has to run again — which matters, because a guarantee that has to be re-established before every interaction is a tax rather than a guarantee.

What a pass does not mean

It is worth being blunt here, because the word verified invites a stronger reading than the mechanism supports. A verified token can charge the maximum fee. It can be paused. It can have every holder frozen, and an authority who can burn any of their balances.

Verification tells you the rules are the published ones. It does not tell you that you will like them.

What it establishes is identity, not quality — and identity is worth exactly as much as the review behind the runtime address you chose to pin. Read the flags afterwards. The point is that now you can believe them.

The price: one deployment has to hold everything

A clone cannot add code. So every extension any canonical token might ever want has to fit inside a single deployed runtime, and that runtime is the row of the size table that constrains the whole design: 18,053 bytes against a 24,576-byte limit, with 6,523 to spare.

Those free bytes are the entire budget for everything this runtime will ever support. Which is why it ships the five modules it has and no more, and why new capability arrives as a new runtime with a new address rather than as an addition to this one. An integrator pins a runtime and gets a set of behaviours that is closed as well as fixed — and the day that set needs to grow, they will have to look at the new address and decide again. That is the honest shape of the trade, and it is a better one than a set that could quietly grow underneath them.