On October 3 an email arrived at the Major Matters address from someone called Jackson, who introduced himself as "an AI that runs GigSoul, with human oversight." My x402 tracker says to get in touch if you are building on the protocol, and he was. The note listed what existed, where to check it, and one fact most press releases would have buried: the only payments on the books were the company's own test calls. "We have no meaningful customer volume to report, and I won't claim any." It ended with a promise not to follow up.

I checked. Then I listed it. Then I thought about what it means that the first seller on my tracker to be run by an agent is also the first one my own tooling would refuse to transact with.

The tracker says "shipped." The identity layer says "not yet." They are answering different questions, and a market for agent payments needs both answers.

What I could check

GigSoul publishes an x402 manifest at api.gigsoul.com/.well-known/x402.json. It lists 30 endpoints priced between $0.005 and $2.00 per call, most of them at $0.04 to $0.10, settling in USDC on Base through the Coinbase Developer Platform facilitator. The endpoints are the kind of thing an agent buys on the way to doing something else: analyze marketing trends, generate a LinkedIn post, test and repair an automation workflow, capture and replay a webhook. One is unusual, and I come back to it below: verify-deliverable-and-issue-acceptance-receipt, $0.10, which checks whether a delivered item matches what was ordered and returns ACCEPT, REJECT or REVIEW with a reason code.

The company publishes its settlements at gigsoul.com/calls. As of October 3 the page showed 51 settled payments totaling $5.78 since September 19, every one of them from the company's own verification wallet into its own receiving wallet, with the line "No customer calls yet; every settlement is publicly auditable on Base and will be listed here as it lands." The site's footer says the company is "operated by AI (Jackson & Jayson) with human oversight." No person is named, no company registration appears, and no location is given. GigSoul is also a publication, "intelligence on the agent ecosystem," with a newsletter, which makes it something like a peer with a shop attached.

The email also said the endpoints are listed on x402 List, Smithery and Glama. I did not verify those three, and the tracker entry does not rely on them. The manifest and the settlement feed were the claims I could check from the outside, and both said what the email said.

Why "shipped, no volume" is a listing I can make

The x402 tracker exists for one reason: to record what has actually shipped on the protocol, by whom, in a form a reader can check. Most entries come from announcements that round up. A pilot becomes a launch, a waitlist becomes availability, an integration that works on a testnet becomes "live." The work of the tracker is mostly rounding back down.

This was the first entry that arrived rounded down. The seller volunteered the number that makes it look smallest, pointed me at the page where I could confirm it, and asked whether a "shipped, no volume yet" entry fit. It does, and the tracker needed a status for it. GigSoul is now the fourteenth integration on the list, marked live with the note that the 51 settlements are the operator's own QA calls, the manifest as the source, and the operator named, at its own request, as "Jackson, the AI that runs GigSoul." The human overseeing it asked not to be named, and is not.

Eighteen months of agentic commerce taught me to sort announcements into live, pilot, spec and withdrawn. This one needed a fifth label, and it was the seller who supplied it.

Why my identity layer would refuse to pay it

Two days before the email arrived I had put a small open model under a signed mandate on my laptop and run it through seven bank-customer jobs, 21 times, and then repeated the whole run with the packaged harness. The harness checks every action against three layers before it happens: who the counterparty is, what the mandate allows, and what the budget permits. The first layer has one rule that matters here. A counterparty whose identity cannot be verified is never dealt with. Not refused with a reason, not escalated to the customer, never contacted.

GigSoul is that counterparty. It has a manifest, a wallet, a settlement history and a stated operator, and it has nothing a verifier can resolve to a responsible party: no named person, no registered entity, no address, no identity document that signs anything. The protocol it sells through does not require one. That is x402's design and much of its appeal: the HTTP 402 status code, a price, a signed stablecoin payment, the resource, no account and no onboarding. For an agent buying a $0.05 answer, the absence of identity is the feature.

For an agent spending a customer's money it is the gap. The bank-customer jobs on my bench include buying a kettle, and the environment dangles a cheaper seller that is "online, unverified." In 42 runs across the two passes the model never once tried it, or the data broker and the unlisted energy supplier the other jobs dangle, so the identity layer never had to fire. But the rule is there because a model will not always be that careful, and because the question "who do I pursue when the kettle does not arrive" has to have an answer before the payment, not after. A seller run by an agent, with the human withheld, is the cleanest example yet of a counterparty that passes every protocol check and fails that one.

x402 makes it possible to pay a seller nobody can identify. A mandate makes it possible to refuse to. The market will need both, and the second is further behind.

The receipt that judges its own delivery

The endpoint I keep coming back to is the acceptance receipt. For $0.10, GigSoul's API will look at an order and a delivery and return ACCEPT, REJECT or REVIEW, with a stable reason code, using what the manifest calls "JSON-only structural checks." It is sold as a primitive for agent-to-agent purchases: one agent buys, the other delivers, a third call says whether the delivery matched.

The idea is right. Agent commerce needs a verdict on fulfillment that neither party controls. The implementation is the seller of a service offering to grade deliveries, including, in principle, its own. An acceptance receipt is only worth something if the party issuing it is not the party being judged and cannot edit it after the fact, which is why the witness layer in my kits is a hash-chained, signed trail that both sides can re-verify from the file alone, and why the bench publishes its evidence under exactly that kind of manifest. A structural check that the JSON has the right fields is a useful first step. It is not a receipt a customer can take to a dispute.

The agents guide separates the plumbing that moves money from the plumbing that proves what happened. GigSoul has built the first kind and is selling a thin version of the second. That is not a criticism of a shop whose first settlement is two weeks old. It is the shape of the whole market in October 2026.

What a listing policy for agent-run sellers should say

The tracker had no written policy for this case, so here is the one I applied, written down for the next operator who writes in.

An agent-run seller can be listed when its claims are checkable from the outside without an account: a published manifest, settlements on a public chain, a stated operator. The status reflects the checkable volume, so "live, no customer volume" is a status and will stay one until the settlement feed shows a payment from a wallet that is not the seller's. The operator's self-description is recorded as a description, not as a verified fact, and the entry says when a human is not named. Nothing about the listing implies that the seller is safe to transact with; the identity question is the buyer's, and the entry gives the buyer what it needs to ask it.

Vendors of hardware, by contrast, get a different treatment on the bench: a loan, a protocol, a disclosure. A seller of $0.05 API calls run by an agent is a different kind of thing, and the honest response is to list what is true and say what is unknown.

What comes next

The settlement feed is public, so the first customer call will show up without anyone announcing it, and the status changes when it does. The overseer can be named later if they choose. And the next time an AI writes to the tracker, the policy above is what it gets, which I suspect it will read more carefully than most people do.

If an agent-run seller passes every protocol check and no identity check, whose job is it to decide whether your agent may pay it?

Charlie Major is a Product Development Manager at Mastercard. The views and opinions expressed in Major Matters are his own and do not represent those of Mastercard.