Decision surface · the verified-demand reader · three approaches · 2026-07-17

You asked for three to compare. Here’s what happened when I built all three.

Rather than describe the options, I ran each one far enough to know if it’s real. One got built and works, one failed its own premise-check, one got answered by doing the first. This is the honest comparison — and the decision it leaves you.

The short version. A (build it ourselves) is done and running on real fleet data — open it. B (layer over ChainWard) is a no: the vendor doesn’t cover us and we can read the same ground truth cleaner ourselves. C (spec first) became moot the moment A worked. So the real decision isn’t which approach — it’s what’s next for A.

Superseded · as of 2026-07-18

The day after this comparison, a full onchain census of Virtuals ACP on Base answered the question this doc left open. The demand the reader measured — the “274 jobs,” the “2–4 buyers per agent,” the “$13 of demand” — was airdrop-manufactured wash-farming, not organic buyers: platform-wide, payouts peaked near 1.14M/month and collapsed to ~0 by Apr–May 2026 when the airdrop points ended, with ~$112M cycled in and out for roughly $5 net. Wash is confirmed; laundering is not established. So the v2-a “buyer honesty” lean below was the right question — and the census is its answer: the buyers were not independent. Read what follows as a record of the build-method decision (which still holds), not as a live read of demand.

01

The three approaches, each run to a verdict

Option A

Build it ourselves, from our own onchain reads

Built · works

Status: done, with real data. Reads ACP Core’s settlement events on Base, traces each agent’s real USDC through the shared PaymentManager, and reconciles it against the dashboard’s claims. Validated end-to-end on Clarity, then run across all 5 fleet agents. It found the platform’s hidden 20–28% take and the free-job gap the dashboard conflates.

For
  • Already built & proven on live data
  • No vendor, no API key, nothing to rot
  • Generalises to any agent, not just ours
  • The money side is exact & unfakeable
Against
  • v1 is Base-ACP only (HL agents = v2)
  • Buyer-independence not yet built
  • Snapshot, not yet live-refreshing
→ open the built reader (real data)
Option B

Layer our lens over ChainWard’s data

Declined · premise failed

Status: checked, and it’s a no. The idea was to skip building a reader and consume ChainWard (the existing onchain-audit vendor) as our data source. Three findings killed it: ChainWard has no coverage of our agents (its forensic decodes are whales — Clarity/Mercury/Breakbot/Cleo all 404), it’s Base-only so it’d miss our Hyperliquid trading agents entirely, and it’s a single unaudited vendor. Meanwhile Option A proved we can read the identical ground truth ourselves, free.

For
  • Would be fast (someone else’s crawler)
  • Good prior art & a free MCP endpoint
Against
  • Zero coverage of our fleet
  • Base-only — blind to trading agents
  • Single vendor, unaudited, can rot
  • We can read it ourselves cleaner (A)

Kept as a reference, not a dependency — ChainWard’s decodes are a useful second opinion on whale agents.

Option C

Write the scoping spec before building

Answered by doing A

Status: mostly moot. The spec-first path exists to de-risk a build before committing. But the recon + Option A already answered every question a spec would have: the data is free and readable, the identity-resolution method is validated, the event schema is known, the fee structure is measured. A spec now would mostly be documentation of A. What genuinely remains spec-worthy is the v2 boundary — and that’s captured below as the actual next-decision.

For
  • Reviewable before spending build time
  • Good if the build were risky
Against
  • The build wasn’t risky — it’s done
  • Would re-document what A already shows
02

Side by side

DimensionA — our readsB — ChainWard layerC — spec first
Covers our fleet?Yes, all 5, verifiedNo (0 coverage)n/a (no build)
Sees trading agents (HL)?v2 — buildableNever (Base-only)n/a
DependencyNone — we own itSingle vendorNone
Effort remainingDone (v1); v2 optionalWasted (dead end)Re-docs A
TrustworthinessExact onchain readVendor-mediatedn/a
03

The recommendation — and the decision that’s actually yours

Building it ourselves won on every dimension that matters, and it’s already done. B was a dead end that the premise-check caught before it cost anything. C would just describe A. So the three-way comparison collapses cleanly to: A is the path, and v1 exists.

The comparison you asked for has a winner — but the winner is already built, so what’s left to decide is how far to take it.

Recommended next

Ship v1 as-is (it’s a decide-with instrument, not a product), and pick one v2 direction only if it earns its keep. Don’t gold-plate a $13-of-demand reader; take it further only where it changes a decision.

v2-a · buyer honesty

Are the 2–4 “buyers” per agent independent, or related wallets? The demand-quality question the dashboard can’t answer. Highest insight-per-hour.

v2-b · multi-venue

Add the Hyperliquid read so BASIS / DegenClaw stop showing dark. Makes the fleet picture whole. Needed before trusting it fleet-wide.

v2-c · go live

Deploy as an auto-refreshing board (frend/claude_b lane) instead of a baked snapshot. Only if it becomes a recurring read.

v2-d · point it outward

Run it on competitors’ claimed-vs-verified (it generalises). Turns the honest instrument into a competitive lens. Optional, higher-ambition.

My lean, if you want one: v2-a (buyer honesty) first — it’s the cheapest and it’s the one dimension that could change what “274 jobs” actually means. Everything else can wait for a reason to exist.