Verifying the code
One EXTCODECOPY against forty-five bytes, why it beats a registry, and why the answer is safe to cache forever.
All docs
Every canonical token here is an EIP-1167 minimal proxy pointing at one shared runtime. Its entire runtime code is forty-five bytes: a ten-byte prologue, twenty bytes naming the implementation, a fifteen-byte epilogue. There is no room in that for behaviour — no branch, no storage, nothing conditional.
So if the prologue matches, the epilogue matches, and the twenty bytes between them name a runtime you reviewed, then the token's code is that runtime's code. Not similar to it.
import {BERCVerification} from "berc/libraries/BERCVerification.sol";
/// Pin this in your deployment config. There is no discovery step.
address constant BERC_RUNTIME_V1 = 0x...;
if (BERCVerification.isClonedFrom(token, BERC_RUNTIME_V1)) {
// Verified. behaviorFlags() is produced by the runtime you reviewed.
}Why not a registry
A registry answers the same question with one call, and it is the obvious design. It is also strictly worse, for a reason that has nothing to do with the registry's code and everything to do with its write path.
- With an owner
- the owner can forge entries. The question becomes whether you trust that key — the same question you started with, moved one contract to the left.
- Without one
- it can never learn about a second runtime, so the answer set is 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 when that address is unreachable, misconfigured or hostile.
Bytecode has none of those problems. It needs no governance, cannot be rewritten, and answers identically at every block from every caller.
Resolve once, cache forever
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 verifies at every later block. Store the result beside the address and never run the check again.
Provenance is not the claim
A clone deployed by somebody who never touched the canonical factory verifies exactly the same, and that is correct rather than a gap: the guarantee is about which code runs, never about who deployed it. The factory does keep an index of what it made — use it to enumerate tokens for a UI, never to decide whether one is safe.
A zero runtime address fails the check by construction. A minimal proxy pointing at a code-less address delegates into nothing, which succeeds and returns empty for every selector — a contract that would pass a naive check while behaving like no token at all.