]> Everyday AI Ltd

mblake@everydayai.link

Operations and Management benchmarking measurement methodology payment autonomous agents settlement finality authorization latency Agent-initiated payments now execute across several settlement rails with materially different finality semantics, authorization primitives and failure modes. Published comparisons of these rails are commonly self-asserted, and commonly do not state a procedure another party could reproduce. This document specifies a measurement methodology for such rails. It defines finality per rail at its ecosystem-canonical reliance level rather than imposing a single definition, separates payment-validation latency from challenge-issuance latency as distinct and non-comparable quantities, and specifies an out-of-path observation posture in which the measuring party never holds funds, keys or signing authority. It states reporting requirements, including mandatory disclosure of limitations and a prohibition on merging observer-clock and payer-clock measurements. It defines no payment protocol and recommends no rail.

Introduction Software agents increasingly initiate payments without a human in the loop, over a growing set of settlement rails. Those rails differ from one another in ways that make naive comparison actively misleading: they reach irreversibility through different mechanisms and at different points, they expose different kinds of pre-settlement decision, and some complete an authorization entirely within the calling process while others cannot answer without a network round-trip to a backing service. Comparisons of these rails are nonetheless already being published. In those the author has examined, the comparison is self-asserted, the measurement procedure is not stated in enough detail to reproduce, the definition of the quantity being compared is either absent or silently different per rail, and no record exists showing that the analysis was fixed before the numbers were seen. No systematic survey is offered here, and the claim is not made of publications the author has not read. This document specifies a measurement methodology intended to make such comparisons reproducible and falsifiable. It follows the pattern established for benchmarking methodology work in : define the terms, define the system under test, define the procedure, and define what MUST be reported. The methodology has three properties that distinguish it from a straightforward port of network benchmarking practice to payments. First, it refuses to impose a single cross-rail definition of settlement finality, and instead measures each rail at its own ecosystem-canonical reliance level while recording that level as data (). Second, it treats the pre-settlement authorization step not as one quantity but as at least two quantities of different kinds, which MUST NOT be raced against each other (). Third, it specifies an observation posture in which the measuring party sits outside the payment path entirely, holding no funds, no keys and no signing authority, and it requires that this property be enforced mechanically rather than asserted ().

Relationship to other work Several contemporaneous Internet-Drafts address agent-initiated payments at the protocol layer. defines a "Payment" HTTP authentication scheme over the 402 status code of . defines a contract and escrow layer for autonomous agent commerce, with bonded optimistic settlement and graded verification of delivered work. Neither specifies a measurement methodology, and this document does not compete with either: it measures rails, including rails that implement such protocols, and it defines no protocol of its own. defines a benchmarking methodology for AI agents performing network operations tasks. This document addresses a different system under test, and adopts a comparable document structure. discusses considerations for performing measurement on the Internet safely; those considerations apply to any deployment of this methodology that observes traffic other than the measuring party's own.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Agent:

A software process that initiates a payment without a human acting on the specific transaction.

Rail:

A payment mechanism considered end to end, comprising a protocol and the settlement system beneath it. Two deployments of the same protocol over different settlement systems are different rails for the purposes of this document.

Reliance level:

The point at which a participant in a given rail treats a payment as sufficiently irreversible to act upon. Reliance levels are rail-specific and are defined in .

Finality class:

A grouping of reliance levels that are of comparable trust character, used to record whether two rails' finality points are of the same kind.

Authorization primitive:

A protocol operation that returns either a decision about whether a payment may proceed or a payable challenge, prior to and distinct from settlement.

Payment-validation primitive:

An authorization primitive that evaluates something the payer has already submitted.

Challenge-issuance primitive:

An authorization primitive in which the payee issues a payable challenge before the payer has committed anything.

In-path measurement:

Measurement performed by a party that operates a leg of the payment flow, and which is therefore capable of affecting the payment it measures.

Out-of-path measurement:

Measurement performed by a party that holds no funds, no keys and no signing authority for the payment, and which is therefore incapable of affecting it.

