06 · Not upgradeable
The runtime contains no DELEGATECALL. The code that is sealed is the code that runs.
The question
Is the code at this address the code that will run tomorrow?
A proxy delegates every call to an implementation address held in storage. Change the storage, change the token. A seal on a proxy's bytecode would be a seal on a door, not on what is behind it.
How it decides
The check disassembles the runtime bytecode, one instruction at a time. It walks the opcodes and skips the data bytes that follow every PUSH, so a 0xf4 inside a constant is not mistaken for an instruction. The CBOR metadata at the tail is set aside first for the same reason.
If DELEGATECALL (0xf4) occurs as an instruction anywhere: fail. The runtime contains DELEGATECALL: it can run code that lives elsewhere.
Otherwise: pass. No DELEGATECALL in the runtime. The code that is sealed is the code that runs.
What passes
Any plain contract. A token that calls other contracts with CALL (a router, a pool, an oracle) passes: those calls run the other contract's code in the other contract's context, and cannot change this one.
What fails
Every proxy pattern: transparent, UUPS, beacon, diamond, minimal clones (EIP-1167). Also any contract that links an external library with DELEGATECALL semantics, which is rare in tokens and correctly flagged when present.
Why the check is on bytecode
This is the one check that does not need the source at all, and that is a feature. Anyone with eth_getCode can re-run it and get the same answer. It is also the check that a zkVM proves most cheaply: a linear scan of a few kilobytes.
Known edges
None known. A contract cannot run code from elsewhere in its own context without DELEGATECALL (or the now-removed CALLCODE, 0xf2, which the check would treat the same way if it ever appeared).