The payment was verifiable. The work wasn't.

Yesterday I paid $20 to a machine.

Not a subscription, not a checkout page. My agent hit an API run by ProductClank, got back an HTTP 402 with a price, signed a USDC payment on Base, retried the request, and bought a boost campaign for one of our posts. Ten replies from their agent network, $2 each. No account, no invoice, no human on either side of the transaction.

Here's what struck me afterward. The important facts about the payment were independently checkable. The record of the work couldn't tell me much of anything.

TL;DR: I made a real machine-to-machine purchase where the payment was independently verifiable end to end, but the buyer-visible record of the work was basically a counter. The first delivery had a real problem; the later delivery was healthy; the record could not tell the difference. That gap is the part of the stack I'm working on.

What I could verify about the payment

The payment side of this transaction left a trail that anyone can check:

• The 402 challenge stated the price and terms before any money moved.
• The settlement is on-chain: one transaction on Base, $20.00 USDC, status success.
• ProductClank exposes a keyless status endpoint keyed to the payment nonce. Any holder of the nonce can confirm the purchase settled and see the campaign it bought.

That's genuinely impressive machinery. Five years ago this transaction takes a sales call. Yesterday it took one HTTP retry.

What I could verify about the work

The agreement was 10 replies. The delivery record I can query says this:

items_generated: 20
items_claimed: 20
status: active

That's it. Counts.

The record can't tell me whether the replies matched the guidelines I paid under. It can't tell me whether they came from ten agents or one. It has no notion of a reply that shouldn't count.

And that second question wasn't hypothetical. The first wave of delivery was five replies from a single account in about two minutes. ProductClank's founder, Lior Goldenberg, replied publicly on the boosted thread within hours:

"I see it worked but i also see the same agent claimed all tasks, which is not the intended behaviour! let me dig into it..."

I want to be clear about the tone here, because this is not a gotcha. Lior saw the problem in public, acknowledged it in public, and fixed it fast. Later replies came from distinct accounts and were genuinely on-topic. That's a founder behaving exactly the way you'd hope, on a product that's early and moving quickly. We were a $20 self-serve buyer, nothing more.

But notice what the fix didn't change: the buyer-visible delivery record. Before the fix, it would have counted one agent claiming everything. After the fix, it counts a healthy delivery. Same shape, same numbers, no way to tell them apart from the record. The difference between those two deliveries lives entirely in a founder's attention and a public reply thread.

A counter that says 20/20 can't tell a healthy delivery from an unhealthy one.

This is the industry default, not a ProductClank problem

I keep seeing the same asymmetry everywhere in agent commerce, and I wrote about the general form of it in payments know when money moved, not whether it was earned:

• Payment: challenge, signature, settlement, receipt. Every step verifiable by a third party.
• Work: a counter goes up, a status says done.

The payment rails are ahead because payments had to be adversarial from day one. Money attracts precision. Work has been allowed to stay vague because a human was always around to eyeball it.

The point of agent-to-agent commerce is that a human shouldn't have to eyeball every transaction. My agent bought from their agents. The only reason this particular delivery gap got caught is that a human founder happened to read his own replies, and a human buyer happened to be running a deliberate test.

The missing object is an acceptance record

The missing thing wasn't another payment primitive. It was an acceptance record.

Before the work: what counts. After the work: what passed, what didn't, and what was earned. Then a signed result another system can verify without reconstructing the whole transaction.

Spoolis builds exactly that object, so here's the honest version of what it would have changed, using the shape we run in production:

1. The agreement gets pinned before the work: 10 replies, distinct accounts, matching the stated guidelines, $2 per accepted reply.
2. Delivery gets verified against that agreement, per unit.
3. The result is a signed verdict, not a counter: accepted 8, rejected the duplicate claims, earned $16 of $20, here's why, here's the receipt.
4. Either side can hand that receipt to any other system, which can check the signature without trusting either of us.

The first delivery wave and the fixed delivery wave would produce visibly different results. That's the whole point. "Done" becomes checkable, and partial becomes payable.

We run this pattern live today at small scale: in one composed demo, an agent could spend up to $1.00 on 100 records, Spoolis counted 97, and the payment rail paid exactly $0.97. Per-unit acceptance is the same idea this boost purchase was missing.

What this does not prove

• One $20 purchase proves nothing about demand for verification. Buying from someone is not the same as someone buying from us: this is not Spoolis traction.
• It doesn't prove ProductClank needs Spoolis. They may build acceptance semantics themselves, and their record may already be deeper on the seller side than the buyer-visible endpoint shows.
• It doesn't prove the replies were bad. The later ones I read were thoughtful. My claim is only that the record can't tell me, and I paid based on the record.

What it does prove, concretely: a machine-to-machine purchase can settle today with strong independent payment verifiability and a buyer-visible work record that could not distinguish a healthy delivery from an unhealthy one.

Notes

• Purchase: 2026-08-28, 12:34 UTC. $20.00 USDC on Base via x402 (exact scheme), campaign CP-540, 10 replies expected. Settlement tx 0x0e3db622a2938ac2ed4a456aecd3ea3e5df402383a232c59829140696ba663df.
• Delivery record quoted from ProductClank's keyless purchases endpoint, checked 2026-08-28 ~21:15 UTC.
• Lior Goldenberg's reply is quoted verbatim from the public thread on the boosted post.
• We paid ProductClank as an ordinary self-serve buyer. No partnership, no contact beforehand, no endorsement implied in either direction.

Related reading: pay per verified unit · payments know when money moved, not whether it was earned · authorization is not earned value