BIII

Safe-to-pay verdicts on Base, with the evidence attached: 29 tools, 55 modules, 142 test files, 54 probes that publish their own bounds. Non-custodial, descriptor-only, every verdict re-verifiable on-chain.

Spoken "B3". Written BIII — a B with three bars. The real-world USDC till on Base: an independent merchant accepts USDC in person with just a phone. Non-custodial (their own wallet), no terminal, no PSP, no KYB middleman.

B = Base · 3 = phase three of the trilogy, and Base's three pillars.

The gap (researched, not assumed — 2026-07-21)

Accepting USDC on Base is solved for the online enterprise and unsolved for the real-world independent:

Nobody serves the café, the market stall, the plumber, the freelancer who wants to take USDC on Base with just a phone, keep the funds in their own wallet, and hand over a real receipt — in two minutes, with no account to open.

(Landscape verified on the date above; re-check before any public claim. We build compatible with Base/Coinbase/Flexa/Lyzi and claim no partnership.)

The trilogy — phase 3: the agentic economy pays real-world humans

MainStreet   →  WHO is safe to pay            (the reputation oracle)
LAWBOR       →  agent ↔ agent, outcomes PROVEN paid in USDC on Base
BIII         →  agents & humans  →  REAL-WORLD merchants     ← this

BIII is the bridge between the on-chain agent economy and the shopkeeper on the corner. The same "safe to pay" and "proven paid by a real USDC transfer" discipline, pointed at a till.

How it works

