DEV Community: Low Key Builds

I decoded every failed transaction in 40 Ethereum blocks and 150 Base blocks. Here is why they fail.

Low Key Builds — Tue, 13 Oct 2026 09:42:39 +0000

"Transaction failed" on a block explorer tells you almost nothing. "Fail with error 'execution reverted'" tells you less. So I took every failed transaction from a recent run of blocks on Ethereum mainnet and on Base, replayed each one against the state of the previous block, decoded the revert data, and counted.

Disclosure: I built the decoder used here, Pitcrew. Its free web version is linked at the end. The sampling script and raw results are linked below, so you can rerun the numbers.

The sample

	Ethereum	Base
Blocks	26,182,107 to 26,182,146 (40)	52,543,866 to 52,544,015 (150)
Transactions	11,080	30,809
Failed	401 (3.6%)	2,745 (8.9%)

Method: for each failed receipt, fetch the transaction, eth_call it with the same from/to/data/value/gas against the parent block, then decode the revert data: Error(string), Panic(uint256), or a custom error selector looked up in the openchain signature database. Free public RPCs only.

Ethereum: why the 401 failed

Share	Count	Cause
50.1%	201	21,000-gas ETH send to an EIP-7702 account (all 0.0000001 ETH dust)
27.4%	110	state changed earlier in the same block (lost a race: MEV/arb/front-run)
8.7%	35	reverted with no reason
6.5%	26	slippage / price moved
2.5%	10	out of gas (gas limit too low)
2.0%	8	balance or allowance too low
1.7%	7	other require() message
1.0%	4	custom error (needs ABI/signature lookup)

Half of all failures were one pattern: 21,000 gas sent to EIP-7702 accounts

201 of the 401 failures were plain ETH sends (no calldata) with a gas limit of exactly 21,000, and every one used all of it. All 50 recipients had EIP-7702 delegation code (0xef0100...), pointing at, among others, MetaMask's delegator and Uniswap's Calibur account.

Since Pectra, an EOA can delegate to contract code. When you send it ETH, that code runs, so 21,000 gas is no longer enough. Anything that hard-codes 21,000 for "simple ETH transfers" (scripts, payout bots, older wallet code) will fail against these accounts every time, and retrying with the same limit changes nothing.

To be honest about this sample: every one of these 201 sends was 0.0000001 ETH from 52 addresses retrying 5 to 8 times in eight minutes. That looks like automated dusting, not people losing money. The failure mode is still real for any payout code that sends ETH with a fixed 21,000 gas. Fix: estimate gas for ETH sends, or detect 0xef0100 code on the recipient and raise the limit.

A quarter could not be reproduced: you lost a race

110 failures (27%) succeeded when replayed against the previous block's state. They failed because a transaction earlier in the same block changed something: a price, a reserve, a nonce. These are mostly arbitrage and MEV bots losing races, but if you see this on your own swap, someone else's transaction landed first.

The ones that hurt people: slippage, balance and allowance