Payer clock:

A time base anchored at an event the payer itself performed.

Observer clock:

A time base anchored at the moment an observing process first saw a third-party event.

Work class:

A classification of an authorization primitive by whether its critical path contains an intrinsic network round-trip to a backing service. See .

Topology:

The network vantage from which a measurement was taken, including the measuring host's location and its route to the rail's backing services.

Scope and Non-Goals This document specifies how to measure. It does not publish measurements. The following are explicit non-goals, stated normatively because the value of the methodology depends on them:

• This document defines no payment protocol, no wire format, and no message.
• This document publishes no measurement result for any named rail, and implementations of this methodology are not required to publish results in order to conform to it.
• This document does not rank any rail, and specifies no procedure by which a single overall ordering across all measured rails could be produced. explains why such an ordering is not a well-formed output of this methodology.
• This document recommends no rail for any purpose, and provides no means by which a reader could transact over any rail described in it.

No rail is named anywhere in this document. Definitions are stated in terms of mechanism, so that they apply to rails this document does not discuss and to rails that did not exist when it was written.

System Under Test The system under test (SUT) is a rail, exercised through one client implementation, from one topology, under one workload. A measurement is taken against a single SUT. A comparison between rails is therefore taken across a set of SUTs, and for a network-dependent primitive that set MUST span at least two network-distinct topologies (). Narrowing the SUT to one topology and requiring a comparison to span several are the same requirement seen from two ends: the narrow unit is what makes the disclosure honest, and the spanning set is what makes the comparison valid. This framing is deliberately narrow, because the common error in this space is to report a property of one client, one host or one network vantage as though it were a property of the rail. A conforming measurement therefore treats the following as part of the SUT and MUST disclose each of them:

• the rail, identified by protocol and settlement system;
• the client implementation and version used to exercise it;
• the topology ();
• the workload constants, including payload sizes and any credential or caveat counts that vary the work performed;
• the deployment assumption for any component that could plausibly be deployed either in-process or as a separate service, since the two differ by at least one inter-process hop.

Where a rail exposes a configurable cache or time-to-live that changes whether a call reaches a backing service, that configuration is a property of the deployment and not a property of the rail. It MUST be reported as a disclosed configuration, with the request inter-arrival distribution that produced the observed hit rate, and it MUST NOT be used to place the rail in a different work class ().

Reliance Levels and Finality Classes

The problem with a single definition of final Settlement finality is not one quantity across rails. Each rail's ecosystem has a point at which participants conventionally treat a payment as good, and those points differ in kind: a number of block confirmations on one rail, a ledger close on another, a named commitment state on a third, a consensus decision on a fourth, the release of a cryptographic preimage on a fifth. Imposing a single definition across such rails produces one of two failures. Choosing the strictest available definition measures rails against a bar that their own ecosystems do not use, and produces numbers that no participant acts on. Choosing a uniform nominal definition, such as a fixed number of confirmations, silently measures different trust properties on different rails while presenting them as the same quantity.

The requirement A conforming measurement MUST define finality per rail at the reliance level that rail's ecosystem canonically uses, and MUST record that reliance level as data accompanying every measurement. Each recorded reliance level MUST carry a finality class, which states the trust character of that reliance point. The finality class exists so that a reader can determine whether two rails' finality points are equivalent in kind before comparing their durations. A conforming measurement MUST NOT present durations measured at reliance levels of different finality classes as a single ordered comparison without simultaneously presenting the finality classes. The classes are not a footnote to the comparison; they are a precondition for reading it. A reliance level that is weaker than economic finality MUST be labelled as such in the recorded data. Where a rail's canonical reliance point is a soft commitment that a subsequent reorganisation could in principle undo, the record MUST say so, and MUST NOT describe the measurement as economic finality.

Authorization Primitives and the Required Split

Authorization is not one thing Rails expose a decision point before settlement at which the rail indicates that a payment may proceed. It is tempting to treat that point as one comparable quantity across rails, and to race rails against each other on the time taken to reach it. That treatment is a category error, and this section specifies the fix. The decision points divide into at least two kinds:

