Draft: ITokenFactory

[amiecorso]

Summary

Draft of the B-20 token factory interface. Not for merge. Posting so the team can react to the shape and the open design questions before we commit to anything.

Key design choice: no address prefix, registry-based dispatch

Earlier drafts proposed reserving 0xB200 / 0xB201 address prefixes for B-20 tokens. We dropped that approach because Base has roughly hundreds of pre-existing contracts at addresses already starting with any given 16-bit prefix; reserving the prefix would either break those contracts or require extensive scanning + grandfathering at hardfork time.

Instead: B-20 tokens have arbitrary-looking addresses (CREATE2-style derivation, no fixed prefix). The chain maintains an internal registry of "addresses that are B-20 tokens", populated by the factory at creation time. Dispatch is registry-based; `variantOf(token)` reads from the registry. Full rationale in FACTORY_DESIGN_NOTES.md.

What's in this draft

• Three creation methods (`createDefault`, `createStablecoin`, `createSecurity`), one per variant. Diverges from the PRD's unified `createToken(...variant...)` wording in favor of typed per-variant params; flagged as an open question.
• `TokenVariant` enum has only `NONE`, `DEFAULT`, `SECURITY`. No `STABLECOIN` value: Stablecoin is a Default token with `currency` set, distinguished via `isStablecoin(token)`.
• Default and Stablecoin share address derivation. `predictDefaultAddress` and `predictStablecoinAddress` return the SAME address for the same `(creator, salt)` pair (caller picks Default OR Stablecoin per slot; both can't co-exist).
• Security uses a different derivation domain. No collision with Default / Stablecoin even at the same `(creator, salt)`.
• Per-token custom decimals (immutable after creation, per IDefaultToken).
• `admin == address(0)` explicitly allowed for the "demonstrate no owner" case from the PRD.
• Initial supply bootstrap mint for Default and Stablecoin (atomic with creation, currently bypasses policy check; flagged).
• Permissionless creation. No factory admin.
• No wrapper coupling. Factory creates the token only.

Open questions (full list in FACTORY_DESIGN_NOTES.md)

1. `transferPolicyId` required vs default-to-always-allow at creation
2. Bootstrap mint policy bypass vs apply
3. Two-step "renounce last admin" pattern (not in v1, worth separate discussion)
4. Drop `STABLECOIN` from the enum entirely vs keep it (current draft drops)
5. Three separate functions vs one unified `createToken(variant, ...)` (PRD says unified)
6. Address derivation algorithm specifics (implementation-level, lock down before ref impl)
7. Capability bit validation at creation

Status

Draft. Looking for team reaction on the registry-vs-prefix decision and the other open questions before iterating further.