Methodology: Rail Readiness Levels (RRL)

Version 1.0 · 2026-10-25

This page explains how we assign an RRL level to each listing in the directory. RRL measures how much public, verifiable evidence exists that an organization operates a payment rail for agents. It does not measure quality, security or reputation.

Listings are published in Spanish. On each listing, the seal reads “Pagado por Lupa” and health reads Operativo, Degradado, Caído or Sin sondeo.

Principles

• One level per rail and per listing. The level does not belong to the organization. An organization that uses x402 and ACP has two levels, one per rail.
• Levels are earned with evidence. Only what we can observe and link counts. A seller’s own statement is not enough on its own.
• Every level shows its evidence. Each listing shows the level, a link to the evidence, the date we observed it (with Argentina time, ART, when there is a probe) and the date of the next review.
• Few levels, with rules for moving down. There are four levels, from RRL 0 to RRL 3. Each one has explicit rules for moving up and moving down.
• Health is a separate axis. A service that is down this week keeps its level until a degradation rule is met.

Two families of rails

The criteria depend on how the rail can be verified.

• Rails with 402 (x402 and MPP). The service answers an unpaid request with HTTP status 402 and a payment challenge we can read. Charges settle on a public network, so they can be verified too.
• Rails without 402 (AP2, ACP, PAP, UCP and others). There is no public 402 challenge we can probe. Evidence comes from primary sources, such as documentation from the organization or the protocol owner, and from public manifests when the rail defines one.

Rails and methods that cannot reach RRL 3 today

Some rails and payment methods do not leave a public payer we can verify. Without that evidence we cannot apply the rule of 2 payers distinct from the owner. For that reason their maximum level today is RRL 2 · Pilot:

• L402 (Lightning). The payment does not leave a payer visible on a public network.
• MPP with card. The charge is processed outside a public network.
• MPP sessions. Payments go through a payment channel and not through an individual charge we can attribute to a payer.

If any of these cases gains a verifiable public payer, we will update this page and the rule will apply the same way as for the other rails with 402.

Levels

RRL 0 · Indexed

The listing appears in a public discovery source, such as a service catalog or a third-party list, but we have not verified it yet.

• Criterion: at least one public source lists the service or the organization with the rail.
• Linked evidence: the discovery source and the date we read it.
• Moves down or out: if it does not move up within 4 weeks, the listing is archived. An archived listing is reopened if new evidence appears.

RRL 1 · Announced

The organization officially announced that it uses or will use the rail.

• Criterion, for both families: there is an announcement, documentation or specification published by the organization itself or by the protocol owner, with a date. A press article alone is not enough.
• Linked evidence: the primary source and its date.
• Moves down: if the announcement is withdrawn or denied, the listing moves down to RRL 0. If 180 days pass without new evidence, the listing stays at RRL 1 with the flag “announcement with no updates”.

RRL 2 · Pilot

The rail works, but there is not yet enough evidence of real charges.

Rails with 402

• Criterion: the endpoint returns a valid 402 in the weekly probe.
  • x402: a readable challenge with at least one payment option in accepts, stating scheme, network, asset and receiving address (payTo).
  • MPP: a WWW-Authenticate: Payment header with identifier, realm, method and intent or request.
• And one of these conditions is also true:
  • In the last 30 days there are not enough charges for RRL 3.
  • It only charges on a test network.
• Linked evidence: the probe record, with date, HTTP status and a fingerprint of the payment header.

Rails without 402

• Criterion: one of these conditions is true:
  • The organization documents a sandbox, a beta or a public integration.
  • There is a pilot with a named merchant.
  • The rail defines a public manifest and we found it, but it has validation errors.
• Linked evidence: the sandbox or pilot page, or the manifest validation result, with a date.

Moves down

• With 402: after 2 consecutive weekly probes without a valid 402, the listing moves down to RRL 1 and health becomes “Down”.
• Without 402: if the 90-day review cannot confirm the source, the listing is flagged “review overdue”. If the source no longer exists, it moves down to RRL 1.

RRL 3 · Production

The rail charges for real and there is recent evidence.

Rails with 402

• Scope: x402 and MPP with individual charges settled on a public network. The cases in the section “Rails and methods that cannot reach RRL 3 today” stay at RRL 2 at most.
• Criterion: both conditions are met:
  • The last weekly probe received a valid 402.
  • In the last 30 days we saw settled charges to the payTo declared in that 402, made by at least 2 payers distinct from the owner.