Payment-validation:

The payer has already submitted something, and the rail evaluates it. The question answered is "is this payment valid?".

Challenge-issuance:

The payer has committed nothing, and the payee issues a payable challenge. The question answered is "what should be paid?".

These are different protocol steps in a different order, not two speeds of the same step. That authorization is separable from settlement is long established in card-network practice, where authorization messages are distinct from the later clearing and settlement messages . That precedent supports the separability this document relies on throughout; it does not itself draw the distinction between validation and issuance, which rests on the order-of-operations argument above and not on any prior standard.

The requirement A conforming measurement MUST determine, for each rail, which authorization primitives that rail actually exposes, and MUST measure the rail on each primitive it exposes. Measurements of a payment-validation primitive and measurements of a challenge-issuance primitive MUST be reported as separate quantities and MUST NOT be combined into a single comparison, ordering or score. A rail that exposes only one of the two primitives is measured only on that one. Its absence from the other comparison is not a deficiency of the rail and MUST NOT be reported as one. A rail that exposes both is measured on both, and yields two independent quantities that are not commensurable with each other. The two kinds named here are the minimum, not the whole. Where a rail exposes an authorization primitive of some further kind, that kind MUST be measured and reported separately under a name of its own, and MUST NOT be combined with either of the two named here. The requirement is that primitives of different kinds are never raced; the enumeration of kinds is expected to grow. Attaching a label to a mixed comparison is not a conforming alternative to splitting it. A label names a category error without removing it: the underlying model of a single ordered comparison still asserts that the items differ in degree along one axis when they differ in kind.

Where an authorization primitive cannot be separated from settlement On some rails, paying is settling: the act that would signal acceptance is the same act that achieves finality. On such a rail there is no pre-settlement validation decision to measure, and a conforming measurement MUST NOT synthesise one by relabelling a settlement event as an authorization event. Such a rail is measured on the challenge-issuance primitive it does expose, and on settlement finality (), and it does not appear in the payment-validation comparison at all.

Terminology honesty No rail known to the author publishes a metric under the name used in this section. Rails name these operations in their own terms. The framing in this document is therefore an analytical framing imposed over primitives that the rails do publish, and a conforming measurement SHOULD say so plainly rather than implying that it reports a figure the rail itself defines. The separability of authorization from settlement is nonetheless genuine and observable on each rail that exposes both.

Work Classes, Grouping and Decomposition

Why a single ordering is not a well-formed output Within a single authorization comparison, rails may differ enormously in the work their primitive performs. Some complete the primitive without any network round-trip: the critical path is local computation, typically signature verification. Others cannot answer without at least one intrinsic round-trip to a backing service. When the spread between these classes is large relative to the spread within them, a single ordering across both encodes class membership rather than rail quality. The resulting table looks like a ranking and functions as a restatement of which rails do local work.

The requirement A conforming measurement MUST classify each measured primitive into a work class:

Local-complete:

No network round-trip to a backing service lies on the critical path of the primitive.

Network-dependent:

At least one intrinsic backing-service round-trip lies on the critical path of each call.

Comparisons MUST be made within a work class. A conforming measurement MUST NOT produce a single ordinal comparison spanning both work classes. Where a cross-class statement is needed, it MUST be made through the decomposition tuple defined below, and not through an ordering.

The decomposition tuple For each measured rail, a conforming measurement MUST report the tuple:

• the local compute floor, being the portion of the measurement attributable to computation performed by the measuring party;
• the backing-service component, being the portion attributable to round-trips to services the rail depends on;
• the end-to-end duration.

The end-to-end duration is the headline figure. A conforming measurement MUST NOT subtract the backing-service component from the end-to-end figure, because the round-trip to a backing service is part of the authorization work the rail performs, not overhead added by measurement. The decomposition is a secondary, protocol-design view, published alongside the headline and never in place of it.

Topology requirements A single topology measures the measurement harness as much as it measures the rail. Accordingly:

• A conforming comparison involving a network-dependent primitive MUST draw on measurements from at least two network-distinct topologies. Each such measurement is a separate system under test (); the requirement is on the comparison, not on any single measurement.
• Each reported figure MUST carry the topology it was taken from, and MUST carry the minimum observed round-trip floor for that topology, so that a reader can separate the rail's behaviour from the route.
• Local-complete primitives are expected to be topology-invariant. Measuring them from the same topologies provides a control: if a local-complete figure varies materially across topologies, the harness is being measured and the measurement is not yet valid.

Where a rail exposes distinct work modes within one work class, each mode is reported separately with the work it performs disclosed, and the mode representing autonomous agent operation is the one reported as that rail's headline for the agentic case.

Out-of-Path Observation This section specifies the observation posture. It is the section with the strongest requirements, because the property it describes is easy to claim and easy to lose.

Two postures A measuring party may sit in the payment path or outside it. An in-path measurer operates a leg of the flow. It may hold keys, sign, submit, or serve one side of the exchange. Such a party can measure everything, and can also, in principle, affect the payment it is measuring. Its measurements are measurements of a system that includes the measurer. An out-of-path measurer does not touch funds, keys, signing or broadcast. It learns about a payment that has already happened, either by reading a public ledger after the fact or by being told by a participant after the fact. The distinction is long established in payment messaging, where a copy of a message taken in the flow before completion is a different artefact, with different capabilities and different risk, from a copy of a settlement record taken after the fact for reporting.

The requirement A conforming out-of-path measurement MUST satisfy all of the following:

• The measuring component MUST NOT hold or have access to key material for any party to the payment.
• The measuring component MUST NOT sign, and MUST NOT construct, submit or broadcast any payment or transaction.
• The measuring component MUST use read-only interfaces to any settlement system it observes.
• The measuring component MUST NOT share code paths with any in-path component in a way that could give it signing capability. Where both an in-path harness and an out-of-path observer exist in the same project, the observer MUST NOT import the harness and the harness MUST NOT import the observer.

Mechanical enforcement An out-of-path claim that rests on a written assertion is not verifiable by a reader, and degrades silently as code changes. A conforming measurement therefore MUST enforce the properties above mechanically, in automated checks that run on every change, and MUST describe those checks in the published methodology. Suitable enforcement includes an import allowlist that excludes signing libraries and key material, a restriction to read-only remote-procedure-call methods, and a bidirectional check that the in-path and out-of-path components do not import each other. A failing enforcement check means the out-of-path claim is false for that revision, and results produced by that revision MUST NOT be published as out-of-path.

What each posture can and cannot measure An out-of-path measurer that reads a ledger after settlement cannot observe any event the payer performed privately, and in particular cannot observe the moment the payer began. It therefore cannot report any duration anchored at a payer event. An out-of-path measurer that is told about a payment by a participant after the fact can report durations anchored at that participant's own events, because the participant observed them, but only those. These limits are not deficiencies to be worked around. They are the reason the next section exists.

Clock Discipline and Incommensurability

The requirement Every reported duration MUST carry the clock it was measured on. A duration anchored at an event the reporting party itself performed is on the payer clock. A duration anchored at the moment an observing process first saw a third-party event is on the observer clock. The second includes the observer's polling interval, its network path to whatever it polls, and its own scheduling; the first does not. Measurements on different clocks MUST NOT be merged into one series, one average, or one comparison, even where they nominally describe the same transition. Where a data schema is used to record measurements, that schema SHOULD make the merge impossible to express rather than merely discouraged.

No synthesised durations Where a measuring party did not observe the start of an interval, it MUST NOT report a duration for that interval. This applies specifically to retrospective observation of a settlement record. Such a record commonly carries enough information to make a plausible duration computable by assumption. A conforming measurement MUST NOT compute it. A post-hoc observer cannot know the durations it did not observe and MUST NOT invent them, and a conforming schema MUST reject records that carry duration fields the observation mode could not have produced. A retrospective observation that yields no durations is a complete measurement of the static facts it did observe, and conforms as such. Conformance in this document is defined per observation mode: a report conforms if it satisfies every requirement applicable to the mode it declares. The requirements in that presuppose durations, or that presuppose the decomposition tuple, apply only to observation modes capable of producing them, and their absence from a retrospective observation is neither a defect nor a non-conformance. Every report MUST declare its observation mode, so that a reader can tell which requirements were in force.

