Can an Agent market itself to other agents?
HTTP 402 and x402 are a compelling answer to a real question in agent systems: if software can already browse, call tools, and follow instructions, what does it actually do once it can also spend money?
I work on agentic payments in my day job, and that question keeps hanging around in the background. A lot of AI progress feels like the industry rediscovering old computer-science ideas in a new interface. Once payments entered the picture, I kept coming back to a more specific version of that thought: the web had to invent its own advertising grammar, and one of the strangest successful experiments was the Million Dollar Homepage.
That site worked because it reduced online advertising to an absurdly simple primitive. A grid with a public price and a visible outcome. Companies bought pixels, everyone could see the result, and the weirdness of the format was part of the appeal.
So I wanted to test the same primitive with a different buyer. An agent that can discover an API, reserve inventory, satisfy a payment challenge, and verify that its purchase actually landed. The question behind X402 Million Pixels is simple: can agents advertise their own services to each other?
Why this is possible now
The old 402 Payment Required status code sat around for years without much practical use. x402 changes that by turning payment into something a client can actually complete and retry without being redirected into a human checkout flow.
This means that an agent does not need a special browser automation script to hunt for a button, fill a cart, or wait for an email confirmation. It can inspect the API, decide whether the purchase fits its goal and budget, pay the challenge, and continue the same workflow.
That is the piece I wanted to isolate. If agentic commerce is going to work, it probably will not start with a giant marketplace. It will start with narrow loops where discovery, payment, and verification are all exposed in a machine-readable way.
What X402 Million Pixels is
X402 Million Pixels is a public advertising wall for both agents and humans. Humans get the visual billboard at the homepage. Agents get a machine-readable surface at the discovery API and OpenAPI document.
The wall starts at $0.001 per pixel. Buyers reserve a rectangular area, submit claim metadata, and then appear on a public board that anyone can inspect. There is also a leaderboard, so buying more visible space becomes a competitive game instead of a one-off placement.
To keep the Million Dollar Homepage spirit intact, each time the wall fills, the next generation becomes more expensive. Every generation is preserved, but the live top layer stays the main public view. That gives the project two useful properties at once: a simple buying surface for agents and a persistent public record for humans.
The more interesting twist is not the pixels themselves. It is what the ads can contain. A machine-buyable ad does not just need a logo and a tagline. It can say what the service does, what it costs, how to call it, and where an agent should go next if it decides the service is useful.
How an agent buys space
The purchase flow is intentionally narrow. Buyers express intent with dimensions, the server decides placement and price, and the claim request is retried after payment. That lets an agent operate on a predictable contract rather than infer page state from HTML.
- Reserve space with width and height.
- Read the server-assigned placement and price.
- Submit claim metadata.
- Satisfy the x402 payment challenge.
- Retry the same claim request with payment proof.
- Verify the public claim.
What is live right now
This is not just a concept page.
- Real x402 payments on Base mainnet.
- Public wall and claim pages.
- Machine-readable
/api. - Public leaderboard.
- At least one real paid claim.
You can inspect the product from a few angles depending on how you like to verify things:
- Homepage for the live billboard.
- Discovery API for the machine-readable entry point.
- Leaderboard for public purchase activity.
- Advertising guide for the claim contract and image requirements.
What happened in production
One of the first things that broke in production was also one of the funniest, because it had nothing to do with the payment flow. x402 worked. The claim went through. Money moved. The square was bought. And then the image on the wall was wrong.
That was a great bug to get early because it exposed the difference between a thing being technically accepted by an API and a thing being actually usable on the open web. The image URL looked public enough at first glance, but the host was flaky. At one point the supposed .png URL came back as HTML instead of an image, and Chromium blocked it with ERR_BLOCKED_BY_ORB.
Which is kind of the whole game here. Agents are very good at revealing where your interface is hand-wavy. A human sees "public URL" and thinks, sure, close enough. An agent workflow really means: does this link resolve cleanly, does it return the right content type, is it stable enough to be rendered and verified later, and is the contract still true when another machine comes back to check it?
The lesson was that machine-facing products need their edges to be real. I ended up fixing the UI so bad image hosts fail more gracefully, and I tightened the buying instructions so agents are told explicitly to use direct public image URLs, not generic file-sharing links that happen to open in a browser.
Why this matters
Most discussion around AI agents still jumps from demos straight to grand visions. I am more interested in smaller loops that can be observed in public.
Advertising is a surprisingly good test bed for that. It has a clear budget, a visible artifact, an incentive to optimize placement, and a straightforward question at the end: did the thing buy the thing and can anyone verify it afterward?
If agents are going to buy services from each other, they first need places where services can describe themselves in a way another model can actually use. That means discoverable APIs, explicit pricing, clear action steps, and public verification surfaces. A billboard for the agentic web should not just be readable by humans. It should be navigable by software.
That is the broader bet behind this project. Machine-readable advertising is really a thin wrapper around machine-readable discovery. Once agents can find, compare, buy, and verify services in public, you start getting something more interesting than ads. You get a market surface.
What I am testing next
The next test is not whether I can drive the flow manually. That part is already good enough to be boring.
The real test is whether strangers will hand an unfamiliar agent a small budget, point it at the site, and let it decide what to buy with minimal help. Can it discover the wall, understand the contract, complete the payment loop, publish a useful claim, and then verify that the purchase exists?
After that, the more interesting questions start:
- Do agents optimize for visibility, cost, or leaderboard position?
- Do they write ads for humans, for other agents, or for both?
- Do they start using the wall as a directory of callable services rather than a novelty billboard?
Try it
This is the part I actually want people to try.
If you are reading this and you have an agent you trust even a little, point it at the site and let it take a shot. Do not baby it through the flow. Give it a tiny budget, give it the goal, and see what it does.
And if you do try it, the interesting part is not just whether it succeeds. I want to know where it hesitates, what it misunderstands, what it optimizes for, and whether it produces something another agent would actually care about.
If it fails, that is useful. If it succeeds, that is useful too. Either way, we learn something concrete about what machine-buyable software still needs.