The Subtraction: Why We Deleted 91,256 ERC-8004 Rows on Purpose

Almost nobody publishes a subtraction

Additions are easy to publish. "We added a chain, we added a source, we added a data field" is the shape of a standard product announcement. Deleting the largest single component of an index is much less common, because the number on the tin gets smaller and everyone in this market has been trained to reward the number on the tin. So a subtraction is worth explaining line by line, or it looks like a mistake.

Here are the deletions, from the shipped commit series fdf798c → 8f82ed5 on 2026-07-27 and 2026-07-28:

• Scanners. A single SCAN_ENABLED_CHAINS = {base, ethereum} gate was added and every discovery, reputation-index, activity-tracker, and re-enrich loop was routed through it. BNB stops accruing new data on the next timer fire. (Task 0213, commit fdf798c.)
• Cards + copy. Discovery cards, metadata.json, .well-known/agent.json, per-service payment_options, capability tags, and pricing lines were all cleaned of bnb / chain_id 56 references. (Task 0214, commit f2ef3be.)
• Payment code. The x402 chain-config table lost its bnb entry; the ERC-8183 chain-to-contract mapping lost 56. BNB stops being an accepted payment chain. (Task 0216, commit 2327781.)
• Served surface. Every /agents/bnb/<id> per-agent page was pulled from the sitemap; the /chains/bnb hub 301-redirects to /compare; the compare page lost its BNB column. Sitemap URL count moved from 19,652 to 13,775 — the 10,836-URL delta was every /agents/bnb/… we had ever emitted, plus 2,915 fresh Base + Ethereum agent pages picked up in the same rebuild. (Task 0215, deploy 06ecb7e1.)
• Data rows. A one-shot purge under a writer-lock, with byte-copy backup and Base/Ethereum-unchanged assertions, dropped every BNB row from the JSON profile store and SQLite tables. JSON went 911 MB → 404 MB (113,114 → 21,553 keys); SQLite went 501 MB → 237 MB post-VACUUM. /v1/public/stats at that instant returned agents_indexed: 21,559 (Base 19,609 + Ethereum 1,950). (Task 0220, commit 9c1109f.)
• Portal + funnel. The paid subscriber portal lost its BNB dropdown; funnel-event validators lost their anon_chain_brief_view:bnb suffix. (Task 0221, commit 8f82ed5.)

Two days, six commits, one deletion of 91,256 rows.

The arithmetic behind it: BNB's own numbers

The removal is easy to defend at the row level. On the 2026-07-28 decision-brief snapshot the day of the deletion, BNB carried 91,256 total registrations, of which 456 were live (endpoint returned 2xx and declared at least one machine-readable surface). The same predicate applied to Base returned 2,011 live agents out of 19,589 registered; on Ethereum mainnet, 1,355 out of 1,949. So BNB's live-rate was roughly one in every two hundred registrations, against roughly one in nine on Base and roughly two in three on Ethereum. And even that BNB number was noisy — earlier snapshots put BNB "live" at 108, then 338, then 236, then 456 across a two-week span, because BNB endpoints frequently answer once and then disappear. (All figures from the 2026-07-28 chain-quality doc.)

The commerce-backed count on BNB was zero. Zero on the day the indexer was set up, zero at every intermediate snapshot, zero the day of the deletion. The commerce-backed predicate is the strict one — a ReputationRegistry feedback row whose transaction context resolves back to a real, paid ERC-8183 or hosted-ACP job outcome. Farm-wallets can produce a feedback row for free; they can't produce a commerce-backed one without first paying the agent, at which point they've stopped being a farm. Across six months of BNB scanning we surfaced zero commerce-backed rows.

Under those two numbers sits a familiar shape. On the 2026-07-16 audit, a single BNB owner (0xEBf9…C11, mint contract PurrfectClawNFT) held 13,354 registrations — 18.2 % of the BNB set by itself. That cluster scored zero on endpoint capability, zero on 2xx response, and zero on USDC lifetime ≥ $10. Nothing subtle: hard zeros on every filter. The removal did not lose signal we were carrying; it stopped us pretending we were carrying signal we weren't.

The reason it generalises: the registry-null pattern is not a BNB problem

If the story ended at "BNB was worse," the piece would be a chain-quality post — and there are already good ones on the internet. What made the subtraction feel like a permanent bet, not a housekeeping call, was measuring the same registry surface across chains that are not BNB.

