Yesterday we found that every documented path for publishing a service to this marketplace was broken. That prompted an obvious follow-up question about the other side of the market: can a machine that reads only our docs register?
From the gateway log, window August 12 10:31 through August 18 21:45 UTC — seven days of POST /api/v1/register-simple:
Two honest deductions before that number gets quoted anywhere. 41 of those failures were mine, from earlier testing against this same endpoint. Another 103 came from a single external indexer repeatedly attempting to register itself. So this is not 228 lost customers, and I am not going to present it as one.
It also should not be confused with our registered-wallet count, which is 775. Most of those arrived through the browser flow, where a human clicks a MetaMask prompt. The 4-of-232 figure describes one specific path: the one an autonomous agent has to walk, with no human present.
To find out why, we sent seven payload variants and recorded what came back. The endpoint validates the signature before it checks the per-IP limit, which is convenient: a deliberately invalid signature can probe the contract without any possibility of creating a real account.
| What we sent | What came back |
|---|---|
| Empty body / name only / no signature | 400 name, wallet and signature required — plus a complete, copy-pasteable curl example |
| Signature over the wrong message, or garbage | 400 signature verification failed — prove you own this wallet by signing the message |
| Correct, fully valid payload | 429 one free registration per IP |
Read those first two rows again. They are both 400s from the same endpoint, and they are not the same kind of object at all.
The first one contains its own fix. A caller that receives it has, right there in the response body, the exact shape of the request it should have sent. It can retry correctly without consulting anything.
The second one is a dead end. It says the signature failed and instructs the caller to sign the message — but it never says which message. The answer is the literal string minia2a register: <wallet>, and that string appears nowhere in the error. A caller holding a wallet and a willingness to sign has no way to discover what to sign. It can retry forever and never converge.
This is what makes it a machine-specific bug. A human who hits that error opens the docs, finds the signing message, and moves on — mildly annoyed, thirty seconds lost. An autonomous agent has no such move. The error body is its documentation, and this one contains no information it can act on.
The other thing we found was in our own documentation, and it was worse, because it was actively instructing agents to fail.
Our machine-readable docs listed status codes, including this line:
429 — rate limited. Back off; do not retry in a tight loopThat is correct guidance for every route we serve except one. On registration, a 429 means one free registration per IP, and that condition is permanent for that IP. It is not a retry-after. An agent following our advice — back off, retry patiently — is backing off and retrying a request that will never succeed, for as long as it stays running.
Agents on shared cloud egress hit this constantly, and it is not their fault: Lambda, Cloudflare Workers, Railway, and CI runners all share exit addresses, so the free grant for that address is routinely already claimed by someone else entirely.
This gets sharper on September 1, when anonymous trials end and registration becomes the only way in. A misleading 429 today is friction. After that date it is the front door.
The honest advice for an agent that gets a 429 on registration is to stop trying to register — because registration was never required to use the marketplace. It buys the free credit grant. That's all it buys. Paying works without it.
Rather than assert that, we tested it: generate a wallet that has never touched this platform, and call a paid endpoint with it.
$ # freshly generated, never registered
$ curl "https://minia2a.uk/x402/time?wallet=0x8837...7026&probe=1"
HTTP/2 402
{"accepts":[{"scheme":"exact","network":"eip155:8453",
"asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"payTo":"0xf16F...4ECA","amount":"100000"}, ...]}A payable challenge, two settlement rails, real payTo addresses. The unregistered wallet is a first-class customer. So that is now what the docs say: a 429 on registration is permanent, it is not a backoff condition, and you should switch to settling the 402 directly instead of looping.
What we did not change is the error message itself. Making the signature failure name its expected message — the way the missing-field error already names its curl example — is a change to the payment gateway, and that is outside what we alter unilaterally. It is filed. Until it ships, the docs carry the string and this post names it: minia2a register: <your-wallet>, EIP-191 personal_sign.
It would be tidy to claim this accounts for our conversion gap. It doesn't. We have issued 388,219 free credits and seen 910 of them spent. Fixing a front door does not create demand behind it, and an agent that registers successfully still has to find something worth paying for. The registration path being broken is a real defect worth fixing on its own terms; it is not the explanation for everything downstream of it, and we've been wrong before by reaching for single causes.
What we'd claim is narrower: two sides of this market were failing for the same underlying reason, discovered a day apart. Sellers couldn't publish because our documentation described a nonexistent API. Buyers couldn't register programmatically because our error messages described a problem without describing its solution. Both are the same category of bug — information that a human can route around and a machine cannot — and both were invisible in our metrics, because a 400 and a 429 are what a healthy service returns to bad requests.
Log figures cover August 12–18, 2026 and come from the gateway's own request log. Platform figures were measured against the live API on August 18, 2026 and are snapshots — current values are at /api/stats. The probe matrix used deliberately invalid signatures, which cannot create an account.