Glossary

• A
• C
• D
• E
• F
• I
• L
• N
• O
• P
• R
• S
• T

Ambiguity bound

The longest time a paying agent can be left not knowing whether its payment went through. The question asked of each rail is whether its documentation bounds that window, and where the bound lives, for example an expiry field inside the signed payment.

Authorization primitive

The step in which a rail checks a payment, or asks for one, before anything is delivered. The DIM-02 measurement times two such steps separately and never combines them: payment validation and challenge issuance.

Capability record

The set of documented facts this site holds about one rail. Each record is served as a signed credential, one per rail, listed at capabilities/index.json.

Challenge issuance

Asking a client to pay before a service is delivered. In DIM-02 this is primitive B: the emission of a payment challenge, either an HTTP 402 response or a minted invoice.

Confidence interval

A range that shows how precise a reported figure is. On the DIM-02 page the 95 percent interval is for the median, derived after the fact from the calibration parameters; it is a descriptive addition, not a pre-registered quantity.

Deterministic finality

A payment becomes final at one defined moment, after which it cannot be reverted. The methodology names deterministic close as one of the distinct finality mechanisms the rails use.

DID document

A published file that names the key this site signs with. It is served at .well-known/did.json, and a verifier reads the public key from it to check a credential's signature.

Documentation profile

A record of what each rail's own specification or operator documentation says about it, with no figure produced by making a payment. Each cell names the source it rests on and the date that source was read.

Error catalogue

A published list of the errors a paying client can receive. The question asked of each rail is whether its specification or its operator publishes one, and at what address.

Finality

The point at which a payment can no longer be reversed, so the party paid can rely on the money. The methodology defines settlement-finality as the time from submitting a payment to the moment the transfer is irreversible on the rail, at the level that rail's own documentation says a builder may rely on.

Idempotency

A retried payment does not move money twice. The question asked of each rail is whether resubmitting the identical credential, or signing a fresh one while the first is still valid, can move value twice, and which documented mechanism prevents it.

Local-complete

A rail that can make its decision without a network call on each payment. In DIM-02 a local-complete rail does no per-call network round trip in steady state, and its figures are comparable only with other local-complete figures.

Lognormal parameters

Two numbers that describe the typical value and the spread of a set of timings skewed towards slow outliers. DIM-02 records them per rail from calibration and uses them only to derive the descriptive interval shown beside each median.

Network-dependent

A rail that must make a network call for each payment. In DIM-02 a network-dependent rail makes one per-call round trip, and its figures are not comparable with local-complete figures.

Observer privacy exposure

What a party outside a payment can see about it. The record states, per the documentation, the payer identifier, the amount, any memo or metadata, and whether the payment can be linked on a public ledger.

Offline verifiability

Whether a paying agent can later establish what happened to its payment without asking anyone. The record states whether the documentation defines such an object, for example a signed receipt, who signs it, and the limits the documentation states on that check.

Outcome knowledge

How a paying agent learns whether its payment succeeded. Mediated means another party tells it; trustless means it can check for itself; mediated, then trustless means it is told first and can check on chain afterwards.

Payment validation

Checking a payment authorization and deciding to accept or decline it. In DIM-02 this is primitive A: a payment authorization presented to a verifier, up to the accept or decline decision.

Pre-registration

Publishing a method and its analysis plan in a fixed, dated form, so they cannot quietly change later. Each method here was frozen and externally anchored after its pilot and calibration runs and before any confirmatory run or any published result.

Probabilistic finality

A payment becomes harder to reverse as more blocks are built on top of it, so certainty grows over time rather than arriving at one moment. The methodology names probabilistic rooting as one of the distinct finality mechanisms the rails use.

Provenance label

A tag on each cell saying where its content comes from. The label is one of three, documentation-derived, measured or void, and no documented cell on this site carries the label measured.

Rate limit

A cap on how often a service can be called. The record states only whether the operator's documentation declares such limits on the path a payment uses: a declaration, never a measurement.

Restitution

Getting value back after a payment, or stopping one before it settles. The record lists each kind the documentation describes (a refund, a dispute, or the cancellation of an authorization not yet settled), with who starts it and who bears its fee.

Signed credential

A record whose contents are signed, so anyone can check that it has not been altered and who issued it. Each capability record is a W3C Verifiable Credential signed with ES256 over P-256, checkable offline against the published key.

Specification pin

The exact documents, versions and dates that define a rail's payment flow. Each record names them so a reader knows which text was read; it is metadata, not a score.

Tier-1

Facts that are measured. A dimension measured by a method that was frozen and anchored before publication, shown with confidence intervals and without ordering by result.

Tier-2

Facts that are documented. What each rail states about itself in its specification or its operator's documentation, every cell naming its source and the date it was read.

Tier-3

Directions that are declared. Plans stated on the roadmap, none of them measured.