How Treasury Desk AI Would Review a New Token Standard

Treasury Desk Brief · Token Standard Review

Public-source token-standard review Treasury-control checklist Retrieval date: 2026-07-12 Educational discussion only

Base B20 as a Treasury-Control Case

A public-source workflow for human review, not AI approval.

Executive summary

Base’s official documentation places B20 inside the Beryl upgrade and describes it as a native token standard, an ERC-20-compatible superset and a precompile-based implementation.
A token standard can become a treasury-control surface, but the existence of the standard does not prove issuer quality, compliance, safety, adoption, reserve quality or treasury suitability.
A reviewer-first workflow should capture the public claim, open official docs, extract control primitives, separate protocol capability from issuer configuration and route unresolved issues to human review.
The B20 sources expose control primitives a reviewer can map: factory and registry architecture, roles, admin and admin-renunciation paths, mint / burn, pause, policy scopes, supply caps, metadata, memos, permit support, variants and event surfaces.
Evidence remains bounded: official live B20 issuer examples and an official B20 audit report were not identified in the reviewed official sources; a live Activation Registry read was not executed in the source-pack run; token-specific explorer states remain open.
This article does not approve B20, recommend Base or any token, certify issuer controls, verify reserves or replace legal, compliance, security, audit, accounting or treasury review.

A token standard is also a control surface

A new token standard is not only a developer primitive. For treasury and finance reviewers, it is also a control surface.

The first job is to separate what the standard supports from how a specific issuer configures and operates a token. A pause function does not prove a good incident policy. A supply cap does not prove conservative issuance. A blocklist does not prove compliance. A currency field does not prove backing.

That is the useful reviewer frame for B20: protocol capability first, issuer configuration second, offchain disclosure third, human review always.

What is Base B20?

Base’s Beryl overview places B20 inside the Beryl upgrade. The B20 Native Token Standard describes B20 as Base’s native token standard and an ERC-20-compatible superset implemented through Base-native Rust precompiles.

Official Base docs and the Base Standard Library show a factory / registry architecture around B20, including a singleton factory, Activation Registry and Policy Registry. The documented variants are ASSET and STABLECOIN.

Official docs present B20-related network paths, including mainnet, Base Sepolia and Vibenet. The source pack keeps activation wording conservative: a live Activation Registry read was not executed in that run, so a final publication should refresh the Activation Registry check and official deployment documentation before stating current activation. Vibenet is described in source-pack context as experimental and not intended for production or user-facing apps.

Official live B20 issuer examples and an official B20 audit report were not identified in the reviewed official sources.

How Treasury Desk AI would review it

This is an illustrative, human-reviewed workflow:

Capture the claim being made about B20.
Open official sources rather than relying on social summaries.
Extract mechanics: factory, variants, roles, policies, caps, pauses, metadata, permit and events.
Map control primitives into reviewer questions.
Separate protocol capability from issuer configuration.
Log missing public and offchain evidence.
Route open issues to human legal, compliance, accounting, audit, treasury, operations and security reviewers.

AI boundary. Treasury Desk AI can organise sources, statuses, gaps and reviewer questions. It does not approve a standard, certify a token, audit code, validate compliance, verify reserves or replace professional judgment.

Evidence state

Evidence item	Current source-pack status	Safe reading
B20 inside Beryl	Confirmed by official docs	Standard-level fact, not adoption
B20 native / ERC-20-compatible superset	Confirmed by official docs	Capability description, not endorsement
Factory / registry architecture	Confirmed by official docs and repo interfaces	Architecture, not issuer legitimacy
Mainnet / Sepolia / Vibenet paths	Partial / docs-level	Live registry refresh required before a live-state claim
Official live B20 issuer examples	Not identified in the reviewed official sources	Do not invent token examples
Official B20 audit report	Not identified in the reviewed official sources	Do not imply audit or security assurance

B20 feature map

Primitive	What official sources support	Control question	What it does not prove
ERC-20-compatible superset	Standard ERC-20 calls plus B20 surfaces	Will current systems handle the added features?	Integration quality or suitability
Factory / registries	Singleton factory, Activation Registry and Policy Registry	Which network and deployment path created the token?	Issuer legitimacy or adoption
Roles / admin-less path	Admin, mint, burn, pause and metadata roles; final-admin renunciation	Who holds privileges, and were they renounced?	Governance quality or safety
Mint / burn / blocked burn	Role-gated supply changes and `burnBlocked` path	Who can create or destroy balances?	Reserve backing, legality or treatment
Pause / supply cap	Granular pause controls and optional cap	What can be paused or capped, and by whom?	Operational resilience or credit quality
Policies	Allowlist / blocklist model with sender, receiver and executor scopes	Which transfers or actors are constrained?	Compliance sufficiency
Memos / metadata / permit	Memo events, contract URI, ERC-2612 / EIP-712 support	What operational evidence and authorization surfaces exist?	Business purpose or integration security
Variants	`ASSET` and `STABLECOIN` variants	Which variant was deployed?	Issuer quality or asset classification