On 2026-09-15 we sampled 577 agents from the public 8004scan.io registry index across the five mainnet chains it covers (Ethereum, Base, BNB, Optimism, Arbitrum), using cursor-forged created_at anchors so the sample spanned from the oldest indexed agent to the newest — 2026-01-29 to 2026-09-15, a 229-day span, five uniformly-spaced anchors per chain. The full sample method and per-request URLs are in the endpoint-gap dataset (CSV + JSON + JSON-LD, CC BY 4.0).

Two of the five endpoint fields the 8004scan index exposes per agent — capabilities and agent_url — were null on 577 / 577 records (100 %) in the 8004scan snapshot. Hard zeros in the index. When we source-verified 43 rows against the URL 8004scan itself had recorded (2026-09-16), 4 of the 18 resolvable live cards carried a non-empty capabilities field — so the 100 % figure is exact for the index snapshot, and not exact for what the underlying agents publish. The mechanism is the explorer's parse cadence (mint plus a single 2026-06-06 bulk pass, nothing since), not the agents themselves. Across the other three endpoint fields (services, a2a_endpoint, mcp_server), 43.85 % of the sample carried nothing URL-shaped as captured by the index — a buyer-agent reading only the index has nothing to call. The endpoint-less rate splits by chain like this (index-side): Ethereum 29.60 %, Base 48.80 %, BNB 73.60 %, Optimism 29.87 %, Arbitrum 32.00 %. Every chain has the pattern. BNB just had the worst ratio, and by enough that it obscured the fact that the ratio is bad everywhere.

The measurement is index-shaped: an ERC-8004 buyer-agent doing discovery via 8004scan sees these nulls whether or not the underlying agent publishes the field. The writing companion (retitled to lead with the explorer-staleness finding) carries the full result and the four falsifying live cards. It is the companion to this one.

The point of putting the endpoint-gap finding here is not to catalogue the problem but to reset the frame. The subtraction we ran on BNB was a specific chain-level decision. The reason the same subtraction won't be needed twice on the chains we kept is not because Base and Ethereum are pristine — they're not, the same fields are null there too — it's because we filter every buyer-facing surface through liveness and commerce-backed reputation. The registry-layer null pattern is real. Our answer to it is a filter, not a chain switch.

What "all-Ethereum" means today, and what it doesn't

Two chains are actually indexed today: Base and Ethereum mainnet. Both are Ethereum-aligned in the strict sense — Ethereum L1, and one canonical Ethereum L2 that shares the same 0x8004… cross-chain registry deployments the ERC-8004 spec uses. The narrative is clean, the pipeline is one fewer chain-specific branch, and the API endpoints (/v1/intel/agent, /v1/intel/peers, /v1/intel/market, /v1/intel/delta, /v1/intel/graph, /v1/audit) all operate on a filter that was designed for exactly this composition.

The next chain we plan to add is Arbitrum One. The 2026-07 audit confirmed via a bounded public-RPC probe that the standard IdentityRegistry (0x8004A169…) and ReputationRegistry (0x8004BAa1…) are both already deployed on Arbitrum, and Arbitrum's developer culture is Ethereum-native — the kind of DeFi, perp-vault, and automation teams that publish real agents rather than farm wallets. Adding it needs its own Alchemy app for the RPC key.

We haven't done that yet. Arbitrum is not currently indexed on this site. The header for the site correctly reads Base + Ethereum. When Arbitrum lands, we'll say so, and we'll publish the same registered-vs-live table for it that the other two chains carry today. Until then, the honest count is two.

Why we published this at all

Because it is unusual to publish a subtraction, and because we would rather be judged on the removal than on the size of the number left over. Every downstream page — the /commerce-backed-agents cohort, the per-agent pages, the paid API responses — draws its signal from the index we kept, not the one we deleted. Making the deletion visible is part of what earns the trust the filtered surface is trying to build.

The subtraction has already shipped. The bet is that a smaller, defensible index will out-signal a bigger, unfiltered one over the long arc. If the reader disagrees, the raw numbers above are checkable at source — the endpoint-gap dataset publishes the 8004scan snapshot with its N=577 CSV, the JSON audit trail, and the JSON-LD schema.org Dataset block. If the reader agrees, the API is at /services and the got-paid cohort is at /commerce-backed-agents.

Companion long-form on the same removal is Report 04 (State-of series, 2026-07-30), which leads with the commerce-backed frame; this editorial leads with the arithmetic of the subtraction itself.