Fee attribution Where a rail's design causes a network fee to be borne by a party other than the payer, a conforming measurement MUST record the fee as the fact it is and MUST NOT attribute it to a party that did not bear it.

Statistical Treatment This section states requirements on the analysis, not a mandate to use one estimator.

Comparison Where a methodology compares rails pairwise, it MUST specify the estimator in advance. The method of paired comparisons is suitable for deriving a latent comparative strength from pairwise outcomes, and where it is used, ties MUST be handled by an explicit extension rather than by discarding tied observations. Comparison MUST be confined within a work class () and within an authorization primitive kind ().

Censoring Rejections, timeouts and other non-completions MUST be treated explicitly as censored or competing outcomes. They MUST NOT be silently dropped from the sample, because dropping them biases the result toward the conditions under which a rail succeeds. Where the data violate the assumptions of the chosen pairwise model, the methodology MUST specify the fallback analysis in advance, together with the data-driven trigger conditions that select it. Selecting a fallback after seeing that it produces a more agreeable result is not conforming.

Interval reporting Point estimates MUST be accompanied by interval estimates, and the full interval MUST be reported alongside any summary figure derived from it. Where a proportion such as a success rate is reported, a score interval is suitable; the conservative bound for a success proportion is the lower bound, because it is the bound that does not flatter the measured system. Which bound is conservative depends on the quantity and on the direction in which being wrong would mislead: for a latency, the conservative bound is the upper one. A methodology MUST state which bound it treats as conservative for each reported quantity, and MUST NOT report a bound in place of the interval.

Distribution reporting For any latency-like quantity, the central tendency alone is not an adequate summary, because a rail whose behaviour depends on a network path can have a median that moves materially as the sample grows while its tail tells the stable story. A conforming measurement MUST report, for each measured rail and each measured quantity, at minimum: the median, an upper percentile, a further upper percentile characterising the tail, the sample size, the measurement timestamp, and the topology. Any threshold grid used to report the probability of completing within a bound MUST be fixed in advance and MUST NOT be refitted per run.

Pre-Registration and Reproducibility

The requirement Where a methodology will be used to produce published comparisons, the design and the analysis plan MUST be fixed before any result is generated, and the fixed form MUST be recorded in a way that a third party can verify was fixed beforehand. The record MUST identify the frozen artefacts by cryptographic digest, and MUST be committed to at least one anchor that the publishing party does not control. Reproducibility requires that any deterministic component of the methodology, including any simulation or calibration pipeline, produce identical output from identical input, and that the expected digest of that output be part of the pre-registered record. Random number generation used in such a pipeline MUST be seeded deterministically and MUST be domain-separated per measured dimension, so that adding a dimension cannot perturb an existing one.

What anchors prove, and what they do not An anchor establishes that a specific byte sequence existed at a specific time and was committed to by a specific signer. That is precedence, integrity and signer identity. An anchor does not establish that the anchored method is correct, that its results are valid, or that its author originated any cryptographic primitive it uses. Primitives such as hash functions, signature schemes and transparency logs are commodity standards used as-is. A conforming methodology SHOULD state this distinction explicitly in its own published record. Overstating what an anchor proves is a failure mode of pre-registration practice and undermines the credibility the anchor was intended to supply.