Protocol capability versus issuer configuration

A protocol / standard capability is what B20 supports. Issuer configuration is how a specific token issuer sets roles, policies, caps, pauses, metadata, mint / burn paths and operations.

Issuer quality, compliance, reserve quality, legal status and adoption are not proven by B20 docs alone.

B20 capability	Issuer decision / configuration	Public evidence	Offchain disclosure needed	Unsafe inference to avoid
Admin and roles	Who holds them; whether admin was renounced	Role reads and events	Governance / key-control policy	“Admin-less means safe”
Mint, burn and cap	Who can change supply; cap value	Role and supply events	Issuance / redemption policy	“Capped means backed”
Pause and policies	Current state, policy IDs and scopes	Pause / policy reads and events	Incident and screening rationale	“Blocklist means compliant”
Memos and metadata	Whether and how they are used	Memo / metadata events	Business taxonomy and disclosure process	“Onchain memo proves purpose”
Stablecoin currency field	Code chosen at creation	`currency()` and creation parameters	Reserve, legal, redemption and issuer evidence	“Currency code proves a stablecoin”

Stablecoin variant review

Official sources describe a STABLECOIN variant with fixed six-decimal precision and a currency() field. The source pack treats that field as self-declared rather than externally verified against a reserve, issuer or regulatory source.

The field can show how the deployer configured the token. It cannot establish reserve backing, redemption rights, regulatory approval, issuer quality, legal status, accounting treatment or treasury suitability. A reviewer still needs issuer-specific disclosures and operating evidence.

Onchain / explorer verification

Official sources document canonical factory and registry surfaces, deterministic address logic and public event surfaces. The IB20 interface exposes role, policy, pause, supply-cap, metadata and memo-related methods and events. Coinbase’s Query B20 Events documentation describes indexed event types.

For a confirmed token address, public sources may help check creation, variant, roles, admin renunciation, mint / burn events, cap, pause state, policies, metadata and memos. But the source pack does not identify official example live B20 tokens, so token-specific states remain unverified in this review unless a future official source and corresponding explorer record are added.

Evidence boundary. Onchain visibility is not legal, compliance, reserve, accounting, issuer-quality or token-safety proof.

Treasury-control checklist

Reviewer question	Source to check	Public evidence can show	Public evidence cannot show	Handoff
Who holds admin and can admin be removed?	B20 docs / `IB20.sol`	Role state and renunciation events	Governance quality	Governance / security
Can supply change or be capped?	Roles, mint / burn and cap events	Capabilities and visible changes	Backing / accounting treatment	Treasury / accounting
Can transfers, mint or burn be paused?	Pause reads and events	Current feature state	Incident readiness	Ops / security / legal
Can accounts be blocked or balances burned?	Policy Registry / `burnBlocked`	Policy and third-party-burn capability	Lawfulness / compliance	Legal / compliance
Are sender / receiver / executor policies active?	`policyId(scope)` / policy events	Policy IDs and assignments	Policy quality	Compliance / ops
Are memos available for operational evidence?	Accept B20 Payments / event index	Public reference trail	Complete business purpose	Finance ops / audit
Are events emitted for role / supply / pause / memo / metadata changes?	`IB20.sol` / CDP event docs	Observable change trail	Complete control effectiveness	Audit / finance ops
Is the stablecoin currency field externally verified?	B20 docs / stablecoin interface	Self-declared configured value	Reserves / approval / suitability	Legal / accounting
Can protocol capability be separated from issuer configuration?	Source pack + official docs	Standard-level capability	Issuer due diligence	Human review lead

What public sources can and cannot decide

Official Base docs support standard identity, documented mechanics, network wording and architecture. The official repo and raw interfaces support method, event and role definitions. EIP pages provide standards context. Explorer or event-index sources can support token-specific public state when a confirmed address exists.

They cannot decide token safety, issuer quality, issuer compliance, reserve backing, legal status, accounting treatment, audit assurance, adoption, suitability or whether a treasury should use B20, Base or any B20 token.

What this does NOT prove

This material is not investment advice, trading advice, legal advice, tax advice, accounting advice, compliance advice, audit assurance, reserve verification, a token-safety review, an issuer-quality review, a stablecoin recommendation, a chain recommendation or a product recommendation. It does not prove adoption, Treasury Desk demand, WTP, PMF, traction or revenue. It does not establish that any B20 token is safe, compliant, reserve-backed or treasury-suitable. Human review remains required.

Discussion question

Where do token-standard reviews usually confuse protocol capability with issuer configuration?