blueagent-b20-verify

name	blueagent-b20-verify
description	Verify whether a token on Base is a genuine B20 (Beryl Native Token Standard) before trusting or trading it. Use whenever a token claims to be a B20, sits at a 0xB200… address, or appears in a B20 launch feed. Reads state directly from chain via the B20 Factory precompile and multicall — never guesses.

B20 Verify — grounded, never guessed

The trap

Real B20 tokens live at 0xB200… addresses. That prefix is CREATE2 vanity — it is cosmetic and it can be faked. Plain ERC-20 contracts already squat 0xB200… addresses and name themselves "B20." Holder counts, token names, and address prefixes are all forgeable.

The address proves nothing. Only isB20() on the Factory proves authenticity.

Any tool that infers "this is a B20" from the address prefix, the token name, or a language model's impression of the contract is guessing. Guesses get people rugged.

Verify order (never skip step 1)

1. Ask the Factory

The B20 Factory is a protocol precompile at the same address on every Base network:

B20 Factory:         0xB20f000000000000000000000000000000000000
Activation Registry: 0x8453000000000000000000000000000000000001
Policy Registry:     0x8453000000000000000000000000000000000002

Call isB20(address) on the Factory.

• false → stop. It is not a B20, whatever it calls itself. Report that plainly.
• true → continue.

2. Multicall the token state

Only after isB20() returns true, batch-read the real state from chain:

• variant — ASSET (configurable decimals) or STABLECOIN (fixed decimals, currency code)
• supply and supply cap — note the no-cap sentinel is type(uint128).max, not MaxUint256
• roles — role-based access control holders (mint, pause, policy admin)
• pause state — per-feature, not a single global flag
• policies — per-scope transfer policies from the Policy Registry

3. Report what the chain said

Return the values as read. Do not smooth over gaps, do not infer missing fields, and do not fabricate a verdict the reads do not support. If a call reverts or an RPC fails, say so — an honest "unknown" beats a confident wrong answer.

Activation gating

B20 deployment is gated on-chain by the Activation Registry. Do not hardcode activation dates — read isActivated() from the registry. Before activation, a deploy reverts with FeatureNotActivated. An RPC failure should degrade to unknown, never to active.

Boundaries

• Read-only. This skill verifies; it does not sign, transfer, or deploy.
• No fabrication. Every field reported must come from an actual chain read.
• No custody. Nothing here holds user funds or keys.

Why this pattern generalizes

Any chain-native token standard with a factory or registry can be verified this way: ask the authority contract first, then read state, then report only what was read. The failure mode to design against is always the same — a cosmetic signal (address, name, holder count) that looks like proof but is trivially forgeable.