Worked example The methodology described in this document was developed alongside two pre-registered measurement dimensions whose records are public and may be inspected as an instance of the requirements above: a settlement-finality pre-registration and an authorization-latency pre-registration . Each fixes its design and analysis plan, identifies its frozen artefacts by digest, and is committed to independent anchors. They are cited here as an example of the practice; what each record does and does not contain is stated below. Competing interests. Both pre-registrations are the author's own. The author operates the measurement project from which this methodology was distilled, and the requirements stated in this document were derived from that project's two measurement dimensions, exercised to date on test networks and on traffic the project itself originated. The records contain the pre-registered designs, the digests of the frozen artefacts, and, for the authorization-latency record, a first-party test-network calibration record disclosed as pilot evidence; neither contains a result for any production rail. The author is therefore a prospective publisher under this methodology as well as its editor. Readers should weigh the requirements on their merits and against their own deployments rather than on the authority of the worked example.

Reporting Requirements A conforming report MUST include all of the following that its declared observation mode can produce. The list is normative because a comparison missing any of these items cannot be assessed by a reader; items an observation mode cannot produce are excused by that mode's declaration, never by silence.

• For each measured rail: the reliance level and finality class ().
• For each measured authorization quantity: which primitive kind it measures ().
• For each measured rail: the work class and the decomposition tuple ().
• For each reported duration: the clock it was measured on ().
• For each figure: the distribution summary, sample size, timestamp and topology required by .
• The full system-under-test disclosure required by .
• The measurement posture, in-path or out-of-path, and for an out-of-path measurement, the mechanical enforcement in place ().

Disclosure of limitations A conforming report MUST disclose known limitations of its own measurements, and MUST do so as part of the pre-registered record rather than only after results are known. This requirement exists to prevent silent caps: a limitation that is known to the measuring party, is material to interpretation, and is simply not mentioned. Limitations that MUST be disclosed where they apply include at least:

• measurement taken under load conditions unrepresentative of production, where the effect on distribution tails is expected to be material;
• measurement of a path that omits a step the production path would include;
• measurement on a test network whose production counterpart shares a design but not necessarily its empirical behaviour;
• any bound that is known to be optimistic or pessimistic rather than representative.

Where a methodology bounds its own coverage, by sampling, by capping retries, or by reporting only a subset, the bound MUST be stated. Silent truncation reads to a reader as complete coverage.

Security Considerations The methodology in this document is a measurement methodology. It issues no instruction to transact, and conformance to it requires no party to move funds. The measurements from which this methodology was derived were performed, to date, against test networks and against traffic the measuring party itself originated. A deployment that observes traffic originated by third parties raises considerations beyond the scope of this document; , an expired IRTF Internet-Draft that was never published as an RFC, discusses them. The out-of-path posture of is itself a security property, and it is the reason that section states mechanical enforcement requirements rather than descriptive ones. A measuring component that acquires signing capability, key material or the ability to broadcast has become an in-path component, whatever its documentation says, and both its risk profile and the meaning of its measurements change accordingly. An in-path measurer can affect the payments it measures. Where in-path measurement is used, the report MUST disclose it (), so that a reader can account for the measurer being part of the measured system. Publishing comparative measurements of named third-party systems has consequences for those systems. A publisher SHOULD provide a means by which an operator of a measured system can respond to a published measurement, and SHOULD publish the criteria and procedure in advance of the measurements, so that the procedure cannot be adjusted in response to a particular result.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Independent Existing agent interoperability protocols move tasks (A2A) and money (x402, AP2) but provide no mechanism that binds work to payment to proof of completion. This document specifies PACT (Propose, Agree, Complete, Trust), an application-layer contract protocol for commerce between autonomous agents. PACT defines (1) a sealed-bid second- price task-award procedure; (2) the Verifiable Task Contract (VTC), a signed JSON object binding parties, scope, price, verification method, and liability; (3) escrowed, optimistically released settlement with a fraud-proof challenge window; (4) graded verification methods ranging from deterministic re-execution to zero- knowledge proofs of inference and staked arbitration; and (5) co- signed Work Attestations from which agent reputation is derived as a byproduct of settlement. PACT composes existing primitives: Decentralized Identifiers, JSON Web Signatures, OAuth token-exchange delegation chains, the x402 payment protocol, and AP2 mandates. Tempo Labs Tempo Labs Tempo Labs Stripe Stripe This document defines the "Payment" HTTP authentication scheme, enabling HTTP resources to require a payment challenge to be fulfilled before access. The scheme extends HTTP Authentication, using the HTTP 402 "Payment Required" status code. The protocol is payment-method agnostic, supporting any payment network or currency through registered payment method identifiers. Specific payment methods are defined in separate payment method specifications. Telefonica This document defines a benchmarking methodology for evaluating Artificial Intelligence (AI) agents performing network operations tasks such as configuration, troubleshooting, and optimization. This document focuses on task-oriented performance metrics, including task completion success, execution efficiency, and robustness across multi-step workflows, proposing benchmarking practices towards agent- based, closed-loop network operation scenarios. The proposed methodology aims to provide a reproducible and vendor- independent framework to compare AI agent effectiveness in controlled network environments. SR2 Communications internet Research Lab Internet measurement is important to researchers from industry, academia and civil society. While measurement of the internet can give insight into the functioning and usage of the Internet, it can present risks to user privacy. This document describes briefly those risks. It also outlines considerations for researchers to reference when designing internet measurements to ensuring that those measurements can be carried out with user safety as a priority. International Organization for Standardization

