AboutbetterERC
A modular ERC-20 extension framework: a token declares what it does, and an integrator reads it in one call.
There are two questions. What does this token say it does, and can you believe it? The first costs one view call. The second costs one read of the token's own bytecode, and no trust at all.
Every ERC-20 on the EVM is its own program. An integrator who wants to know how one behaves has to read its source, or simulate a transfer and hope the result generalises. This project is the missing half — not new capabilities, but a declaration layer over the ones that already exist.
A declaration is only worth the code that produces it, so there is a second half. Canonical tokens are minimal-proxy clones of one shared runtime: forty-five bytes with nowhere to hide behaviour. Match the shape, read the address, and what the token says stops being a claim about itself.
Five modules
Identifiers are hashed from a name, not from an interface's selectors, so adding a view function to an interface does not silently change every deployed token's identifier.
Nine bits, one word. Six describe what a transfer does. Three describe what an authority can do to you.
One _update, four phases
Every balance change passes through a single override that fixes the phase order. Modules override phases instead of chaining super calls, so a module cannot change the order by being listed first, and each phase sees the arguments it was designed for.
Read the pipeline_update(from, to, value)
1. restriction checks
mint and burn arrive with the zero address intact
2. fee collection
own _rawUpdate, own Transfer event; skipped on mint/burn
3. the transfer itself
for value - fee
4. the hook
after balances settle, guarded, under a gas cap