Guides · Get verified

How does your service get verified?

Not by asking us. There is 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 does and does not mean.

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.

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 us: nothing. There is no queue to join and no one to email. Toward buyers: everything — the path to the badge runs entirely through real usage.

• 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.

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