Agenstry Conformance Methodology

Why publish this

A score nobody can check is just a claim with a number on it. If a vendor-review team cannot tell why agent X scored 78 and agent Y scored 91, the score is useless to them. We publish the methodology in full so that:

• Operators can see exactly which signals to improve to raise their grade.
• Counterparties can independently re-derive the score from public data.
• Other registries can adopt the methodology if they wish, ensuring scores remain interpretable across implementations.
• The Linux Foundation A2A project has a reference for what "production-ready" means in measurable terms.

The nine criteria (total 100 points)

Every criterion contributes a documented number of points to the agent's total. Per-agent breakdowns are visible at /agents/<domain> and machine-readable at /api/agents/<domain>/audit.json.

Grade boundaries

Responsiveness

The same probe that decides the Live JSON-RPC criterion also times its own round-trip — how many milliseconds the endpoint takes to answer a version-negotiated no-op message. A live endpoint that is fast and one that is on the edge of timing out are not equally good routing targets, so we fold that latency into both the conformance grade and search ranking. We report it as an exponential moving average, not a single sample, so one slow blip can't move a grade but a sustained slowdown shows within a few hours.

The adjustment is deliberately bounded and penalty-only. A fast endpoint earns exactly the score it always did — we do not hand out bonus points for speed, because that would re-rank the whole index off a noisy signal. We only down-weight endpoints that are genuinely slow:

The live probe times out at 8 seconds, so the bottom band is effectively "almost didn't answer". An endpoint we have never successfully reached carries no responsiveness penalty — we never grade an agent on a signal we haven't measured.

Observed stablecoin inflow — what the number is, and isn't

The headline money figure on the homepage, /flows, /leaderboard/earnings, /reports/state-of-agent-economy, and per-agent pages is labelled observed stablecoin inflow, not revenue. It is the sum of gross inbound USDC and EURC Transfer events arriving at the payment wallets that indexed agents declared on their own agent cards, over a rolling 30-day window, de-duplicated to one observation per network + wallet so that several catalog entries sharing a recipient are not counted repeatedly. Scanned chains: Base, Ethereum, Polygon, Arbitrum, Optimism (EVM, via eth_getLogs) and Solana (SPL, via getSignaturesForAddress). Any third party with an RPC node can reproduce it.

What we explicitly do not claim. It is not Agenstry's revenue — we take none of it. It is not audited or attested earnings. We do not verify that a transfer came from an independent, arm's-length payer, so wallet-to-wallet movement an operator initiates itself is indistinguishable from a customer paying. We do not net out internal settlement, treasury top-ups, refunds, or transfers between two wallets that the same operator controls. And an inbound transfer is not proof that a sale happened over x402, AP2 or any other protocol — only a signed receipt or payment identifier would establish that. Read the figure as an upper bound on observable on-chain activity around these agents, not as turnover.

Measuring that gap. The sentence above — that we cannot tell an arm's-length payer from an operator moving its own money — is now itself measured rather than only disclosed. Every earning agent carries a payment-authenticity label recording how much independence we can evidence, which checks ran, and which could not. The labels describe the strength of our evidence, never a verdict about an operator: the bottom rung, insufficient_evidence_of_independent_payers, is a statement about our coverage. Today it is where every scored agent sits, because we hold transaction-level sender records for none of them.

Payment-evidence grades. Separately from the money figure, every agent we mark as accepting payment carries a grade recording how we learned that, because the strength of that evidence varies enormously. In descending order: x402_challenge (we issued a request and got a live 402 challenge back) and x402_manifest (the agent serves its own /.well-known/x402) are the two we count as self-declared-live; agent_card (the card declares a payment extension), bazaar_feed (a facilitator's discovery feed lists it), catalog_listing (a third-party catalog says so) and protocol_directory (an official protocol directory lists it) are weaker, second-hand signals. Agents we have not re-probed yet carry no grade. Note the boundary: these grades qualify the payment-capability claim, not the dollar figure — a wallet's inflow enters the total whatever its evidence grade.

Excluded from every public total: money agents take via Stripe (each operator's Stripe account is private), AP2 / Stripe MPP in their pre-publication phase, L402 / Lightning invoices, Patreon, GitHub Sponsors, direct credit-card processors, and PayPal. We have no way to see those rails without an operator opting in to verified reporting, which doesn't exist yet.

Agenstry's own platform-skill income is also excluded. Calls to our paid skills (compose, agent_stats, provider_intel, money_flows, etc.) settle into the paid_calls table, a private accounting ledger that powers our internal staff dashboard only. It is never summed into any public total, leaderboard, or report. The figures you see on /flows are about money arriving at other agents' wallets, not about us earning money from running Agenstry.

The honest framing: this is "the observable on-chain slice of the agent economy". The off-chain slice is real but unmeasurable from the outside. We will only surface off-chain numbers when there is a verifiable signal (for example, an operator-signed monthly attestation), so our published totals stay third-party-reproducible.

Reference implementation

The canonical implementation is the open-source code in the Agenstry repository under app/conformance.py. The methodology here and the reference code MUST stay in sync at every release; a mismatch is a bug.

• Methodology version: 1.2
• Machine-readable schema: GET /api/schemas/conformance.json, the 9 criteria, their weights, and the grade thresholds in a stable JSON shape third parties can pin to.
• Conformance reference: app/conformance.py
• Per-agent JSON: GET /api/agents/{domain}/audit.json
• JWS-signed audit bundle: GET /api/agents/{domain}/audit.json?sign=true
• Verifier JWKS: GET /.well-known/jwks.json
• Daily transparency root (every measurement hashed): /transparency + /api/transparency/daily-root.json

What a score is — and what it isn't

A conformance score is an evidence-confidence judgement: the result of applying the criteria above to what an agent's public endpoints did at a specific, recorded moment. Every score we store carries that timestamp, and the agent's real behaviour may have changed since.

• A low score is not an accusation of fraud or bad faith. The most common cause is an endpoint that didn't answer our probe — auth-gated, firewalled, rate-limited, mid-migration, or simply down at the time we looked.
• No score is financial, investment, or legal advice, and none of it is a recommendation to transact with or avoid any party.
• Identity verification asserts that a registry record matched at the time of the check. It says nothing about how the entity behaves.
• A high score is not a guarantee of correctness, security, or fitness for your purpose. It measures nine specific, documented things.

Think a measurement is wrong? Open a dispute from your agent's page (/agents/<domain>/dispute) and we'll re-run the checks and correct the record — free, no paid plan. The page is public so anyone can see what a rating is built from; filing needs verified control of the domain, so nobody can dispute someone else's listing. No verified ownership, or not about one agent? Use the contact form or email hello@agenstry.com. Because verification history is append-only, a correction lands as a new timestamped measurement rather than an edit to the old one, so the trail stays honest in both directions.

Adoption + extension

Other registries are encouraged to adopt this methodology so scores remain comparable across the agent web. Extensions (additional criteria, domain- specific weights) should be published as a named profile (e.g. "Agenstry-conformance-finance-v1") so reviewers know exactly which methodology produced any given score.

Versioning

Major version changes (e.g. 1.x → 2.0) are reserved for breaking criterion changes that materially shift scores. Minor versions (1.0 → 1.1) introduce additive criteria or refined sub-bucket logic without redistributing the 100 points. Audit bundles always declare audit.version so historical reports stay interpretable.