betterERC
Docs/Verification

The shared runtime

One deployed contract every canonical token executes, why it carries modules a given token never installs, and the size budget that closes the set.

All docs

The guarantees an integrator gets on a chain with a single shared token program come from there being exactly one program: a wallet does not audit each mint, it audits the program once and every mint inherits that audit. This runtime is the closest an EVM chain gets. Deployed once, never upgraded, and pointed at by every canonical token — so what you verify is not a token but an address.

Why a clone rather than a proxy the token controls

The upgradeable reference token declares UPGRADEABLE and means it: its upgrade authority can point the proxy at any implementation, including one with a different extension set, and nothing on chain prevents that. It is an honest declaration of a real power, and it is also why a token that wants to be believed cannot be built that way.

A clone has no admin slot and no upgrade path. Its forty-five bytes name this runtime and can never name another, so the extension set you read today is the set that will be there in a year — a fact about bytecode rather than a promise from an issuer. New capability arrives as a new runtime and new tokens. Existing tokens keeping their behaviour forever is the product, not a limitation of it.

Every module inherited, a subset installed

A clone cannot add code, so the runtime carries every extension any token might want and each token turns on a subset at initialisation. Modules that read configuration are naturally inert when unconfigured: an unregistered fee module has a zero rate, an unregistered restriction module blocks nothing.

Non-transferability is the exception, because its check is unconditional by design, so it is gated on registration explicitly. And because every module's setters exist on every token, the authorisation dispatch rejects configuration of extensions this token did not install — without that, a token reporting no fee extension could still be given one.

The budget that closes the set

ContractBytesOf the 24,576 limitFree
ExtendedTokenUpgradeable20,04381.6%4,533
BERCRuntimeV118,05373.5%6,523
ExtendedToken15,44262.8%9,134
BERCFactoryV14,19517.1%20,381

The runtime is the row that constrains the design. Its 6,523 free bytes are the entire budget for everything this version will ever support, which is why it ships five modules and no more. An integrator who pins this address gets a behaviour set that is closed as well as fixed.

Initialisation is a race only if you make it one

Cloning and initialising must happen in the same transaction. The canonical factory does both; anyone cloning the runtime directly must do the same, or a front-runner initialises the clone with themselves as admin. An uninitialised clone is inert rather than dangerous — nothing has sealed its extension set, so every discovery view reverts.

The runtime locks its own storage in its constructor. Without that it could be initialised directly, producing an address that passes no clone check but answers every call — a decoy that looks canonical to anyone who verified by asking rather than by reading code.