Open Issues for -01 This revision is published with three known structural gaps. They are recorded here rather than left for a reader to find, and they are the stated agenda for the next revision. None of them is a wording problem, and none is fixed by this revision. 1. The finality definition is not operational. places requirements on the "ecosystem-canonical reliance level", on the "finality class" and on what may be called economic finality, but supplies no decision procedure, no enumeration of classes and no membership test. A measuring party can therefore select the reliance level that flatters a rail and assert that it is canonical; two conforming measurements of the same rail may legitimately disagree; and the gate on cross-class comparison is, as written, discretionary. Direction for -01: an initial finality-class taxonomy along the axes this document already gestures at, together with a rule that the chosen reliance level and the evidence for its canonicality are fixed in the pre-registered record, and a requirement to measure at more than one reliance level where canonicality is contested. 2. The distinguished posture cannot produce the flagship quantity, and the tuple concedes the ordering. makes out-of-path observation the distinguished posture; forbids reporting any duration whose start the measurer did not observe; and concedes that a ledger reader never observes the payer's start. A purely out-of-path observer therefore reports no authorization-latency durations at all, and the only route to them is participant reporting, on which this revision places no provenance, attestation or disclosure requirement. The bidirectional import prohibition guarantees capability isolation, not evidentiary independence. Separately, the end-to-end figure in the decomposition tuple of yields data from which a reader may derive a cross-class comparison that does not permit the publisher to assert as a finding; the position that the tuple is data, and that a reader-derived comparison is the reader's, is stated here rather than deferred. Direction for -01: define conformance per observation mode throughout rather than in one section, add provenance and disclosure requirements for participant-reported data, carry the tuple-is-data position into the normative text rather than leaving it in this appendix, and re-scope the document's own claim so that it says plainly which quantities each posture can and cannot yield. 3. There is no measurement procedure. This document states constraints, prohibitions and reporting requirements. It does not state a procedure in the sense that benchmarking methodology documents conventionally do: instrumentation points, the start and end event for each primitive, trial counts, and the traffic pattern under which measurements are taken. Two conforming implementations could therefore measure differently and both comply. Direction for -01: a procedure section supplying those elements. One further question, raised in review and not yet resolved, is recorded without commitment: the two-clock taxonomy of has no slot for a duration anchored at consensus-attested ledger timestamps, which for some rails are the ecosystem's own canonical time base. Such a duration is anchored neither at a payer event nor at an observer's first sighting, and the prohibition on synthesised durations may therefore exclude a measurement that is better founded than one this document permits.

Acknowledgments The distinction between validation and issuance primitives was sharpened by adversarial review that refuted an earlier single-comparison design, as was the work-class grouping requirement of . The three open issues recorded above were identified by a further cross-model adversarial review of this revision, conducted before publication. The author thanks the reviewers of those rounds.