Settlement finality (DIM-01) on test networks: named-rail findings

Version 1.0, for the confirmatory run of 2026-10-27 to 2026-10-28.

What this page is

This page reports settlement finality (the PayBench dimension DIM-01) for five named payment rails on test networks: the time from a paying client's initial request to the client's own evidence that the payment was final at that rail's own reliance level. Everyday AI Ltd made every payment measured, with its own test funds, and was itself both the payer and the payee of every one.

Provenance

The method and its analysis plan were frozen and externally anchored after declared exploratory runs and before the confirmatory run, and before publication of any result. The design was revised across several rounds of review with the exploratory data in view, as the pre-registration's revision history records; no exploratory data enters any figure on this page. The figures below are the output of the frozen analysis tool for the confirmatory run, rounded and nothing else.

The data pre-registration is the signed git tag paybench-dim1-testnet-prereg-v1 in the public payhelm repository (https://github.com/agentic-paybench/payhelm/blob/paybench-dim1-testnet-prereg-v1/paybench/methodology/dim1-testnet-PRE-REGISTRATION.md), registered on the Open Science Framework with digital object identifier 10.17605/OSF.IO/UETFW, its manifest anchored by an OpenTimestamps proof in Bitcoin blocks 971501 and 971504 and by Rekor transparency-log entry 3259214273. It builds on the settlement-finality methodology frozen at version 1.2 (OSF digital object identifier 10.17605/OSF.IO/XGFUJ; signed tag paybench-prereg-v1.2) and changes nothing in it.

Addendum 1 to the pre-registration, dated 2026-10-29 and written after the confirmatory run and before publication of any result, corrects one fact. The pre-registration describes the T1 vantage as in England, United Kingdom, and both vantages as in Europe; the T1 host's network path originates in South Africa, and the description was wrong when the document was frozen. No host, configuration or procedure changed between the freeze and the run, and the measurement protocol, the analysis plan and every anchored file are unchanged: one vantage measured from Africa and one from Europe. The addendum is at https://github.com/agentic-paybench/payhelm/blob/paybench/dim1-testnet-frozen/paybench/methodology/dim1-testnet-PRE-REGISTRATION-ADDENDUM-1.md, and the OSF registration carries a versioned update of 2026-10-29 giving the same correction.

Scope of the measurement

Every payment was made on a test network with tokens that carry no monetary value. No funds moved on any production network, and no other party's payments were observed. The figures describe five pinned test deployments and service paths, not the rails in production, and they say nothing about any production network's finality.

Test-only components sit inside the measurement, and every figure includes their behaviour: on Machine Payments Protocol on Lightning (Spark regtest), Spark's hosted regtest operators, with simulated Lightning routing; on Machine Payments Protocol on Tempo (Moderato testnet), the Stripe-mediated acceptance leg that production may use is not exercised at all; on x402 on Base (Sepolia), the x402 facilitator is the firm's own in-process component; on x402 on Solana (devnet, Alpenglow), the x402.org facilitator as it runs against devnet; on x402 on Stellar (testnet), the OpenZeppelin testnet facilitator.

Solana devnet runs the Alpenglow consensus, under which there is no 32-slot rooting, while Solana mainnet ran, as of the freeze date, the consensus for which the frozen method's reliance level for that rail was written. The figures for x402 on Solana (devnet, Alpenglow) are therefore not representative of Solana mainnet finality, and that rail is not raced (see Diagnostic, not raced, below).

Measurement window: 2026-10-27 06:10 UTC to 2026-10-28 07:13 UTC, in four blocks, two at each vantage. T1 is a self-hosted machine whose network path originates in South Africa; T2 is a Hetzner Cloud machine in Germany. Both ran the same harness from the same frozen file set.

What was measured

• Primary interval: from the client's initial unpaid request, the request that draws the HTTP 402 payment challenge, to the client's own evidence that the payment reached the rail's pinned reliance level. It deliberately includes the rail's protocol and HTTP exchange as well as settlement.
• Companion interval: from the pay command, the client's commitment of value, to the same end. It is the starting point the authorization-latency measurement (DIM-02) uses.
• Warm-only cut: the scored payments. Cold-inclusive cut: the scored payments together with each runner's warm-up payments at the start of each block.
• pass@k: the share of payments that reached final within k seconds, on the pre-registered grid of 2, 3, 5, 10, 15 and 20 seconds.
• Censored: a payment with no client evidence of the pinned level within 120 seconds of its initial request, or rejected without such evidence, or failed. It stays in the denominator of pass@k as not final at any k, is right-censored at 120 seconds in the percentiles, and is never dropped.
• Races: the four raced rails were measured in pairs. In each trial both rails of a pair executed the same payment scenario at the same moment on a seeded schedule; each of the six pairs ran 500 races, 125 in each block. x402 on Solana (devnet, Alpenglow) was measured alone, on 2,000 solo slots interleaved into the same schedule, and is in no race.

"Final" is defined per rail by each rail's own reliance level, so the figures are not like-for-like security objects:

• Machine Payments Protocol on Lightning (Spark regtest): preimage release.
• Machine Payments Protocol on Tempo (Moderato testnet): Simplex BFT block finality.
• x402 on Base (Sepolia): soft finality, one Base block.
• x402 on Solana (devnet, Alpenglow): commitment finalized as devnet reports it.
• x402 on Stellar (testnet): ledger close.

The per-rail figures permit a reader to derive an ordering of their own. Any such ordering is invalid, because each rail's "final" is a different reliance level, and the frozen method's deferral of rail-by-rail scoring applies to it in full.

Reading the tables

• Rail is the rail's pinned display name, carrying its test network, so no figure can be read as a production network's. R-number is the project's internal identifier for the same rail, carried for reference only; it is not the sort key.
• A pass@k cell gives the share, then two 95 percent intervals, lower bound first: the Wilson score interval, and the robust interval, a block bootstrap that resamples runs of 10, 20 and 50 consecutive scheduled payments and keeps the widest of the three. The interval written first is the one the method leads with: the robust interval wherever consecutive payments are correlated (the dependence flag), otherwise the wider of the two, as the frozen tool marks it.
• P50, P95 and P99 are censoring-aware (Kaplan-Meier, censored at 120 seconds); "not reached" means the percentile falls among the censored payments. The percentiles of the observed payments alone are shown beside them.
• The log-normal median and scale are fitted by censored likelihood, with a 95 percent block-bootstrap interval; the fit to the observed payments alone is shown beside it as a bracket, never as a substitute.
• For the cold-inclusive cut the frozen tool computed no bootstrap, so those cells read "not computed by the tool for this cut"; nothing was recomputed to fill them.
• Flags the method sets are findings about the measurement, not about any rail: every rail carries the vantage-heterogeneity flag, so the per-vantage tables come before the pooled ones; Machine Payments Protocol on Lightning (Spark regtest) carries the dependence flag, set at T2, which also governs its pooled cuts; x402 on Stellar (testnet) carries the block-heterogeneity flag at T1, its two T1 blocks differing beyond the pre-registered test; no rail carries the opponent-dependence flag.
• Every figure is copied from the output of the frozen analysis tool, rounded only: pass@k to three decimals, seconds to two, the log-normal scale to three.

Results: the four raced rails

Vantage T1, warm-only primary interval (750 scored payments per rail)

Vantage T2, warm-only primary interval (750 scored payments per rail)

Pooled across both vantages, warm-only primary interval (1,500 scored payments per rail)

Pooled, cold-inclusive cut (scored and warm-up payments)

Pooled, companion interval (pay command to the same end), warm-only

Assurance and censoring, pooled warm-only

P(settled given accept) is the share of observed payments that a later re-read of each rail, made no sooner than two hours after each block, confirmed settled. A payment censored by the client but found settled on chain stays censored, because the paying client was told it had not completed.

Races realised

Unpaired payments: zero on every rail. Voided trials: zero. Runner restarts: zero in every block on every rail. No block ended early.

Diagnostic, not raced

x402 on Solana (devnet, Alpenglow). Measured on the same protocol, but each payment was made alone, without a co-scheduled opponent, so these figures are not load-comparable to the raced table. Its 2,000 solo payments (500, 500, 500, 500 in the four blocks) are reported here, never in the raced tables, and no race statistic includes them.

Diagnostic, not raced: counts, percentiles and log-normal fit, by cut

Diagnostic, not raced: pass@k, by cut

Diagnostic, not raced: assurance and censoring, pooled warm-only

The named disconfirmer, tested

The pre-registration names, before the run, a result that would count against a single-number reading of any rail's finality. Its words: "If the per-rail pass@k curves of two rails cross between the warm-only and cold-inclusive cuts, between the two vantages, or between the software-version strata of section 6.7, the single-number reading of either rail's finality is not supported and the report says so."

Applied to the tool's pass@k figures on the frozen grid (2, 3, 5, 10, 15, 20 s). A pair "crosses" between two cuts when, at some k, the two rails' pass@k stand in one relation in the first cut and the opposite relation in the second (equal values are not a crossing). Which rail of a pair has the larger share is not stated here, for any pair.

• Warm-only against cold-inclusive: no pair crosses (raced rails, and pairs including x402 on Solana).
• Software-version strata: none exist (one x402 on Solana version throughout; no other rail records one), so this limb cannot fire.
• T1 against T2, on the point estimates: three pairs of raced rails cross: Machine Payments Protocol on Tempo with x402 on Base, at k = 2 s; Machine Payments Protocol on Tempo with x402 on Stellar, at k = 20 s; Machine Payments Protocol on Lightning with x402 on Stellar, at k = 20 s. Two pairs including x402 on Solana cross: Machine Payments Protocol on Lightning with x402 on Solana, at k = 10 s; x402 on Solana with x402 on Stellar, at k = 15 s.
• T1 against T2, on the intervals (a crossing counted only where the two rails' intervals do not overlap at either vantage): none of the three raced pairs crosses (in each, the intervals overlap at one vantage at least, on Wilson and on the robust interval alike); both pairs including x402 on Solana still cross (the intervals separate at both vantages, on both interval types).

Result: the clause as written is read on the point estimates with every rail counted. The named disconfirmer fires between the vantages: the single-number reading of finality is not supported for any of the five rails. Robustness reading, not the clause as written: counting a crossing only where the two rails' intervals separate at both vantages and excluding x402 on Solana as not load-comparable, the disconfirmer does not fire; shown for context, it does not govern. Two further facts a reader should weigh regardless of the reading: finality is strongly vantage-dependent at short k for the raced rails even where no crossing fires (the per-vantage tables above lead for that reason), and the k = 20 s crossings are near-ceiling differences of 0.001 to 0.009 in pass@k.

Disclosures

• The T1 host ran with 16 GB of memory against the 8 GB its pre-registered host pin states; the harness has no memory-dependent behaviour, and the core count and processor were as pinned.
• Every block was launched by hand and then ran unattended.
• During both T1 blocks every interactive session on the T1 host was idle or offline and one scheduled background task was paused; one trivial scheduled check ran throughout; the per-trial host-load readings are in the records either way.
• Only x402 on Solana records a network software version: every observed payment recorded solana-core 4.4.0-beta.1 (1,817 of 1,817); censored payments record none because the version is read after finality. No version changed, so no software-version strata exist.
• On x402 on Base (Sepolia) the firm's own seller account pays each payment's network fee in Base Sepolia test ether; its balance went from 0.010034 on the morning of 2026-10-27 to 0.008862 before the last block, and no funds stop occurred.
• No pause, settle stop, funds stop, runner restart, void, unpaired payment or early end occurred in any block, and no payment's runner started more than 5 seconds after dispatch (the largest gap was 4.7 milliseconds).
• One cosmetic fix outside the frozen file set was made before the run: a doubled host name in a log line of the T2 launch script.
• On x402 on Solana (devnet, Alpenglow), 193 of 2,000 scored payments are censored: the firm's own test traffic met a rate limit, and 189 of the 193 have a settled transaction behind the x402.org facilitator's HTTP 429 responses. The paying client was told those payments had not completed, so they stay censored, as the method requires. The pre-registration predicted that the spacing of these payments would not trip that limit; the prediction did not hold.

The withheld file

The frozen method computes Bradley-Terry strengths and a pairwise win matrix over the four raced rails. They are computed because the method requires it and are not published: they are written to a file headed WITHHELD, kept only in a private repository, and its existence is disclosed here. Its SHA-256 hash, 27034346e8841a9cc74443be1866b2d253c8b4cb9b9ef9c15d7f5aa9b6195651, was anchored after the analysis ran and before any publication, by an OpenTimestamps proof attested in Bitcoin block 973658 and by a Sigstore signature recorded as Rekor transparency-log entry 3560518693, to show that the computation was done and that the file has not changed since. It is released only if the firm reopens its section 21 Level 2 decision by a recorded ruling.

What this run does not say

• No rail is ranked, and no recommendation is made.
• No mainnet measurement was made, and nothing here states any production network's finality.
• The pooled figures mix two hosts, two hardware generations and two networks; the per-vantage figures are where a single-host reading lives.
• The pre-registration makes no commitment to publish and no commitment to any display beyond these per-rail quantities. The further diagnostics it lists (sensitivity cuts, probe floors, timing distributions and the rest) are in the firm's analysis record and are not reproduced on this page.

Corrections and right of reply

Any operator of a rail or facilitator named on this page may respond through the structured right-of-reply channel at https://reply.agentic-paybench.dev/. Replies about a factual data error, a methodology defect, a mischaracterisation, a confidentiality objection, or a jurisdictional objection are reviewed before publication; replies about methodology framing, a change since the measurement window, or the scope of the environment tested are published promptly with a badge saying the review is pending. The response cap and visibility policy is linked from that page. Corrections to anything here are also welcome by email at mblake@everydayai.link.

Version 1.0, for the confirmatory run of 2026-10-27 to 2026-10-28. This artefact is frozen per dated run: a correction or a re-measurement is published as a new dated version and this one is kept. It is served on the oracle site only while the ADR-009 display gate G_S21 is open, and its publication carries an audit record.