Scanning

B20 tokens

B20 is Base's native token standard. Unlike a normal ERC-20, it bakes issuer powers straight into the token, so LENS reads a different and more dangerous set of signals.

B20 SCAN base · precompile 0xB20f…1c4a · $ASSET STOP freeze and seize — issuer can block your balance transfers paused — selling is halted right now no supply cap — mint role can print freely mint restricted to allowlisted wallets
a B20 scan reads issuer powers, not just balances

Why B20 needs its own scanner

A normal ERC-20 is just a deployed contract, and the risk lives in the dev's behavior. A B20 is a precompile with built-in issuer powers: the issuer can freeze and seize balances, mint without limit, pause transfers, and gate who is allowed to send or receive. These powers are part of the token itself, so a token can look perfectly fine on the surface and still let its issuer freeze your bag at will.

A deployer-history scan does not see any of this. LENS reads the powers directly off the precompile and turns them into the same CLEAR, CAUTION, STOP language.

What LENS reads

The scanner asks the B20 factory whether a contract is a B20, then reads its state directly, read-only, no key, no signature. Transfer-gating plus a seizable asset is a STOP. A paused transfer is a STOP. An uncapped supply is a CAUTION. Restricted minting is informational.

PrecompileAddress
B20 factory0xB20f…0000
Policy registry0x8453…0002
Activation registry0x8453…0001
json
// a B20 verdict comes back on the same /lookup endpoint
{
  "found": true,
  "source": "b20",
  "symbol": "ASSET",
  "verdict": "STOP",
  "transfer_gated": true,
  "paused_transfer": true,
  "supply_capped": false
}

B20 is not active on Base mainnet yet. LENS is already built to read it, so the day Base switches it on, scanning works through the same endpoint. See the B20 page for live status.