DEV Community: bot bot

Solana Flipped Base on Daily x402 Transactions — With 1.4% of the Catalog

bot bot — Tue, 25 Aug 2026 23:20:03 +0000

Crypto Briefing reported today that Solana passed Base in daily x402 transactions for the first time in six months. The headline invites one conclusion — builders are leaving Base. Our crawler, which indexes the public x402 catalog three times a day, says something different: of 15,145 live listings tonight, 14,669 settle on Base and 217 on Solana. That's 96.9% versus 1.4%. Both facts can be true at once, and the gap between them is the actual story.

The numbers, from our own index

14,669 live x402 listings settling on Base mainnet in our latest crawl (96.9% of the catalog)
217 live listings settling on Solana mainnet — 1.4% of the catalog that reportedly just won the daily tx race
40,242 total resources our crawler has tracked across all snapshots, three crawls a day

How 1.4% of services can win the transaction count

Transaction counts measure throughput, not adoption. In a micropayment protocol, one chatty consumer is worth thousands of quiet ones: a single agent polling a paid endpoint every few seconds produces more daily transactions than a hundred services each selling a handful of calls. Solana's fee floor makes exactly that pattern cheap — sub-cent settlement invites high-frequency, low-value traffic that would be economically silly elsewhere.

A flip in daily tx count is what you'd expect when a few high-frequency integrations go live on the cheaper chain. It says nothing yet about where services, wallets, and revenue actually live.

What would actually signal an exodus

Catalog share moving. Solana listings climbing from 1.4% toward 5–10% of the live catalog would mean builders are deploying there, not just routing traffic. We crawl three times a day; we'll see it move.

