agentic-paybench capability oracle

Published facts and measurements about the payment rails that software agents use, signed so they can be checked, with nothing on this site that tells you which rail to use.

What this is

A research data layer over agent-payment rails. For an agent developer, it is a set of signed, machine-readable records of what each rail documents about itself, plus the published method and results of one neutral measurement applied to every rail in the same way. For a payments-strategy reader looking for a neutral measurement, it is that measurement: the method is published and pre-registered, the figures carry confidence intervals, and no figure is presented as a reason to prefer a rail.

What you can read here

• Capability records, one per rail. Documented facts about each rail (who pays the network fee, how finality is modelled, retry and idempotency rules, declared rate limits, status page, error catalogue, and more), every cell naming the source it rests on and the date it was read. Read the records; the statements every record carries: tier2/statements.
• Named-rail measurements. Authorization latency: the time a rail takes to complete its authorization step, the permission part of a payment before settlement, measured the same way on every rail and shown with confidence intervals and no ordering by result. Read the measurements.
• Settlement-finality method. The frozen method, harness and calibrated fixtures for measuring when a payment becomes final. The method only; no results table. Read the method.
• Decision records. Why the oracle is intent-free, that is, why it answers questions about rails and never questions about what to do (ADR-007), and how its gates work (ADR-009). Read the decision records.
• Roadmap. Declared directions, none of them measured. Read the roadmap.

How to check it

Every capability record is a signed credential (ES256 over the P-256 curve). The signing key is published at .well-known/did.json; that document states the key's status (at present a development key, to be replaced by a hardware key at the maintainer ceremony). The credentials verify offline against the published key with the repository's own script and no key of your own; from a clone of github.com/agentic-paybench/oracle:

cd ingest/signer && npm ci && node verify.mjs

Every documented cell names its source URL and the date it was read, so a fact can be re-read at the source. One of the documented cells, offline verifiability, records whether a paying agent can confirm a payment's outcome later without asking anyone.

The measurement methods are published and pre-registered on the Open Science Framework: 10.17605/OSF.IO/XGFUJ (settlement finality, method), 10.17605/OSF.IO/UFQG5 (authorization latency) and 10.17605/OSF.IO/UETFW (settlement finality, test-network confirmatory data).

What this is not

The oracle answers "what is true about rail X", never "what should I do for this payment".

It carries no scores, no ranking and no recommendation on this surface (ADR-007, ADR-009).

The named-rail measurements at results/ are a measurement and not a recommendation; no rail is endorsed. The results page carries these statements, and they apply to everything here:

There is no route from this site to transact: nothing here takes a payment, holds funds or leads to a place that does.

A scored query, an answer that would score rails for a particular payment, exists in the code and is switched off on this site; posture.json shows the gates.

Where to go next: the research index at agentic-paybench.dev links the repositories, the measurement and the pre-registrations. Contact: everydayai.link.