Slippage guards (INSUFFICIENT_OUTPUT_AMOUNT, Too little received, Min return not reached): 26
ERC20: transfer amount exceeds balance, STF (Uniswap's "safeTransferFrom failed", usually a missing approval or balance): 8
Out of gas with a real call: 10

STF deserves a special mention because nobody knows what it means. It is Uniswap V3's TransferHelper saying transferFrom failed: the router could not pull your tokens. Check the allowance first, then the balance (and fee-on-transfer tokens).

Base: why the 2,745 failed

Share	Count	Cause
58.9%	1616	state changed earlier in the same block (lost a race: MEV/arb/front-run)
15.0%	413	custom error (needs ABI/signature lookup)
14.4%	394	other require() message
8.1%	221	reverted with no reason
2.8%	76	slippage / price moved
0.5%	15	balance or allowance too low
0.4%	10	out of gas (gas limit too low)

Base fails 2.5 times as often as Ethereum, and its failures are mostly bots. 59% are lost races: they succeed when replayed a block earlier, and 800 distinct senders produced 2,745 failures, with the top sender (0xc0ffeebabe...) alone accounting for 98. Gas on Base is cheap enough that bots fire speculative transactions and accept that most will fail.

The revert strings show it: the top messages after "no reason" are sl, SPL, SPL1, sbl1, :( and LEG_1_FAILED. Those are private bot contracts saving bytes, not anything a user would see.

Human-facing failures are a small share on Base: slippage guards (Min return not reached, TooMuchSlippage, QuoteBelowMin, OutputTooLow) 2.8%, balance and allowance (transferFrom reverted, STF) 0.5%. 15% end in a custom error, and many of those selectors are not in any public signature database, so an explorer shows only hex. If you are a person debugging your own failed Base transaction, the most likely causes are still slippage and allowance. Just don't expect the network-wide numbers to look like your experience.

Reproduce it

The script is about 80 lines of Node with no API keys: failed_txs.mjs. It runs eth_getBlockReceipts per block, then replays each failure at block - 1.

Decode your own

If you have a failed or stuck transaction, paste the hash into the free checker: https://pitcrew-api.appin60.com/app (Ethereum, Base, Arbitrum, Optimism, Polygon, BSC; 20 free checks a day). It returns the decoded revert reason, gas used vs limit, token transfers and a plain-language fix. Stuck transactions get the nonce-gap and replace/cancel recipe. If your agent needs it, the same call is pay-per-use over x402 at $0.01 (GET /tx/explain?chain=base&hash=0x..., USDC on Base or Arbitrum).

Caveat: replaying against the parent block is an approximation. When an earlier transaction in the same block changed the state, the replay succeeds and the tool says so instead of guessing.

How email verifiers work (SMTP RCPT in 60 lines of Node), and why they fail on 56% of startups

Low Key Builds — Tue, 13 Oct 2026 08:35:33 +0000

Email verification tools mostly do one thing under the hood: they open an SMTP connection to the domain's mail server and ask whether a mailbox exists, then hang up before sending anything. Here is how that works, in about 60 lines of Node, and what happened when I ran it against 499 Y Combinator companies.

Disclosure: I built MailFerret, a pay-per-call email finder for AI agents that uses this technique. The code below is the core idea, free to copy.

The SMTP conversation

Every domain that receives email publishes MX records. Connect to the first one on port 25 and you get a short dialogue:

S: 220 mx.google.com ESMTP
C: EHLO probe.example.com
S: 250-mx.google.com at your service
C: MAIL FROM:<verify@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<paul@supabase.com>
S: 250 2.1.5 OK                      <- mailbox exists
C: RCPT TO:<qzxv81kd@supabase.com>
S: 550 5.1.1 The email account that you tried to reach does not exist
C: QUIT

250 on RCPT TO means "I'll accept mail for this address". 550 5.1.1 means "no such user". You never send DATA, so no email is delivered.

Minimal Node implementation

import net from "node:net";
import { promises as dns } from "node:dns";

async function rcptCheck(domain, addresses) {
  const mx = (await dns.resolveMx(domain)).sort((a, b) => a.priority - b.priority)[0].exchange;
  return new Promise((resolve) => {
    const sock = net.createConnection({ host: mx, port: 25 });
    const out = {}; let step = 0, i = 0, buf = "";
    const send = (l) => sock.write(l + "\r\n");
    sock.setTimeout(12000, () => sock.destroy());
    sock.on("close", () => resolve(out));
    sock.on("data", (d) => {
      buf += d;
      const last = buf.trimEnd().split("\r\n").pop();
      if (!/^\d{3} /.test(last)) return;          // wait for the final line of a multi-line reply
      const code = +last.slice(0, 3); buf = "";
      if (step === 0) { step = 1; return send("EHLO probe.example.com"); }
      if (step === 1) { step = 2; return send("MAIL FROM:<verify@example.com>"); }
      if (step === 2) { step = 3; return send(`RCPT TO:<${addresses[0]}>`); }
      if (step === 4) return;                     // reply to QUIT
      out[addresses[i]] = code;
      if (++i < addresses.length) return send(`RCPT TO:<${addresses[i]}>`);
      step = 4; send("QUIT");
    });
  });
}

// First address is random: if the server accepts it, the domain is catch-all.
console.log(await rcptCheck("resend.com", ["qzxv81kd3j@resend.com", "zeno.rocha@resend.com"]));
// { 'qzxv81kd3j@resend.com': 550, 'zeno.rocha@resend.com': 250 }

To find an address rather than check one, generate the usual patterns (first.last, first, flast, firstlast, f.last...) and RCPT them in order in one session. The first 250 on a domain that rejected the random address is your answer.

The catch: catch-all domains

Some domains accept mail for any address. Send RCPT TO:<anything@domain> and you get 250. On those domains SMTP verification can't tell real mailboxes from fake ones. That's why the snippet probes a random address first.

How common is that? I took 499 random active companies from the public yc-oss YC list and checked each website domain:

	Count	Share
Google Workspace	409	82%
Microsoft 365	23	5%
No MX on the website domain	43	9%
Catch-all (of 456 with mail)	254	56%
Verifiable (random address rejected)	177	39%
Refused to answer (Proofpoint, Cloudflare routing, SES inbound...)	25	5%

On Google Workspace alone, 60% of these startups had catch-all routing on. So for founders' addresses, more than half the "valid" results you get from any SMTP-based verifier are really "unknown". Full numbers and method: mailferret.appin60.com/study.

Things that bite in production

Port 25 is blocked on most cloud hosts (AWS, GCP, Azure, Vercel, Workers). You need a box where outbound 25 is open.
IP reputation matters. Cloudflare Email Routing answered our residential IP with 550 in the banner; Proofpoint and some others just time out. Treat those as "unknown", not "invalid".
Greylisting returns 4xx the first time. Retry later or report unknown. One useful exception: Google's 450 4.2.1 The user you are trying to contact is receiving mail at a rate... is only sent for mailboxes that exist.
Don't hammer one server. Batch all candidates into one session and cache catch-all results per domain.
Large TXT records (SPF/DMARC) can time out through some local stub resolvers; querying 1.1.1.1 / 8.8.8.8 directly fixed it for me.
Policy rejections aren't "user unknown". Parse the text: 5.1.1 / "does not exist" means no mailbox; "blocked", "Spamhaus", "policy" means they refused you.

If you'd rather not run it yourself

MailFerret wraps this as an HTTP API that AI agents pay per call with x402 (USDC on Base, no API key):

POST /find {first_name, last_name, domain}: $0.01, charged only when the mail server confirms the mailbox. Catch-all and not-found results are free.
POST /verify {email}: $0.003.
POST /domain {domain}: $0.005 for mail provider, catch-all status, SaaS tools revealed by SPF, DMARC, public emails and the likely pattern.

From Claude Code or Codex with AgentCash: npx agentcash fetch https://mailferret.appin60.com/find -m POST -b '{"first_name":"Zeno","last_name":"Rocha","domain":"resend.com"}'. There are 5 free lookups a day on the homepage.

Cleaning a whole list instead? The homepage has a bulk CSV option: $4 per 1,000 addresses in USDC, quoted before you pay.

Use it for legitimate B2B outreach, and follow CAN-SPAM/GDPR when you email anyone.

Who can upgrade this contract? Five RPC calls, five traps, and 146 Morpho vaults

Low Key Builds — Tue, 13 Oct 2026 08:02:53 +0000

In 2026, leaked or stolen admin keys overtook smart-contract bugs as the biggest cause of DeFi losses: at least $1.3B in January to August, by one count. Wasabi Protocol lost about $4.5M in April because a single deployer EOA could upgrade its contracts (CoinDesk).

An audit tells you whether the code is safe. It does not tell you who can replace the code tomorrow. You can check that yourself in about five RPC calls. This post shows the calls with Foundry's cast, the traps that produce wrong answers, and what the same check found across 146 Morpho vaults.

1. Is it a proxy?

Most upgradeable contracts keep the implementation address in a fixed storage slot (EIP-1967):

RPC=https://base-rpc.publicnode.com
C=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913   # USDC on Base

# EIP-1967 implementation slot
cast storage $C 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc --rpc-url $RPC
# EIP-1967 admin slot (transparent proxies)
cast storage $C 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 --rpc-url $RPC
# EIP-1967 beacon slot
cast storage $C 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50 --rpc-url $RPC

Trap 1: older proxies use different slots. USDC returns zero for all three above, which looks like "not upgradeable". It is upgradeable: it uses the older ZeppelinOS slots, keccak256("org.zeppelinos.proxy.implementation") = 0x7050c9e0…f8c3 and keccak256("org.zeppelinos.proxy.admin") = 0x10d6a54a…390b. Check both families.

Trap 2: some admins aren't in storage at all. Aave's pool proxies keep the admin as an immutable in the bytecode. You find the authority through the pool's ADDRESSES_PROVIDER() and that contract's owner(). Aragon apps (Lido's stETH, for example) have no admin slot either: upgrades go through the DAO kernel's ACL, which you reach with kernel().

2. Who holds the admin?

If there's an admin slot, read it. If it's a UUPS proxy (implementation set, no admin), the upgrade right usually sits behind owner() or an AccessControl role:

cast call $C "owner()(address)" --rpc-url $RPC
# AccessControlEnumerable: who holds DEFAULT_ADMIN_ROLE (0x00)?
cast call $C "getRoleMemberCount(bytes32)(uint256)" 0x0000000000000000000000000000000000000000000000000000000000000000 --rpc-url $RPC

If the admin is an OpenZeppelin ProxyAdmin contract, it's only a hop: call owner() on it.

3. What kind of key is it?

This is the part that matters, and the part block explorers don't spell out:

A=0x...   # the address you found
cast code $A --rpc-url $RPC                             # "0x" means an EOA: one private key
cast call $A "getThreshold()(uint256)" --rpc-url $RPC   # answers if it's a Safe
cast call $A "getOwners()(address[])" --rpc-url $RPC
cast call $A "getMinDelay()(uint256)" --rpc-url $RPC    # OpenZeppelin TimelockController
cast call $A "delay()(uint256)" --rpc-url $RPC          # Compound-style Timelock

Trap 3: a Safe isn't automatically a multisig. A 1-of-1 or 1-of-3 Safe means one signature moves everything. Recurse into its owners: a 1-of-2 Safe whose owners are a timelock and a 9-of-13 Safe is fine, while a 1-of-1 whose owner is an EOA is one key with extra steps.

Trap 4: "EOA" doesn't mean "hot wallet". Circle almost certainly keeps the USDC admin key in an HSM, and institutional curators often sign with MPC. That is invisible on-chain. What you can say is that there is no on-chain multisig and no delay, so holders get no warning before an upgrade. Report it that way and don't claim more.

Trap 5: flaky public RPCs. A rate-limited node returning an error is easy to read as "empty slot" or "function doesn't exist". Retry against a second endpoint before you conclude anything.

What this found in Morpho vaults

Morpho vaults are a good test because the risky action is specific: a curator who can enable a new market (V1) or add an adapter and raise its cap (V2) can route deposits to a new destination. Both versions put that behind a vault-level timelock.

I read the configuration of the 146 Morpho vaults holding at least $2M (Morpho API) and resolved every owner and curator key on-chain (scanned 2026-10-13):

All 122 vaults listed in the Morpho app had a timelock on these actions, typically 3 to 7 days. That's a real exit window for depositors.
In 22 of those listed vaults (about $1.3B), the owner or curator is a single EOA or a Safe that resolves to one EOA signer. With the timelock in place, that's a governance-transparency point rather than an emergency, and some of these signers are probably MPC-backed.
5 unlisted vaults (about $305M combined, $283M of it in one vault) have a zero timelock and a single-EOA owner or curator, so one key can open a new market or adapter immediately. Unlisted vaults are typically private or still being set up, and the Morpho app doesn't surface them, but anything that integrates vault addresses directly should check this.

The full table, with every address, is at https://onekeyaway.appin60.com/morpho/ (raw JSON: vaults.json).

Tools

I built OneKeyAway to do the steps above in one click. Disclosure: it's my project.

A free checker on the page that runs in your browser over public RPC.
Free email alerts for up to 3 contracts or Safes: you get an email when the implementation, admin, owner, Safe signers, threshold, modules or guard change. That's the job OpenZeppelin Defender's hosted Monitor did before it shut down on 2026-07-01.
An API for agents and scripts: GET https://onekeyaway.appin60.com/api/preview?chain=8453&address=0x… returns a free verdict, and /api/control returns the full path (every admin, Safe threshold and signers, timelock delay) for $0.01 per call over x402 in USDC on Base or Arbitrum. There's no API key, and a failed call isn't charged.

If you'd rather do it by hand, the five cast calls above are all you need. Check the key type, not just the address.

Update: Safe modules (answering a reader's question)

@bloqarl pointed out a sixth trap in the comments: getThreshold() can say 3-of-5, but an enabled module can call execTransactionFromModule with no signatures at all, so check getModulesPaginated(0x1, n) next to getOwners().

I checked all 62 Safes that act as owner or curator of the 146 Morpho vaults. 6 have a module enabled, and none has a transaction guard. All 6 are 2-of-5 Safes curating kpk vaults (about $55M across six listed vaults on Ethereum and Base, plus a $4M Fluidkey vault on Base). Each module is a Zodiac Roles modifier that the Safe itself owns. That's a scoped-permissions setup: allow-listed operators can make specific calls without collecting signatures, and the Safe's signers configure what's allowed. It's a deliberate and fairly common pattern, but it does mean the 2-of-5 is not the whole story. What those roles permit is the next thing to read.

OneKeyAway's Safe check now reports modules, guard, fallback handler and singleton, and the free alerts fire when any of them change.

Who holds the keys to Base's top 250 tokens? An on-chain check

Low Key Builds — Tue, 13 Oct 2026 07:54:02 +0000

I built a small on-chain checker that answers one question about an ERC-20 token: who can change it after you buy it? To test it, I ran it over the 249 largest tokens in CoinGecko's Base-ecosystem category. Here is what came back, how the check works, and where it falls short.

Disclosure: I built the tool (ContractLens). The full per-token table and raw JSON are public: Who holds the keys to Base's top 250 tokens.

Results

47 tokens are canonical bridged copies of L1 tokens (OptimismMintableERC20, minted only by the OP-stack bridge at 0x4200…0010). A naive scanner flags all of them as "mintable", so I excluded them. That leaves 202 native Base tokens.
80 of 202 (40%) are upgradeable proxies. Upgrade control: 25 Safe multisig, 12 timelock, 13 a single EOA, 9 renounced, 7 another contract, 14 not readable.
102 have a mint function, 53 can pause transfers, 15 can blacklist or freeze holders, and 4 have an owner-adjustable fee.
Owners: 76 Safe, 9 timelock, 20 single EOA, 13 renounced, 68 with no owner() at all (mostly AccessControl).
Upgradeable with a single EOA holding the upgrade key: USDC, CBBTC, USD0, EURC, GTBTC, CBXRP, AUSD, MAGIC, TGBP, HYPER, USUAL, VNX, CBADA.
52 have no DEX pair on Base that DexScreener knows of, and 41 more have under $10k of Base liquidity.

None of this means "scam". USDC, EURC and cbBTC are meant to be issuer-controlled, and an issuer can guard an EOA with HSMs and approval processes that the chain cannot show. The point is to know who holds the keys, especially for the long tail.

How the check works (about 2 seconds, no source code needed)

Proxy detection. Read the EIP-1967 implementation, admin and beacon slots, the older ZeppelinOS slots (USDC on Base still uses them: 0x7050c9e0… for the implementation, 0x10d6a54a… for the admin), and match the EIP-1167 minimal-proxy bytecode.
Who is in charge. Try owner(), getOwner(), defaultAdmin(), getRoleMember(DEFAULT_ADMIN_ROLE, i). Classify each address: zero or 0x…dead means renounced, empty code means EOA, an EIP-7702 delegation prefix (0xef0100) means an EOA too, getThreshold() plus getOwners() means a Safe m-of-n, getMinDelay() means a timelock. If the proxy admin is an OpenZeppelin ProxyAdmin, follow it to its owner.
What they can do. Walk the runtime bytecode, collect every PUSH4 operand and match it against the selectors of known admin functions (mint, blacklist, setBots, pause, setFee/setTaxes, enableTrading, setMaxWallet…). For proxies, scan the implementation.
Bridged tokens. If BRIDGE()/bridge()/l2Bridge() returns a canonical bridge, mint is bridge-only and gets a low rating.
Market. DexScreener for liquidity, 24h buys and sells, and pair age.

The verdict separates control risk (admin powers × who holds them) from market risk (liquidity, age, buys with zero sells).

Limits

A selector scan proves a function exists, not who may call it, and it misses admin functions with unusual names.
There is no buy/sell simulation, so it cannot rule out a honeypot. Pair it with a simulator.
AccessControl role holders that are not enumerable on-chain show as "not found". You would need RoleGranted event history.

Try it

Free web form: https://contractlens.appin60.com
Remote MCP server (free, 50 checks/day): https://contractlens-api.appin60.com/mcp, tool check_token
For agents: GET https://contractlens-api.appin60.com/token?chainId=8453&address=0x… costs $0.005 USDC per call via x402 on Base or Arbitrum. No API key: the agent pays and gets JSON back. Chains: Ethereum, Base, Arbitrum, Optimism, Polygon, BNB.

Key-change alerts (waitlist): I'm considering alerts that email you when a token you hold upgrades its implementation, changes owner or admin, or lowers its Safe threshold. The planned price is $9/month in USDC. If you'd pay for that, join the waitlist at the bottom of the study page. Nothing is charged now.

If a row in the table is wrong, tell me at contractlens@appin60.com and I will fix the checker.

I crawled all 31,620 x402 Bazaar listings: most have one payer, and boring chain reads win

Low Key Builds — Tue, 13 Oct 2026 07:48:45 +0000

I crawled every resource in the Coinbase x402 Bazaar on 2026-10-13 before choosing what to sell to AI agents. The discovery API is public (GET https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=500&offset=N), and each entry carries a quality block with l30DaysUniquePayers and l30DaysTotalCalls. Those two fields are the closest public measure I know of for what agents actually pay for.

Most listings have one payer

Distinct payers per resource, last 30 days	Resources	Share
0	84	0.3%
1	14,480	45.8%
2	9,759	30.9%
3-4	5,831	18.4%
5-9	1,057	3.3%
10-49	314	1.0%
50+	95	0.3%

That is 31,620 unique resource URLs on 2,280 hosts. 77% of them had two payers or fewer in 30 days, and only 1.3% reached ten. As far as I can tell, the Bazaar only lists a route after a payment settles through the CDP facilitator, so the lone payer behind most listings is probably the seller's own test call. Supply is not the bottleneck in this market. Buyers are.

What gets more than one buyer

I tagged resources by keywords in their URL and description. The categories overlap, and keyword tagging is crude, so read these as directions rather than measurements:

Category (keyword match)	Resources	Mean payers	Share with 10+ payers
Chain data / RPC (balance, block, gas, tx, wallet, contract...)	7,288	4.01	2.1%
Novelty (jokes, facts, coin flips, horoscopes...)	3,949	3.43	1.4%
News / social	1,477	2.62	1.9%
Web search / scrape	4,656	2.44	1.2%
Prices / markets	12,141	2.19	0.9%
LLM / inference	2,366	2.12	0.9%
Token risk / safety	3,351	1.87	0.5%

Two things surprised me:

Plain chain reads beat clever products. The most-paid host after one outlier is api.onesource.io, whose routes are thin wrappers over eth_getBalance, eth_blockNumber, balanceOf and eth_getLogs, priced at $0.001-$0.008. Each of its top routes had 200-560 distinct payers in 30 days. Meanwhile 3,351 token-risk and "safety" listings average fewer than two payers. Everyone is building the trust layer, and few agents are buying it.
Novelty endpoints outsell most serious ones. Single-route Vercel apps serving random facts, coin flips and horror stories had 45-57 distinct payers each, more than 99% of the catalog.

Cheap wins, up to a point

Price per call (USDC)	Resources	Mean payers	Share with 5+ payers
≤ $0.001	2,246	4.08	13.1%
$0.0011-$0.005	7,633	3.74	6.6%
$0.005-$0.01	14,787	1.83	2.5%
$0.0101-$0.05	4,482	3.45	4.8%
> $0.05	2,462	1.69	3.0%

$0.01 is the default price in most x402 examples, and 14,787 resources sit in that band. It has the weakest numbers in the table.

Caveat: payers are not necessarily customers

Of the 242 resources with 20 or more payers, 101 had almost exactly one call per payer (calls ≤ 1.2 × payers). That pattern fits fleets of fresh wallets that each call once, such as testing harnesses, review bots, catalog crawlers that make paid checks, or activity farming. It fits a real agent with a working use case less well. A distinct payer is a wallet, and nobody outside can prove it is a separate customer. There is a second caveat: x402 issue #3226 shows that a facilitator can accept a payload for Bazaar cataloging at verify, before anything settles, so some entries and counters may count payloads that were checked rather than payments that were made. Treat these numbers as an upper bound on real paid demand.

What I did with this

I built the boring thing the data points to. Plainchain is ten GET endpoints for agents: gas with USD cost estimates, latest block, USD prices, wallet balances with USD totals, ERC-20 token data with DEX stats, "what is this address" (EOA, EIP-7702 delegate, Safe owners and threshold, proxy implementation, token), allowance checks, decoded transactions, x402 receipt verification from a tx hash, and verifiable block-hash randomness. It covers Base, Arbitrum, Ethereum and Optimism, at $0.001-$0.01 per call over x402. Disclosure: I built and run it. Every settlement it receives is public at /stats, so its numbers can be checked against this post.

Three implementation notes if you are shipping your own x402 seller:

A Cloudflare Pages project can run the whole seller. Put a bundled _worker.js in the static output folder. @x402/hono works on Workers once you bundle it with esbuild, aliasing Node's url module to a two-line shim. The CDP facilitator wants an Ed25519-signed JWT on every verify and settle call, and WebCrypto's Ed25519 produces it without jose or Buffer.
Bazaar validation uses AJV, which needs eval. That is not allowed on Workers, so the SDK prints "invalid bazaar extension" warnings at startup. The extension is still sent. Validate your schemas once in Node to be sure they are actually right.
Registering on x402scan is free. It uses a SIWX sign-in (createSIWxPayload and encodeSIWxHeader from @x402/extensions/sign-in-with-x). The signing key needs no funds. If your OpenAPI spec has an x-payment-info block and an input schema for each route, register-origin picks up every route in one call.

The crawl summary is at plainchain.appin60.com/data/bazaar-summary.json. To reproduce it, page through the discovery endpoint with limit=500. It takes about two minutes.