1. Merchant types an amount. → a charge (data only; the merchant's own address).
2. BIII shows a universal QR — an EIP-681 payment URI that every major wallet scans (Base App, Coinbase Wallet, MetaMask, Rainbow…).
3. The customer (or an AI agent) pays USDC on Base from their own wallet.
4. BIII watches the chain and verifies the transfer field-for-field — wrong token / chain / recipient / underpaid / unconfirmed ⇒ not paid, ever. Overpay is a tip.
5. Both sides get a receipt anchored to the txHash (refutable by anyone on Basescan).

BIII holds no key and moves no funds. It mints intents and reads the chain; the customer's wallet signs, and the chain — not us — is the only thing allowed to say "paid".

Run it

npm test                               # all offline; 1269 assertions across 96 files + a 22-case eval harness (2026-08-05)
node test/suite-total.js               # re-derives that count — two report formats coexist, so grep undercounts it
BIII_MERCHANT=0x<your address> npm run serve   # the non-custodial HTTP surface, :4700

• lib/till.js — pure core: money math, charges, EIP-681 URIs, verification, receipts
• lib/chain.js — read-only Base watcher (finds the paying transfer; never invents)
• lib/server.js — thin HTTP: /charge, /status, /receipt, /trust (the LOCAL safe-to-pay verdict as ONE fetch() — known-bad screen + this node's trust-core classifier + floor provenance, fail-closed, CORS-open: any web app embeds a pre-payment check with no MCP; shares lib/vet.js with the MCP tool so the two surfaces cannot drift), /asset (tokenized-asset authenticity as one fetch — genuine/impersonation/unsafe/unknown, fail-closed: a non-registry token is never a false genuine; a pre-trade check any page embeds and re-verifies on-chain)
• lib/trust.js — the trust triangle: composes reputation (MainStreet) + standing (LAWBOR) + settlement (chain) into one fail-closed verdict (unsafe/unknown/trusted/settled)
• lib/invoice.js — the same registry for Web2-style invoices: number, line items (exact micro math), due date, bill-to — paid by the same EIP-681, verified by the same chain discipline, settled/overdue lifecycle, and its receipt lands in the SAME provable till roll as a café sale
• lib/asset.js — the same registry for TOKENIZED ASSETS (stocks / treasuries / RWA): is a token contract the genuine issuer's or an impersonator? genuine / impersonation / unsafe / unknown, fail-closed — catches the FBI-flagged lookalike-token fraud, and composes into the trust triangle (till_vet_asset).
• Issuer-verified registry (data/issuer-verified.json, committed, multi-chain) — the AUTHORITATIVE, no-key, commercial-safe layer that earns the strong green "issuer-verified" badge. 183 entries across 11 chains (counted 2026-08-05 by hermes/economy/probe-readme-claims.js, which reads the registry rather than this sentence), all from ISSUER-DIRECT sources: Dinari dShares (54, Base — enumerated on-chain from the factory's DShareAdded event, each re-verified via symbol()/name(); scripts/biii-rwa-issuer-direct.js), Backed / xStocks (100 across Ethereum/Optimism/BSC/XLayer/Mantle/Arbitrum/Ink from Backed's own public API api.backed.fi, no key, plus 12 on Base from backed-fi/tokenlists; scripts/biii-issuer-backed.js), Ondo (9 OUSG/USDY/rUSDY — official docs, each on-chain-verified), and 8 single-issuer entries on Base (Circle USDC/EURC, Coinbase cbBTC/cbETH, Franklin Templeton BENJI, Lido, Aerodrome). lib/asset-registry merges this over the aggregator by address, so a verified address reads provenance: issuer-official (green) while everything else stays aggregator-teal.
• scripts/biii-rwa-registry.js — builds the AGGREGATOR fallback (the teal "listed" layer). Coingecko's free tier (no key) → data/rwa-registry.json, generatedFrom: "coingecko (free)". Coingecko is an AGGREGATOR, so a match here is provenance: aggregator (teal "listed"), never the issuer-verified green — and the cross-check (scripts/biii-issuer-registry.js) flags any symbol the aggregator lists at a different address than the issuer-official one (potential lookalike). Fail-safe: every entry must validate (0x-40hex · integer chainId · symbol) or it's dropped — a schema drift yields an EMPTY registry, never a wrong "genuine" address.
• lib/export.js — the accounting export finance teams need: till_export turns the same verified receipts into an accountant-ready CSV (QuickBooks / Xero / Excel import it) where every row carries its txHash + Basescan link — a pointer to the chain, not a book to trust. Non-custodial, re-verifiable.
• lib/meter.js — the usage→bill mechanic for a white-label pilot: till_meter turns a month's receipts into a bill against an injected plan, split by trust — settled receipts are ON-CHAIN (provable), the verdict count is SELF-REPORTED (advisory) and labeled as such. Pure, stateless, non-custodial.
• lib/erc8004.js — interop with the dominant agent-reputation standard (ERC-8004): turns a ReputationRegistry.getSummary result into a SEPARATE, advisory, re-verifiable lens on till_trust. Feedback is client-submitted (sybil-farmable), so it never enters the payable decision — it informs, keeps the sybil caveat unless filtered to trusted clients, and always points to re-verify getSummary on Base.
• Decentralization is checkable, not claimed — the known-bad floor carries a content fingerprint (floorFingerprint / till_floor): two nodes with the same fingerprint judge on the same objective floor, re-derivable from named public MIT lists, so convergence is on public data + a deterministic hash, never on a central operator. The classifier is replicated (pure trust-core), the floor converges on public data, and relative reputation stays deliberately local — divergence, where it exists, is always fail-closed (a node with less data is more cautious, never more permissive).
• lib/identity.js — the agent glue: npub AND/OR did:key ↔ Base, trustless. Resolves a buzz/Nostr identity (secp256k1 npub) or a gitlawb identity (Ed25519 did:key) — or both — to a payable, trust-assessable Base address via a bidirectional attestation (each identity key present signs, and the Base key signs, the same canonical message; anyone re-verifies). Fail-closed: unverified / an identity key missing its signature / no identity key / expired ⇒ a claim, not a binding. Resolving is not trusting — you still run the triangle on the address.
• lib/skyfire.js — interop with Skyfire (Experian's agent-identity layer): (1) a KYA JWT lens — who backs an agent (advisory, aud anti-replay, weak posture surfaced: a no-exp or non-audience-bound token is flagged, strict callers refuse with requireExpiry); (2) authorizeCharge — the Programmable Payment: a charge only becomes an executable EIP-681 intent if it's inside what the agent's OWNER signed off — token, recipient allow-list, per-charge max, AND the cumulative cap (drain-safe: ten small charges can't beat a low cap; a malformed or absent limit is REFUSED, never treated as "no limit"). Both fail-closed; BIII does not verify JWT signatures itself (delegated, no dep).
• bin/biii-mcp.js — the agentic bridge: an MCP any agent loads (29 tools, counted from the exported TOOLS list — not from a regex over the source, which silently dropped till_b20_authentic because its name carries digits: till_authorize, till_b20_authentic, till_check_invoice, till_check_payment, till_create_charge,