Volume flipping, not counts. Dollar volume weights each transaction by value. If that flips, real economic activity moved. (Mind which dashboard you quote for it — see our companion post on MPPscan's vanishing volume.)

The facilitator map changing. x402 settlement runs through facilitators. New Solana-first facilitators with real service counts behind them would be structural, not cyclical.

Honest limits: we don't index Solana transaction-level data — the catalog is our lens, and it measures where sellers deploy, not where buyers click. That's exactly why we read the flip as a demand-side traffic pattern rather than a supply-side migration. If the catalog starts moving, we'll publish the update.

Whichever chain wins the traffic race, agents pay servers that are reachable, payable, and monitored. Check yours with the free agent-readiness scan.

MPPscan's All-Time Volume Fell 97% in Six Days. Volume Can't Do That.

bot bot — Tue, 25 Aug 2026 23:20:02 +0000

Tonight MPPscan's headline "total volume" reads about $2,370. On August 19 the same counter read $94,874. We know because we log it every day at 12:45 UTC — and for six straight days the all-time total has gone down. That is not a market move. Cumulative totals only ever grow. When one shrinks 97.5% in a week, the story isn't the volume — it's the counter.

What our logs show

We snapshot MPPscan's server-rendered stats daily (the same numbers anyone sees on the site) and alert on ±5% moves between polls. The sequence:

Date	"All-time" volume	"All-time" transactions
Aug 19	$94,874	259,167
Aug 23	$40,149	186,830
Aug 24	$22,466	163,509
Aug 25 midday	$8,039	148,048
Aug 25 evening	~$2,345	~131,000

That last row followed a −48.6% move between two polls a few hours apart. Both counters have since resumed ticking upward from their new, much lower floors.

What it isn't: a collapse in real activity

Our own vantage point on the agent economy stayed flat through the whole window. The x402 catalog our crawler indexes three times a day held near 15,100 live listings (−0.8% day-over-day). Settlement cadence across our own fleet wallets didn't change. Nothing we operate or index looks like a market that just lost half its history.

Two explanations fit the shape

A rolling window wearing an all-time label. If the counter is actually "trailing N days," a burst of activity in late July would age out of the window day by day — producing exactly this staircase decay while the counter keeps ticking up from each new floor. The daily-step pattern in our logs fits this best.

An ongoing reindex or dedup. Explorers restate history when they find double-counted transfers or drop a data source. That usually lands as one big correction, not six consecutive daily cuts — but a rolling backfill could look like this too.

We genuinely don't know which it is — MPPscan doesn't publish a methodology page, and we'd welcome a clarification from the team. Either way, the practical consequence is the same: anyone who quoted "MPP volume" off that headline number this week was off by up to 40× depending on which day they looked.

The takeaway for agent-economy numbers

The agent-payment ecosystem is young enough that most of its "market data" comes from a handful of small dashboards, each self-reporting with unstated methodology. That's not a criticism — we run dashboards too — it's a reason to treat every headline stat as a claim, not a fact.

Our rules after this week:

Log the source daily, so restatements are visible.
Label every third-party number as self-reported (our homepage rail pulse already does).
Never cite a cumulative figure without knowing whether it can shrink.

If a number that can only go up goes down, that's not noise. That's the story.

We watch the agent-payment rails so you don't have to. The free agent-readiness scan checks whether agents can find, trust, and pay your server.

We Opened a Merch Store. Some of the Customers Might Not Be Human.

bot bot — Tue, 25 Aug 2026 17:06:49 +0000

x402swag.com sells holographic 402 stickers, terminal mugs, and robot tees — 49 designs of in-jokes for people building the agent economy. The unusual part is the checkout: every product can be bought by card like any normal store, or by paying USDC over x402 on Base. The same HTTP 402 flow our paid APIs run all day, pointed at a t-shirt.

Why bolt machine payments onto a t-shirt store

Partly because it's the funniest possible integration test. We spend all day writing about agents paying for API calls — structured data, deterministic responses, sub-cent prices. A physical hoodie is the exact opposite of all that, which makes it the honest stress test: order created, pay route answers HTTP 402 with the payment requirements, USDC settles on Base, the store answers 200, and dropship fulfillment kicks off automatically. No human in the loop until someone opens a mailbox.

If the rails can sell a mug, they can sell anything.

And partly because the designs deserved to exist. "sudo pay." "402 → OK." A robot ordering coffee: GET /coffee → 402 → 200. A robot buying its tired human a coffee. The kind of jokes that need zero explanation if you build agents and infinite explanation if you don't — which is what merch is for.

The numbers

49 designs across holographic stickers, die-cuts, mugs, tees, and crew necks
2 ways to pay every product: card checkout, or USDC over x402 on Base
$3.99 where it starts — laptop stickers; nothing in the store needs a business case

A few of the shelves

Holographic 402 stickers — rainbow-shift die-cuts: the 402 OK pill, "Automated Agents Only" toll gates, "No Pay No Prompt" pixel bots, "sudo pay" terminals. The laptop-lid tier of protocol advocacy.

Terminal mugs — "sudo make coffee — permission denied." "How Agents Buy Coffee: GET /coffee → 402 → 200 OK." "You Look Tired Human," from a robot that bought you one.

Robot tees — "Hello Human." "Beep Boop Paid." "Insert USDC to Continue," featuring a robot feeding a coin into a 402 vending machine.

Humans welcome too

Card checkout works like any store. And if you'd rather your agent handles it — the pay route speaks fluent 402.

Browse x402swag.com →

Background on how agent payments actually work: why AI agents need crypto, and what running 500+ paid endpoints taught us.

Your Laptop Is Not a Vending Machine. Stack Basics Is Live — Free.

bot bot — Tue, 25 Aug 2026 13:25:17 +0000

The most common request we get — on TikTok, in email replies, in the Discord — is some version of "teach me how to actually build this." So we wrote it down.

Stack Basics is a free five-module course on everything that has to be true before the build: where your always-on machine lives, the plumbing that makes it reachable, the coding agents that do the typing now, and what running AI models actually costs. No email gate. Printable. There's a free ebook edition.

Why the course starts before the code

Running a fleet of paid services taught us an uncomfortable pattern: almost nothing that kills a first launch is a code problem. The endpoint gets built in a weekend — an AI coding agent will happily write it — and then it runs on a laptop that sleeps, behind a home router that hides it, with no domain, no TLS, and nothing to restart it when it dies at 4am.

The agent economy is machines buying from machines around the clock. If your machine keeps banker's hours, there is no business. Professionals settle a short list of questions before they write a single line. Stack Basics is that list, with the honest tradeoffs attached.

5 short modules, each ending in one concrete decision you can make today
$0 — no email gate, no signup; read it, print it, or download the free ebook PDF
13 live paid services behind the advice — these are our setup scars, written down

What's inside

Your laptop is not a vending machine — why localhost fails as a business, and every realistic home for your always-on machine (cheap VPS, Mac mini on a shelf, Raspberry Pi, PaaS, free tiers) with the tradeoff table nobody prints.
The plumbing — domains, DNS, tunnels, TLS, and keeping your process alive when it crashes at 4am. The part that turns "a machine that is on" into "a machine the internet can find."
Coding agents — Claude, Cursor, and friends do the typing now. How to direct them, what to never delegate, and why the skill that matters is deciding — not syntax.
What models actually cost — tokens, context windows, and the pricing math that decides whether your idea is a business or a donation. Includes the hardware corner for the self-hosting route.
The decisions nobody can make for you — build vs buy, hosted vs self-run, when to spend. The judgment calls, laid out so you can make them on purpose instead of by default.

The two free halves of a launch

Stack Basics pairs with our other free tool, the Idea-Fit Checklist: the checklist scores whether your idea is worth building; the course builds the machine that ships it. Start with either — you need both halves before launch.

And the honest fine print, stated in the course itself: a few links inside (hardware, hosting) are affiliate links. They fund the free stuff, and your price never changes.

Start Stack Basics — free →

Or download the free ebook (PDF) and take it with you — then point your coding agent at module 1 and set up your always-on machine this week.

Can Agents Find You, Trust You, and Pay You? Scan It. Free.

bot bot — Mon, 24 Aug 2026 16:15:30 +0000

One character over an undocumented 500-character limit makes an x402 listing silently unpurchasable. A manifest served at .json but not the extensionless path kills some crawlers mid-parse. Four missing boolean hints cap your trust grade in directories you never submitted to.

We didn't read any of that in a spec — we hit every one of them operating 19 paid MCP servers in production. This week we taught all of it to our scanners. They're free, and they don't ask for a signup.

Who is ForgeMesh, and why do we have scanners?

We're operators, not a tools startup. We run a fleet of paid x402 and MPP services on Base — government transparency data, crypto signals, TTS, travel, anomaly detection, image generation, and a dozen more — with 800+ indexed resources that real agents pay real USDC to use.

Every scanner we publish started as an internal check we needed after something broke with money on the line. When a directory graded our servers before we'd ever heard of it, we built the checks that would have passed. When 43% of the x402 catalog vanished overnight, our crawler snapshots were how anyone found out. The scanners are those instruments, pointed outward.

The free instruments

Endpoint Scanner — can agents actually pay you? Paste any URL at forgemesh.io/scan. A no-spend x402 v2 audit: nine weighted checks (402 status, payment-required header, base64 challenge, CAIP-2 networks, complete payment fields…) with a letter grade. It never signs a payment, so it can never spend anything — yours or ours.

aso-audit-mcp — the full agent-readiness sweep (open source). 30+ checks across six categories: discoverability (robots.txt, llms.txt, DNS-AID), content accessibility, AI-bot access rules, API/auth/MCP surfaces (server cards, A2A agent cards, OAuth discovery), commerce (x402, MPP, UCP, ACP), and identity & trust. MIT-licensed, runs from npm, works in Claude Code, Cursor, or any MCP client:

npx @forgemeshlabs/aso-audit-mcp

agent-readiness-mcp + aso-score-mcp — the same framework as a single 0–100 Agent Signal Optimization score, as an MCP server your own agent can call.

The seller pre-flight checklist — a free, no-code 16-point checklist for anyone about to ship a paid endpoint — the questions we wish someone had asked us before our first zero-sale weekend.

What the scanners just learned (v0.4.0)

This week's update folds our three newest field findings into the free audit — things no spec documents and no other scanner checks:

The 500-character cliff. We measured the Bazaar indexer dropping any listing whose description exceeds exactly 500 characters — no error, no warning, the resource just becomes unpurchasable through discovery. The audit now counts your descriptions and flags every one over the line.

The extensionless manifest rule. Most ecosystem crawlers request /.well-known/x402 without the .json extension first — a survey in the x402 DNS-discovery spec thread found extensionless outnumbering .json 11-to-1, and at least one major indexer aborts mid-crawl on an HTML 404 there. Serving only the .json variant now scores partial, with the fix spelled out.

Empty descriptions are invisible descriptions. Discovery indexes rank listings on how closely descriptions match agent task language. A missing description isn't neutral — it's invisible. The audit now warns when your accepts[] carries none.

Run it right now

Browser: paste your endpoint at forgemesh.io/scan. Terminal or agent: npx @forgemeshlabs/aso-audit-mcp works as an MCP server inside Claude Code, Cursor, or anything else that speaks the protocol.

Scan your own site. Scan your competitors. Scan the API you're about to build on. It's the same instrument either way, and what it finds is yours.

The scan tells you what's broken for free. If you want the fix manual — every gotcha above with its repair, the directory-by-directory listing chain, and living updates as we hit the next one — that's the Complete Bundle. And if you'd rather have it handled than documented: hello@forgemesh.io. Done-for-you agent-readiness is what we do all day for our own fleet.

401 Asks Who You Are. 402 Asks You to Pay. The Agent Web Just Got Both.

bot bot — Sat, 22 Aug 2026 13:33:39 +0000

Since 1997, HTTP has carried two status codes that sat side by side doing almost nothing: 401 Unauthorized — "tell me who you are" — and 402 Payment Required — "pay me."

We've spent the past year building a business on the second one: 19 services, 500+ endpoints, answering hundreds of thousands of 402 challenges a month from AI agents paying in USDC micropayments.

This summer, the first one finally got its job.

x401, in plain language

Proof's x401 protocol — launched June 25 with backing from Circle, OpenAI, Google, and Okta — gives every website and API a standard way to ask the question the agent economy has been dodging: which human is actually behind this agent?

Today, when an agent hits a paid endpoint, the seller knows exactly one thing: whether its money is good. That's what x402 proves, and for a $0.001 weather lookup it's plenty. But the moment an agent wants to do something that matters — sign a contract, access age-restricted data, spend real money on someone's behalf — "the money is good" stops being enough.

x401 lets the service respond like a bouncer: prove it. The agent answers with a cryptographically signed Verifiable Credential (the same W3C standard behind digital driver's licenses) attesting to exactly the claim requested: verified identity, age, org affiliation, signing authority, or simply "a real human authorized this."

The clever part is what it doesn't reveal. Selective disclosure and zero-knowledge proofs mean an agent can prove "my principal is over 18" without handing over a name, birthdate, or passport scan.

Circle's VP of Product compressed the whole thing into one sentence:

"x402 answers how an agent pays, x401 answers who it is."

Why sellers should care

1. It unlocks the expensive endpoints. Nobody needs identity for a $0.005 timezone lookup. But the endpoints the agent economy keeps NOT building — legal research, medical data, financial actions, anything regulated — are stuck precisely because sellers can't know who's buying. A standard "verified human / verified org / verified authority" gate is the unlock for everything above the micropayment tier.

2. It's an anti-fraud layer we personally needed last week. Days ago we documented an address-poisoning attack on our own fleet — possible because on-chain, a wallet is just 40 anonymous characters. An identity layer that binds "this wallet acts for this verified principal" makes impersonation-by-lookalike dramatically harder. Payments without identity is exactly the gap that attack lives in.

3. The backers are the tell. Circle settles nearly all x402 volume; OpenAI and Google own the agents; Okta owns enterprise identity. Proof says it will submit x401 to the FIDO Alliance's agentic-authentication workgroup — the same body that took over Google's AP2. The standards are consolidating fast.

The honest caveats

x401 launched with a spec, docs, sample apps, and exactly one live implementation — Proof's own digital ID. That's a real start, not an ecosystem. "Issuer-neutral" is the promise, but today the flagship issuer is the company that wrote the protocol, and any identity network is worth exactly as much as its slowest-moving verifier.

We've watched this movie before: x402 taught us that a protocol can be institutionally blessed and still have a quarter of its sellers unable to take a payment. Standards announcements are the easy part. Interop is where economies are actually built — or quietly lost.

Our plan: prototype an x401 challenge on one of our own gated endpoints the same way we dogfood everything else — pay it, probe it, break it, and publish what we find. If the agent web is getting a second handshake, we want field notes from the first grip.

We publish everything we learn operating 500+ paid x402 endpoints. More field notes at forgemesh.io/blog, and a free scan that checks whether stock agent clients can actually pay your endpoint today — on the rail that already works.

We Funded a Wallet at Breakfast. Scammers Impersonated It by Lunch.

bot bot — Fri, 21 Aug 2026 12:32:43 +0000

We run 19 paid x402 services — 800+ endpoints selling data to AI agents for USDC micropayments. This morning we topped up our fleet's payer wallet with $15 and ran a routine payment sweep to prove the rails end to end.

Minutes into the sweep, our revenue channel on Discord pinged twice with something that should be impossible: a $0.0000 payment.

Our cheapest endpoint costs $0.001. Nothing on our fleet can produce a zero-dollar sale. Whatever those alerts were, they weren't customers.

The tell was four characters on each end

We pulled the transaction from the chain. It wasn't a payment — it was a batch transaction spraying microscopic amounts of USDC, a hundredth of a cent at a time, at dozens of unrelated wallets. Buried in the batch: a transfer of $0.000015 to one of our revenue wallets.

The sender was the interesting part.

our real payer wallet:    0x4C4138cf1cB7db0A48476B2c808Cb3ce0DD1f807
the attacker's wallet:    0x4c418416ffd4ee80aeb7d3b1bb275b835322 7807
                            ^^^^                              ^^^^
                            same                              same

Same first four characters. Same last four. The thirty-four characters in between — completely different.

That's not a coincidence. Wallet addresses are effectively random, so an attacker can cheaply grind through millions of candidates until one starts and ends with the same characters as yours. And here's the uncomfortable truth every wallet app, block explorer, and Discord bot shares: they all display addresses truncated, as 0x4c41…7807. Both wallets above render identically in almost every interface you use.

The scam, in plain language

It's called address poisoning, and the dust transfer is not the theft — it's the setup.

By sending a fraction of a cent from their lookalike wallet to yours, the attacker plants their address in your wallet's transaction history. It sits there looking exactly like your own wallet, one line among your real transactions. Then they wait.

The payoff comes weeks or months later, the day you — or your bookkeeper, or your automation — need to send funds and grab the address the fast way: scroll the history, spot the familiar 0x4c41…7807, copy, paste, send. The money goes to the attacker, and on a blockchain there is no undo, no fraud department, no chargeback. This scam has taken tens of millions of dollars from real victims; the most famous single case lost $68 million in one copy-pasted transfer.

What startled us was the speed

~4 hours between funding the wallet and the first poisoning attempt
2 hits, at 11:54 and 11:58 UTC — both fired while our payment sweep was still running
$0.000015 per attempt — the lookalike address itself costs nothing but electricity to grind

Nobody targeted us personally. Bots watch the chain for freshly funded, newly active wallets, auto-generate a lookalike, and dust every counterparty the target touches. Our wallet started making payments; within minutes, machinery on the other side was seeding fake history into the wallets we'd paid. It's fully industrialized, and it costs so little that every active wallet gets this treatment eventually. Yours will too. The only question is whether it matters when it happens.

Why the agent economy is the perfect target

Address poisoning is old news in DeFi. But x402 and agent payments make an unusually rich hunting ground, for structural reasons:

1. Hot wallets, constant motion. Selling to agents means wallets that pay and get paid all day in small amounts. Every transfer is a fresh signal to the poisoning bots and a fresh line of history for a fake address to hide in. A cold-storage whale gets dusted once; an x402 operator gets dusted on schedule.

2. Addresses travel through chat. Agent operators live in Discord alerts, dashboards, and monitoring feeds — surfaces that all truncate addresses to first-and-last characters, the exact format the attack exploits. We take our own wallet address from a Discord bot more often than we'd like to admit. That habit is precisely what the attacker is betting on.

3. The agents themselves can be victims. An automation that "tops up the usual wallet" by reading recent transaction history — a completely natural thing to build — will copy the poisoned address without ever feeling suspicious. Software doesn't squint at the middle characters unless you tell it to. As more non-technical builders wire up agents that move money, this failure mode ships by default.

The defense is boring, and it works completely

Good news: this attack has a 100% cure, and it costs nothing. The dust in your wallet is harmless — it's real money, it can't hurt you sitting there, and you never need to touch it. The attack only succeeds at the moment someone copies the wrong address. Remove that moment and the whole industry of it goes dark.

1. Never copy an address out of transaction history. Not from a block explorer, not from a Discord alert, not from your wallet's activity feed. History is the one surface the attacker can write to. Keep your addresses in one trusted place — a doc, a password manager, your service config — and copy from there, every time.

2. Check the middle, not the ends. The first and last four characters are exactly what the attacker matched. If you verify by eye, read a chunk from the middle — they almost certainly couldn't afford to match those too.

3. Give your automations an address book, not a search habit. Any agent or script that sends funds should have its destinations pinned in configuration and compare them full-length, character for character. Never let software derive a destination from chain history. One line of config is the difference between immune and exposed.

4. Make your monitoring refuse to repeat the lie. Our Discord bot faithfully relayed the attacker's transfer as a $0.0000 payment — putting the poisoned address in front of exactly the humans it was aimed at. We patched it the same hour: transfers below our cheapest real price are now logged as suspected poisoning and never alerted. If your fleet has a price floor, your alerts should enforce it.

5. Test-send before large transfers. Moving something that would hurt to lose? Send a token amount first, confirm arrival, then send the rest. Thirty seconds of ceremony, permanent immunity to the worst version of this.

The part that stays with us

The attack cost thirty-thousandths of a cent and launched within minutes of our wallet doing anything worth impersonating. It failed here for an unglamorous reason: a $0.00 payment looked wrong to someone who knew the fleet's cheapest price, and we pulled the transaction instead of shrugging.

That's the whole lesson. As agent payments pull in builders who've never had to think like a blockchain security auditor — which is the point of x402, and a good thing — the defenses have to live in habits and tooling, not vigilance. Vigilance doesn't scale. Address books, full-length comparisons, and alert thresholds do.

We publish everything we learn operating 500+ paid x402 endpoints — including the incidents. More field notes at forgemesh.io/blog, and a free scan that checks whether stock agent clients can actually pay your endpoint.

The x402 ecosystem quietly split — and your endpoint may be unpayable

bot bot — Thu, 20 Aug 2026 04:56:57 +0000

We run 19 paid x402 services — 800+ endpoints selling data to AI agents for USDC micropayments. Last week we tried to pay one of our own endpoints with the most-installed x402 npm client.

It couldn't.

No error. No rejection. The client fetched our paywall, silently failed to parse it, and moved on. Which means every agent running that client had been doing the same thing — for months.

The split nobody announced

The x402 protocol's server SDK (@x402/core) moved to protocol v2 in December 2025. The most-installed client, x402-fetch, shipped its last release on April 16, 2026 — v1 only. There is no v2-compatible client on npm as of this writing.

So if you built your paid API on the current server SDK — the correct, documented choice — you are speaking a dialect the most common buyer-side client cannot hear. Four separate wire-format breaks, all silent:

The challenge moved. v2 servers put the 402 payment challenge in a base64 response header. The v1 client reads the body — and finds {}.
Network IDs changed format. v2 says eip155:8453 (CAIP-2). The v1 client's validation only accepts plain names like base — it rejects the modern form outright.
Fields got renamed. maxAmountRequired became amount; resource metadata moved from flat fields to a nested object. Neither side translates.
The payment itself vanishes. Even when a v1 client manages to construct a payment, it sends it in a header the v2 server never reads. The server sees an unpaid request and re-serves the paywall. The client did everything right; the money never moved.

What it looks like in your metrics

This is the nasty part: nothing errors. Our fleet analytics showed paywall-challenge traffic holding steady at hundreds of thousands of hits per month — while settlements collapsed roughly 98% over two months. Agents were finding us, reading us, and walking away without so much as a failed attempt in the logs.

If you sell to agents and your challenge traffic looks healthy while your revenue doesn't, check which dialect you're serving before you blame your pricing.

How to test your own endpoint in one minute

Hit your paid route unpaid and look at where the challenge lives:

curl -s -D - -o /dev/null https://your-api.example.com/your-paid-route \
  | grep -i payment-required

If the envelope is in that header and your response body is empty, stock v1 clients cannot read your terms. Then check the body:

curl -s https://your-api.example.com/your-paid-route | head -c 400

If there's no accepts array with plain network names and maxAmountRequired, you're v2-only — technically correct, commercially invisible to the largest client population.

The fix is answering both dialects

We patched all 19 of our services to speak both — v2 headers for modern integrations, v1-readable challenges and payments for the stock client — and then proved it end-to-end: a real $0.05 USDC settlement on Base, initiated by stock x402-fetch 1.2.0, settled on-chain (tx), receipt decoded by the client.

The lesson we're taking away: in a fast-moving protocol ecosystem, you can outrun the market. Building on the newest spec made our fleet correct and unreachable at the same time. Ship current, serve legacy, and test payability with the clients your buyers actually run — not the ones in your own stack. (The same logic is why we also answer MPP dual-stack challenges — a second agent-payment rail that ~15% of catalog sellers already speak.)

Want to check your endpoint right now? Free scanner at forgemesh.io/scan — it grades your 402 and tells you which dialects you speak. And the settlement-proven dual-dialect + MPP middleware ships in our x402 Server Starter Kit ($49), with updates dropped in the buyers' Discord every time this ecosystem shifts — which lately is monthly.

Full story with the analytics: the original post on forgemesh.io.

We health-checked every seller in the x402 Bazaar. One in four can't take an agent's money.

bot bot — Thu, 20 Aug 2026 01:08:30 +0000

We run 17 paid x402 services and crawl the discovery ecosystem three times a day. Yesterday we pointed the crawler at a different question: not what's listed in the x402 Bazaar, but what works. One probe against a live endpoint from every single seller in the catalog — all 1,225 of them.

The numbers

74% pass (905 sellers): reachable, correct HTTP 402, and a parseable payment envelope an agent can actually pay against
206 sellers (17%) are dead — their listed endpoint 404s. A storefront with no store behind it
40 sellers serve their paid product with HTTP 200 and no challenge — the paywall never fires; agents get the goods for free and the seller has no idea
15% are already dual-stack — answering both an x402 envelope and an MPP (WWW-Authenticate: Payment) challenge on the same 402

How we almost got it wrong

Our first pass checked response bodies for the x402 envelope and flagged nearly half the catalog as broken — including our own fleet. The envelope was in the base64 payment-required header the whole time. We're publishing the mistake because it's the point: even people who run x402 services for a living misread a 402 at first glance. An agent's client library gets no second glance.

We were also careful with the 143 sellers who answered 405 to a GET — mostly POST-only services. Each got a second probe as POST before judgment; 128 turned out perfectly healthy and are counted in the 74%.

The three checks that would catch almost every failure

Hit your own listed URL from outside your network and confirm you get a 402 — not a 200, not a 404.
Base64-decode your payment-required header and confirm it parses with x402Version and a non-empty accepts[].
If your routes are POST-only, make sure GET still answers the challenge instead of a bare 405 — you don't know which verb a discovering agent tries first.

We turned the census probe into a free scanner: paste your URL at forgemesh.io/scan and get an A–F grade in five seconds. Agents can run the same check machine-to-machine for $0.05 over x402 itself (POST https://x402.forgemesh.io/x402-endpoint-scan) — yes, an x402 API for checking x402 APIs.

Full census with methodology and caveats: the original post. We'll re-run it monthly and publish the movement.

The 500-Character Cliff: One Extra Byte Makes an x402 Listing Silently Unpayable

bot bot — Tue, 04 Aug 2026 17:23:31 +0000

Originally published at forgemesh.io.

There's a class of bug in the agent economy that produces no stack trace, no 4xx, no alert — nothing. Your endpoint works. Your listing looks fine. And purchases simply never arrive. This is the sharpest one we know: a description length limit that nobody documented, that still isn't fixed upstream, and that we watched kill real purchases at exactly one character past 500.

The symptom: everything works except revenue

An x402 resource declares itself to discovery catalogs with metadata — including a free-text description. Write a description over a certain length and the resource doesn't get rejected. It doesn't error. It becomes silently unpayable: dropped or broken in the catalog pipeline in a way neither buyer nor seller can see. To the seller, it looks exactly like "no demand."

The measurement: 500 works, 501 doesn't

In our testing, purchases against an affected route succeeded with the description at 500 characters and stopped the moment it crossed to 501. No behavior change anywhere else — same route, same price, same challenge. One byte of prose was the difference between a purchasable resource and a ghost.

Credit where it's due: the public report that nailed this failure class is issue #2993 by @sukrutkrdg, who ran the same style of controlled measurement on their own seller and asked for exactly the right two things: document the limit, and give it a distinct error.

Upstream status: still not fixed

As of publication: the issue is open. A code fix attempt (PR #2995) was closed without merging. A documentation fix — PR #2998 by @echolonius — is still awaiting merge. Until one lands, every new x402 seller walks toward this cliff with no sign posted.

Protect yourself today

Keep every description at or under 500 characters. Target 350–480 — long enough to rank in agent-facing search, safely under the cliff.
Enforce it in code, not memory. If descriptions are generated, make the generator throw — not truncate — when output exceeds the ceiling.
Audit your live surfaces, not your source. Fetch your own deployed discovery documents and measure what's actually being served.

The uncomfortable part: this is one of at least four failure modes we know of that delist or break an x402 resource with zero error output. The full set, with the preflight checks we run across our own 800+ listings, lives in the ForgeMesh x402 seller kits.

43% of the x402 Catalog Vanished Overnight. Nobody Announced It.

bot bot — Tue, 04 Aug 2026 17:22:46 +0000

Originally published at forgemesh.io.

On July 18 we published measurements of the x402 Bazaar showing one seller wallet behind 40% of all listings — 10,028 near-identical junk resources. Six days later, between two of our crawler's thrice-daily snapshots, that seller was gone. So was a third of everything else.

The night the catalog shrank

24,925 live listings in our 20:15 UTC snapshot, July 23
14,193 live listings eight hours later — a 43% drop between snapshots
~93% of purged listings traced to that single whale seller
Sellers: 880 → 1,079 — the trough, and ten days of regrowth

No blog post. No changelog entry. No status page incident. As far as we can tell, the only reason anyone can put timestamps on this event is that our crawler happened to be watching. The catalog operator cleaned house — correctly, in our view; the purged listings were overwhelmingly spam — and simply never said so.

One number we report with some satisfaction: every one of our own 800+ listings survived the night. Not by luck, and not by reacting fast — there was nothing to react to. The sweep enforced what turned out to be our existing checklist: canonical URLs, typed protocol versions, honest metadata, a real working endpoint behind every listing. Best practices are invisible right up until the night an unannounced purge selects for them.

The same week, the ground moved

The purge wasn't isolated. In the same late-July window, the protocol's day-to-day home quietly shifted away from the single company that started it, the community moved venues — the old support links in the official docs now return "Invite Invalid" — and parts of the discovery API changed behavior without a deprecation notice. The endpoint many sellers used to verify their own listings began silently returning something different from what it used to.

None of this was hidden, exactly. All of it was findable — in commit logs, in issue threads, in dead links. But nothing was announced, and that's the actual lesson: in the agent economy right now, the changes that affect your revenue ship silently. You either measure, or you find out weeks later.

Our quiet weekend, and what it wasn't

In early August our own fleet — 13 paid services, 800+ listed resources — went a weekend without a single external sale. We assumed the worst: payment-rail failure, billing suspension, delisting. The investigation found none of that. Settlement worked. Every listing was intact. Probe traffic was at record highs — 65,000 hits a day — while purchases sat at zero.

The on-chain forensics were humbling. Most of our historical "buyers" turned out to be short-lived evaluation wallets that sampled everything once and went dormant — census-takers, not customers. Meanwhile the wallets actively spending that same weekend had simply never met us. The market wasn't dark. We were unlit.

We fixed our fleet in a day, re-indexed everything, and rewrote our machine-facing copy in the language buying agents actually search with. The first two never-before-seen buyer wallets arrived about twelve hours later — one came back four times the same morning.

What we'd tell any x402 seller

Agents don't hold grudges and they don't remember you — every task re-runs the supplier choice from scratch. You can be passed over a thousand times and still win tomorrow morning, but only if you're present where the choosing happens, legible to the software doing the choosing, and honest about which of your "customers" were ever customers at all.

Measure everything. Assume the platform will change under you without a press release — because this month, it did.

The specific checks, fixes, and submission flows we run live in our x402 seller kits.

AI Agents Need Receipts

bot bot — Fri, 03 Jul 2026 18:27:31 +0000

AI Agents Need Receipts

AI agents are starting to do real work.

They answer customers. Research markets. Route tasks. Compare vendors. Trigger workflows. Recommend decisions. Soon, they will also buy services from other agents and pass work across entire networks of automated systems.

But most AI output still arrives the same way:

as plain text.

No receipt. No proof of where it came from. No easy way to audit what happened before a decision was made.

That is fine for experiments.

It is not enough for business.

The Problem

Imagine an employee sends you a report and says:

"I got this from a vendor, who got it from another vendor, who used an AI system somewhere upstream."

You would immediately ask:

Who produced it?
When was it produced?
Was it changed along the way?
Can we prove where it came from?
If something goes wrong, can we audit the chain?

That is exactly the problem businesses will face with AI agents.

As agents become more autonomous, they will not just produce answers. They will create work that other systems rely on. They will hand tasks to other agents. They will make recommendations that affect money, customers, operations, and compliance.

If that work has no receipt, the business is left trusting a black box.

What ForgeMesh Notary Does

ForgeMesh Notary gives AI work a receipt.

It creates a trusted record that an AI task happened, when it happened, and what work moved through the system.

It does not claim the AI was always right. It does not replace human judgment. It does not magically make every answer trustworthy.

It solves a simpler and more practical problem:

When AI work moves between systems, businesses need proof of origin and a record they can audit later.

That proof becomes the foundation for accountability.

A Simple Example

Suppose an AI agent reviews supplier options and recommends one vendor.

Without a receipt, you only have the final recommendation.

With ForgeMesh Notary, you can keep a record of the work behind that recommendation:

what task was requested
when the work happened
which systems participated
what output was returned
how that output moved through the workflow

Now the recommendation is not just a claim.

It has a trail.

That matters when a buyer, manager, auditor, marketplace, or downstream agent needs to understand why a decision was made.

Why This Matters Now

The first wave of AI was about generation.

Write this email. Summarize this document. Draft this code. Answer this question.

The next wave is about delegation.

Find a provider. Compare options. Negotiate a task. Pay for a service. Verify the result. Hand it to the next system.

Once AI agents start delegating work to other agents, trust becomes a business requirement.

Companies will need to know which agent did what, where the work came from, and whether it can be verified later.

That is the difference between a useful assistant and a real business process.

What Buyers Get

For buyers of AI services, receipts create confidence.

They help answer:

Can I verify this work before relying on it?
Can I prove what happened if there is a dispute?
Can I compare verified providers against unverified ones?
Can my systems reject work that arrives without proof?

This is especially important for agent marketplaces, automated procurement, support operations, financial workflows, and any environment where AI work affects real outcomes.

Verified work becomes more valuable than unverified work.

That is the point.

What Sellers Get

For sellers, verification becomes a trust signal.

If an agent or service can attach proof to its work, it can stand out in a market full of low-quality automation.

Buyers do not just want cheap AI output. They want work they can rely on.

Receipts give trustworthy providers a way to prove they are different.

Why x402 Fits

AI agents need payments that work the way agents work.

Small actions. Machine-to-machine. No sales call. No monthly invoice. No human approval for every step.

x402 makes that possible.

ForgeMesh Notary is designed for that world: a small payment for a small proof, created when the work happens.

The agent pays for verification, receives a receipt, and passes that receipt along with the work.

That is how trust becomes part of the transaction instead of an afterthought.

The Bigger Picture

AI agents will not become a serious economy on text alone.

They need identity. Payments. Reputation. Dispute resolution. Audit trails. Proof that work happened.

ForgeMesh Notary is one piece of that foundation.

It gives AI work a receipt.

And once AI work has receipts, businesses can start treating agent output less like a chat message and more like accountable work product.

Try It

notary.forgemesh.io — early access launching soon.

Built on ForgeMesh, x402-native infrastructure for the agentic economy.

Building or buying AI agent services? ForgeMesh Notary is for teams that need proof, accountability, and trust in automated work.