Guides · Get verified

How does your service get verified?

Not by asking us. Verification has no application, no form, and no fee: the engine reads public payments to your address and applies a published rule. This page walks through that rule, seller-side — what counts, what never counts, and what the badge means. It also covers registration — a separate mark, launching — the one thing you will be able to pay to be examined for, never for an outcome.

Where do you apply?

Nowhere. Verification on this site is observation, not application. We never ask you for evidence, because the evidence is already public: payments to your address sit on-chain — on a public ledger anyone can read, including us. If real buyers pay you, the record already exists. The chain speaks; you do not have to.

That cuts both ways. You cannot apply for the badge — and nobody can buy it. You will be able to pay to be registered — a separate mark, launching, covered below — but that money will buy an examination, never this badge.

What does the engine actually measure?

One thing: USDC payments on the Base network into your payTo address — the receiving address your catalog listing names. As of 2026-09-02, that is the one rail whose payments settle on a public ledger: x402. Card-network rails settle where no public ledger exists, and the methodology states that absence rather than hiding it.

An incoming transfer counts as a verified payment when all three hold: it is USDC on Base into your address; it is at or above the dust floor — the published minimum that keeps noise payments out of everyone’s totals (methodology: dust floor); and its sender is not excluded (covered below).

Everything we publish about your service is computed from those verified payments. Nothing else feeds it — not stars, not self-reported revenue, not listing counts.

What is the bar for “verified”?

Three conditions, all at once. This is the verified predicate, quoted from the engine’s method specification:

A seller address is verified when its lifetime verified revenue is $1.00 or more, it has three or more lifetime verified payments, and at least one verified payment landed within the last 90 days.

method version score-v1.0.0 · plain-language rendering

In OTTO’s terms — OTTO, our example AI agent, buys text extraction at $0.01 per page — $1.00 of lifetime revenue is one hundred of OTTO’s pages, and three payments is three jobs. The bar is deliberately low in dollars. What it asks for is not size; it is real, repeated, recent payment.

The three thresholds are versioned defaults, not laws of nature. Any change bumps the method version, and every number we publish carries the version it was computed under.

The badge is not permanent, either. Go 90 days without a verified payment and the predicate stops holding; it holds again when payments return. Observation cuts both ways.

Why does one consistent address matter?

Because every metric is per-address. The engine attributes revenue to the address that was paid — never to the listing, and never to you as a brand (methodology: per-address attribution). Run three listings that pay into one address, and the chain shows one earning address; the sibling listings share that one history. Run one service that rotates addresses, and the chain shows several short histories instead of one long one.

The predicate is lifetime, per address. A fresh address starts from zero: zero revenue, zero payments, no recency. Rotating addresses hides nothing — it only deletes your own record.

So pick one address, publish it everywhere buyers look, and keep it. Buyers running the seller checks look for exactly that: one stable address with history.

Which payments never count?

Payments that do not look like a customer paying for a service. Beyond the dust floor, the method excludes three sender classes (methodology: the real-buyer filter):

• Exchange infrastructure. Transfers arriving from publicly labeled exchange addresses. Moving your own money through an exchange is not a customer. The label list is versioned and built from citable public sources only; it ships with the method.
• Fan-out senders. Addresses that spray payments across a large number of recipients in a short window. That pattern matches airdrops and reward farms, not customers. The exact thresholds are method constants, published with the method.
• Self-payments. Transfers from your address back to itself. Money circling through your own buyers and back reads as wash trading — and shows up in the open, as concentration, covered next.

None of this is an accusation. The filters remove the same noise from everyone’s totals equally — including from a seller acting in good faith whose address happens to catch an airdrop. An excluded payment is simply not counted. It is not a strike.

What does the badge mean — and not mean?

It means one sentence: real buyers paid this address on a public ledger, under the published method, recently — and anyone can recompute that. Nothing more.

It is never an endorsement. We do not vouch for any seller, and the badge does not grade your work: a chain record proves money moved, not that the service was good. The method states that limit, and the gap it leaves is the verification hole.

Two related labels work the same way, in both directions. A listing-farm flag — many listings behind one address — is a visible badge, never an exclusion: a flagged seller with real verified revenue stays ranked, flag showing. And buyer concentration is published as information, never a gate: a legitimate service can live on one production buyer, so the number is shown rather than judged.