• What a payer distinct from the owner is: a wallet that paid and that is not the payTo. It also cannot be linked to the payTo by its source of funds, by transfers from the payTo to it or by amounts that go around in a circle. Links are checked with public network data, and anyone can review the linked transactions in a public explorer.
• Payments that do not count:
  • Lupa’s payments do not count toward the 2 payers. This includes verification payments and payments for the “Paid by Lupa” seal.
  • Charges on test networks do not count either.
• Linked evidence:
  • The hashes of 2 transactions from distinct payers, linked to a public explorer.
  • The record of the last probe.
• Window: the 30 days are rolling. They are recalculated in every weekly probe.

Rails without 402

• Criterion: both conditions are met:
  • The organization documents general availability (GA) of the rail.
  • At least 2 named merchants operate with the rail, each one with a public, dated source.
• If the rail defines a public manifest, the manifest must also validate without errors in the weekly probe.
• Linked evidence: the primary source for general availability, with a date, the source for each of the 2 merchants and the manifest validation result when it applies.
• The 2-payer rule does not apply: on these rails we cannot observe payments publicly. That is why their RRL 3 requires 2 named merchants and the listing says so.

Moves down

• If fewer than 2 payers distinct from the owner remain in the last 30 days, the listing moves down to RRL 2.
• After 2 consecutive weekly probes without a valid 402, it moves down to RRL 2 and health becomes “Down”. After 3 consecutive probes it moves down to RRL 1.
• If the payTo changes, the listing moves down to RRL 2 until we see 2 payers distinct from the owner paying the new address.
• Without 402: if the 90-day review does not confirm the source, the listing is flagged “review overdue”. If the organization withdraws general availability or fewer than 2 named merchants remain operating, it moves down to RRL 2.

How a listing moves up

• A listing moves up at most one level per weekly probe. The exception is a new listing, which can enter directly at the level its evidence supports.
• To move up, the evidence must be current on the day of the probe. Old evidence does not count for moving up, even if it was valid at the time.
• No listing moves up because the seller asks. The seller can send us evidence and we verify it like any other evidence.
• Before publishing a new RRL 3, we review the payers by hand. Meanwhile the listing stays at RRL 2 with the reason “pagadores en revisión manual” (payers under manual review).

Weekly probe

• Once a week we send one unpaid request to each registered endpoint with 402 and store the HTTP status, the payment header and the date.
• We never pay during the weekly probe. Verification payments are only made for the “Paid by Lupa” seal.
• In the same pass we look on the network for charges to each declared payTo in the last 30 days and count the payers distinct from the owner.
• Public manifests of rails without 402 (for example PAP or UCP) are validated in the same pass when the rail defines one.
• Primary sources for rails without 402 are reviewed every 90 days.

What is linked at each level

“Paid by Lupa” seal

The seal is not a level. It means we made a real paid call to the service and the service delivered what it promised.

• Linked evidence: the hash of our payment and the date.
• Expiry: the seal expires after 90 days. It also expires earlier if the payTo, the price or the response format changes.
• Partial measurement: for now the seal covers 48 of the 90 days. We will complete it in the coming weeks.
• Relation to the level: the seal does not raise the level. Lupa’s payments do not count toward the 2 payers distinct from the owner.

Health axis

Health is independent from the level and reflects the last probe.

• Operational: the last probe received a valid 402.
• Degraded: the last probe failed or the challenge was incomplete, but the previous probe was fine.
• Down: 2 consecutive weekly probes without a valid 402, or a rail’s first probe without a valid 402.
• Not probed: the rail has no public 402, like AP2 or ACP. The listing shows no measured health.

What RRL does not measure

• We do not probe AP2 or ACP with a 402. These rails do not expose a public 402 challenge. Their level depends on primary sources and the 90-day review.
• It does not verify payers on L402, MPP with card or MPP sessions. That is why these cases reach RRL 2 at most.
• We do not count payers on non-EVM networks (for example Solana): those rails stay at RRL 2 until there is a verifiable method.
• It does not measure quality or security. RRL 3 means there are recent real charges. It does not say the service is good, safe or cheap.
• It does not measure volume. Two payers are enough for RRL 3. The level does not compare services by sales.
• It does not guarantee that payers are independent. The distinct-payer method detects links that are visible on the network. An owner who uses wallets with no common trail can pass the filter.
• Third-party metrics. When we show a figure we did not measure, we label it with its source, for example “according to CDP”, and link it. Those figures never decide the level on their own.

Listing fields

How to report an error

If a listing has a wrong level, evidence or figure, write to us at lupa@mail.grokbot.com. Include:

• the link to the listing and the rail
• which figure is wrong
• the evidence that corrects it: a public link, a transaction hash or a dated primary source

We review every report with the same method as any other evidence. If the report is confirmed, we fix the listing and record the change with its date in the listing history.