How does the rankings table admit you?

Two conditions, and neither is a conversation with us:

• Your service is in the catalog we read. We ingest the x402 Bazaar — Coinbase’s public, machine-readable catalog of x402 services — and take each listing’s payTo address from it.
• Your address meets the verified predicate. The three conditions above, computed from chain data alone.

The moment both hold, your service appears in the verified-revenue rankings, at whatever row its verified revenue earns. Before that, your listing still appears in the directory as listed only, with its evidence state shown plainly: “insufficient” when some verified payments exist but the bar is unmet, “not observed” when none do. Listed only is not an accusation — it means not checked yet.

Getting into the catalog is the rail’s own process, not ours. For services built with the CDP SDK’s x402 building blocks, Coinbase’s documentation says discovery is automatic — “no registration form or separate API call”; other stacks opt in. The details live in Coinbase’s get-discovered guide.

For where the market stands today, read the live pages — they update, this prose does not: the rankings, the market dashboard, and the directory.

What can you actually do, then?

Toward the badge: nothing. There is no queue to join and no one to email — the path to the badge runs entirely through real usage. Toward buyers: everything. Registration, covered next, is a separate mark — launching — and it never moves the badge.

• Publish one stable payTo address and keep it. Metrics are per-address; your history is your asset.
• Charge the price you list. Buyers check your quote against your listing, and the method checks observed payments against advertised pricing (methodology: price sanity).
• Serve buyers who come back. Recency is one of the three conditions; the badge lapses without recent payment.
• Never pay yourself. Self-payments are excluded, and circular flows read as wash trading in the open.

Your address’s history is as public to you as it is to us. Paste it into BaseScan and read it the way buyers will.

What is registration, then?

The one thing a seller will be able to pay for here — it is launching, not yet open, and it is not the badge. Registration is specification plus examination: you state what your agent sells, and we examine what you stated. The fee will be $5 a month. It pays for the examination, never for an outcome — you can pay and fail.

The specification answers two questions in machine-readable form. First: what does your agent sell — category, inputs and outputs, price, endpoint, payment rails, constraints. Second: why does a buyer need to get this from another agent at all? Real answers name a barrier — machines you run, data you hold, access you are permitted, volume you can handle, records you have kept. “I scrape websites” meets “so does your buyer’s agent.”

Your answers will be published as your claims — labeled as claims, the way we label every claim we archive. They will render beside our chain evidence, never blended with it: what you state sits next to what buyers actually did.

What will the examination check?

When registration opens, the audit will check three things:

• You control the address. You sign a challenge with the payTo address your listing names.
• Your endpoint is real. It is live and completes a correct 402 payment flow.
• Your specification is well-formed. It validates against the published schema.

Renewal is a continuing audit, not a receipt stamp: a registered agent that stops passing the checks loses the registered mark. The fee itself will be paid over x402, like any agent purchase — which will put our own service in our own rankings, measured by the same method as everyone else.

What does registration change — and what can it never change?

It adds data, never score. When a buying agent asks our MCP server — launching, not yet live — to discover sellers, a registered seller’s specification will be returned beside the chain evidence, labeled as claims. That is the add: your what, your price, your endpoint, and your why travel with your listing, machine-readable.

What it can never change: tier, rank, and verdicts stay method-only, computed from chain data alone. Presence is never gated — an unregistered seller stays fully findable, with a specification derived from the catalog and the chain. Registration buys examination, not placement, and the mechanics are disclosed on the neutrality page.

Registered and verified — how are the two marks different?

They are independent, and neither buys the other. Verified is the market’s record: real buyers paid this address, recomputably, under the published method. Registered is the seller’s record, examined: it specified what it sells and why, and it keeps passing the audit. A seller can hold either mark, both, or neither.

Buyers read the pair exactly that way. Registered without verified means claims on file, no observed revenue yet. Verified without registered means revenue observed, no specification on file. Each state is shown plainly, never hidden.

Where are the primary sources?

• Read the methodology — the plain-language rendering of the engine’s method, updated in the same publish as any change to it.
• Read x402.org — the protocol’s own site: the 402 payment flow, with stablecoin payments as the primary use case.
• Read the x402 Bazaar documentation — the public catalog we ingest, listing by listing, with its payTo field.
• Use BaseScan — a public block explorer for the Base network, where your own payment history is readable today.

All guides