A user does not experience consensus as a protocol diagram. A user experiences consensus as a wait.

They sign a transfer, press send, and wait for the application to know whether the transaction is final. Post Fiat is an L1 protocol design whose v2 native-transfer path returns finality from a certified applied batch rather than waiting on an XRPL-style validated-ledger clock.

This first latency study asks one narrow question:

After a wallet submits a native transfer, when can the client observe it as final?

Claim boundary, before the numbers

This article reports a local, one-host, six-validator, sequential native-transfer benchmark. It is not a WAN result, not a public-mainnet result, not a throughput result, and not a claim of global L1 supremacy.

Two other boundaries matter:

• Different finality surfaces. Post Fiat is measured at a certified applied-batch receipt. Private rippled is measured at XRPL validated-ledger inclusion. Those are the closest client-visible local-finality surfaces in this packet, but they are not byte-identical protocol events. No same-surface apples-to-apples comparison is available here.
• Evidence status. The evidence is self-published: public raw reports, aggregate files, command logs, lab book, methodology, charts, and SHA256 manifests are provided. The hashes bind this article to those artifacts; they do not constitute independent replication.

The claim-critical packet ran five sessions per lane and 1000 sequential signed transfers per session. The reported p99 values are empirical packet tails, not population tail guarantees.

TL;DR

In the selected local matched packet:

• Post Fiat L1 v2 full-vote certified finality measured 88.083 ms p50 and 104.705 ms p95.
• The selected reduced-timing private rippled control, close_750ms, measured 883.507 ms p50 at the XRPL validated-ledger boundary.
• Stock private rippled measured 3000.565 ms p50 at the same validated-ledger boundary.
• The aggressive close_250ms rippled stress lane reached 573.367 ms p50, but its tail expanded to 15345.814 ms p95 and 19918.846 ms p99.

The p50 gaps are 10.03x versus selected close_750ms private rippled and 34.07x versus stock private rippled, with the finality-surface boundary attached: certified applied-batch receipt versus validated-ledger inclusion. They are client-visible completion ratios, not same-phase internal consensus-speed ratios.

Quote-safe version:

In a local one-host, six-validator, sequential signed-transfer benchmark,
Post Fiat L1 v2 full-vote certified applied-batch finality measured
88.083 ms p50 and 104.705 ms p95, while private rippled validated-ledger
inclusion measured 883.507 ms p50 for the selected close_750ms profile
and 3000.565 ms p50 for stock. These are cross-surface client-visible
completion numbers, not same-phase consensus-speed ratios.

Reader path

• Result card: the measured lanes, finality surfaces, and ratios.
• Method: what was run, what was excluded, and how to audit the packet.
• XRPL timing: why validated-ledger finality naturally contains a ledger-cycle wait.
• Timer compression: why reduced rippled timers improved medians before damaging tails.
• Post Fiat path: what a certified applied-batch receipt does and does not establish.
• Appendices: XRPL expiration/load behavior and peer context.

Result card

Finality surfaces

Post Fiat certified-batch path

wallet submits signed native transfer
  -> local admission
  -> one-transfer batch
  -> signed proposal
  -> validator votes
  -> quorum/full-vote certificate
  -> local application
  -> finality receipt                         [timer stops]


Private rippled validated-ledger path

wallet submits signed payment
  -> current open ledger
  -> ledger close
  -> establish/proposal convergence
  -> accept/apply
  -> trusted validations
  -> payment observed in validated ledger      [timer stops]

Aggregate results

The conservative Post Fiat headline lane is full-vote, not quorum-fast. In this packet, the full-vote lane waited for all six validator votes before returning.

Ratios, with the boundary attached

Method in one page

The selected matched packet is:

Post Fiat L1 v2 / selected private XRPL matched latency packet

Generated node databases, generated validator keys, generated wallet material, and private logs are excluded from the public packet. Public raw reports are scanned for known private key and seed fields before the hash manifest is written.

The timing-matrix packet that selected close_750ms is:

XRPL private timing stability matrix

That matrix tested stock private rippled plus reduced-timing profiles before the selected matched rerun.

Why the XRPL control is a ledger-cycle measurement

For an application using XRPL semantics, a payment is not final merely because a server accepted it into an in-progress ledger. XRPL’s documentation distinguishes provisional API results from final immutable results: a transaction is final only if it is signed, submitted, and accepted into a validated ledger version after consensus.¹²

That makes the rippled measurement a ledger-cycle measurement:

[ T_{\text{submit}\rightarrow\text{validated}}

R_{\text{open}} + T_{\text{establish}} + T_{\text{build/apply}} + T_{\text{validation}} + T_{\text{client observe}} + T_{\text{queue}} ]

The rippled consensus documentation describes an Open phase, an Establish phase, and an Accept phase. The Open phase lets transactions build up in the open ledger; shortening it trades latency against throughput.³ The Establish phase is where servers share proposals, compare transaction sets, resolve disagreements, and declare consensus only after minimum timing and supermajority conditions are satisfied.⁴

The current stock ConsensusParms source sets:

The source comments warn that these consensus parameters are “not meant to be changed arbitrarily.”⁵

A first-order stock median model is:

If transactions arrive roughly uniformly during an open-ledger interval \(C\), then:

With \(C = 2s\) and \(T_{\text{establish,min}} = 1.95s\):

The measured stock private rippled p50 was 3000.565 ms. That is the expected consequence of measuring validated-ledger finality with an open-ledger wait and a minimum establish phase.

XRPL consensus has also been analyzed in safety/liveness and formal-model work; those papers are useful context, while the timing argument here is grounded in the documentation and source constants above.⁶⁷⁸

What timer compression did to private rippled

The timing matrix avoids a straw-man comparison against only stock private rippled. It tested stock private rippled plus close_1500ms, close_1000ms, close_750ms, close_500ms, and close_250ms, each with five sessions and 1000 sequential payments per session.

The matrix labels are preserved from the packet. In this article, strained means the profile was not stable but also not classified unstable; unstable is the packet label for profiles whose p99 jumped above 10 seconds with large >=10s tail counts.

No reduced-timing profile met the frozen stable criteria. The fastest non-unstable profile was close_750ms, so it became the selected XRPL control in the matched rerun. The close_250ms lane is retained as an aggressive stress lane, not as the optimized XRPL control.

The central XRPL optimization result is simple:

Reducing private rippled timing improved median latency.
Aggressive compression produced large tails.
No reduced-timing profile met the frozen stable criteria.

The selected matched packet repeated the same stress shape for close_250ms:

close_250ms matched rerun:
  p50:   573.367 ms
  p95: 15345.814 ms
  p99: 19918.846 ms

The problem was not that stock private rippled failed. The problem is that the most direct route to making private rippled feel subsecond—compressing the ledger clock—produced unstable tails before the benchmark left loopback.

Why the tail gets nonlinear

Timer compression is not linear optimization. It reduces the slack that hides propagation delay, proposal skew, transaction-set disagreement, scheduling noise, and validator lag.

A quorum system waits on an order statistic, not an average. Let \(D_i\) be the delay for validator \(i\) to receive, process, and respond within the relevant phase. If the protocol needs \(q\) of \(n\) participants by time \(t\), the simple binomial quorum model is:

[ P(D_{(q)} \le t)

\sum_{k=q}^{n} \binom{n}{k} F(t)^k(1-F(t))^{n-k} ]

For a six-node, five-of-six quorum-shaped path, this becomes:

Solving \(6p^5(1-p)+p^6=s\) numerically gives the per-validator-path percentile needed by time \(t\): \(s = 0.95\) gives roughly 93.7%, and \(s = 0.99\) gives roughly 97.3%. If the path waits for all six, the model is \(p^6=s\); system-level p95 then requires each individual path to be around 99.15% by \(t\).

This simple model is not a full model of rippled; it explains why p50 and tail behavior can separate quickly. The median asks what happens when ordinary paths behave. The tail asks how often one validator, queue, scheduler, peer proposal, or transaction set arrives late enough to push the round into recovery behavior.

The matched packet makes the tail shape visible:

This is consistent with distributed-systems literature. Partial synchrony is the standard model for protocols that must work despite unknown or temporarily violated network-delay and processor-speed bounds; timer budgets have to dominate the delay distribution that appears in production, not only the delay distribution that appears in a quiet local test.⁹ Tail-latency work reaches the same operational conclusion from a systems angle: small high-latency episodes can dominate perceived performance as systems scale or utilization rises.¹⁰

A one-host benchmark removes real RTT, packet delay variation, clock skew across machines, noisy neighbors, kernel scheduling variance across hosts, and validator-placement differences. That makes a good one-host result useful as a critical-path measurement, but it also makes bad loopback tails important: a multi-host deployment has to absorb more delay distribution, not less.

What the Post Fiat path changes

The benchmarked Post Fiat path is a direct certified-transfer path:

wallet signs native transfer
  -> local admission
  -> one-transfer batch
  -> signed proposal
  -> validator vote collection
  -> quorum certificate / full-vote certificate
  -> local application
  -> finality receipt

Here, a certificate means the node-verified vote set for a proposed batch that satisfies the validator-set and quorum rules. Before returning, the node checks the parent, proposal, batch, validator set, quorum, vote set, certificate id, and state evidence.

For \(n = 6\) validators, the certificate quorum is:

The quorum-fast lane returned when a valid quorum certificate was available. The full-vote lane still observed 6 of 6 votes before returning.

What the certified receipt does and does not establish

That distinction is the point of the benchmark. Post Fiat did not make the same ledger clock run faster. It moved the wallet’s synchronous completion point to a certified applied-batch receipt and kept non-finality work out of that path.

The Post Fiat transaction improvement process in this packet is:

Keep the safety-critical certificate checks in the synchronous path;
move non-finality work out of it;
return when the transfer is certified and applied.

That is a structural optimization, not a timer tweak.

Safety gate

A fast number is not useful if the node can finalize conflicting histories or accept stale certificates.

The selected packet included a local adversarial finality gate. It passed 9/9 cases with residual_work == [].

At this article’s level of detail, the Byzantine disjoint proposer case is a conflicting-proposer attempt; the expected result is refusal to finalize conflicting histories. The safety gate does not create the latency result. It supports the narrower claim that the measured fast path still passed a local adversarial finality check in this harness.

Evidence and reproduction

Public packets

The selected matched packet includes README.md, aggregate.json, aggregate.md, methodology.md, endpoint-equivalence.md, manifest.json, commands.sh, lab-book.md, session-summary.csv, latency-bars.svg, latency-cdf.svg, raw JSON reports, safety artifacts, and SHA256SUMS.txt.

Hashes for the claim-critical artifacts

Recorded top-level commands

The selected matched packet records this fresh run command:

RUN_ID=postfiat-selected-xrpl-v4-20260609T052252Z SESSIONS=5 ROUNDS=1000 VALIDATORS=6 TUNED_BIN=/home/postfiat/repos/rippled/.build/rippled-timing-46b241ace8b3-close_750ms TUNED_PROFILE=close_750ms TUNED_CLASSIFICATION=strained TUNED_SOURCE_MATRIX=/home/postfiat/repos/postfiatorg.github.io/static/benchmarks/xrpl-private-timing-stability-matrix-xrpl-timing-stability-20260608T152301Z AGGRESSIVE_BIN=/home/postfiat/repos/rippled/.build/rippled-timing-46b241ace8b3-close_250ms AGGRESSIVE_PROFILE=close_250ms RUN_SAFETY_GATE=1 BUILD_RELEASE=1 FORCE=1 scripts/postfiat-xrpl-latency-evidence-v4

It also records the final repackaging command after raw reports existed:

RUN_ID=postfiat-selected-xrpl-v4-20260609T052252Z SESSIONS=5 ROUNDS=1000 VALIDATORS=6 TUNED_BIN=/home/postfiat/repos/rippled/.build/rippled-timing-46b241ace8b3-close_750ms TUNED_PROFILE=close_750ms TUNED_CLASSIFICATION=strained TUNED_SOURCE_MATRIX=/home/postfiat/repos/postfiatorg.github.io/static/benchmarks/xrpl-private-timing-stability-matrix-xrpl-timing-stability-20260608T152301Z AGGRESSIVE_BIN=/home/postfiat/repos/rippled/.build/rippled-timing-46b241ace8b3-close_250ms AGGRESSIVE_PROFILE=close_250ms RUN_SAFETY_GATE=1 BUILD_RELEASE=0 RESUME=1 scripts/postfiat-xrpl-latency-evidence-v4

The timing matrix records this command:

RUN_ID=xrpl-timing-stability-20260608T152301Z SESSIONS=5 ROUNDS=1000 VALIDATORS=6 PROFILES=stock,close_1500ms,close_1000ms,close_750ms,close_500ms,close_250ms BUILD_PROFILES=1 FORCE=1 scripts/xrpl-timing-stability-matrix

The full expanded command log is in each packet’s manifest.json and commands.sh. Raw report paths and original start/finish UTCs are in manifest.json and lab-book.md.

What this evidence settles

It settles the local claim:

In a local one-host, six-validator native-transfer benchmark, Post Fiat L1 v2
full-vote certified finality completed signed transfers at 88.083 ms p50 and
104.705 ms p95. Stock private rippled validated transfers at 3000.565 ms p50.
The matrix-selected reduced-timing private rippled profile, close_750ms, was
classified strained and validated transfers at 883.507 ms p50. The aggressive
close_250ms stress lane reached 573.367 ms p50 but had 15345.814 ms p95 and
19918.846 ms p99.

It does not settle public-mainnet latency, WAN behavior, validator diversity, concurrent throughput, optimized XRPL engineering, independent reproducibility, or superiority over every BFT or object-execution design.

Next evidence

The next claims require new packets, not stronger adjectives.

The engineering goal for the next packets is to preserve the certified receipt path as the environment becomes more real.

Conclusion

XRPL-style finality gives applications a conservative and well-understood boundary: the validated ledger. That boundary is valuable. It is also a structural latency surface. A transaction waits for the ledger cycle: open-ledger residual time, establish-phase proposal convergence, ledger construction, validations, client observation, and sometimes queueing.

The private rippled timing matrix tested the natural shortcut: compress the ledger clock. Median latency improved. Then the aggressive profiles exposed the tail.

Post Fiat took a different route. The wallet waits for a certified applied batch rather than a compressed ledger close. In this local six-validator benchmark, the conservative full-vote path returned signed-transfer finality at 88.083 ms p50 and 104.705 ms p95 while the local adversarial finality gate passed.

That is the result worth building around: not “we turned the same clock faster,” but “we made the transaction completion path smaller.”

Appendix A: XRPL application latency under expiration and load

There is no single honest “maximum XRPL transaction latency” number without assumptions.

For applications, the practical maximum is controlled by reliable submission discipline. If a transaction includes LastLedgerSequence, the client can keep querying validated ledgers until one of two events happens: the transaction appears in a validated ledger, or the network validates ledgers beyond the transaction’s last allowed ledger.

In simplified form:

where \(L_{\text{last}}\) is the transaction’s LastLedgerSequence, \(L_{\text{submit}}\) is the last validated ledger index observed at submission, and \(T_{\text{ledger}}\) is the observed validated-ledger cadence.

Without expiration, the bound is weaker. XRPL’s reliable-submission documentation notes that if transaction cost rises above what the transaction specifies, a well-formed transaction may not be included in the next validated ledger; if costs later fall and the transaction has no expiration, there is no limit to how much later it can be included.²

The claim-critical benchmark is sequential. Under load, XRPL latency has another term:

[ T_{\text{submit}\rightarrow\text{validated}}

T_{\text{cycle}} + K_{\text{queue}}\cdot T_{\text{ledger}} ]

Here \(K_{\text{queue}}\) is the number of ledger cycles a transaction waits before inclusion.

That term is operationally real. rippled has a transaction queue. The XRPL documentation explains that the open ledger cost sets a target number of transactions in a ledger; if the open ledger surpasses that target, required transaction cost escalates quickly, and transactions that cannot pay the escalated cost may be queued for later ledgers. The queue is then used to build subsequent ledgers.¹¹

A serious load benchmark must therefore report finalized transactions per second, failures, expired transactions, admission latency, queue depth, fee policy, CPU, memory, and state size. Otherwise the benchmark can hide the difference between a fast finality path and a growing queue.

Appendix B: Peer context

The XRPL control is the lineage-specific comparison. It is not the whole L1 landscape.

A separate local peer calibration packet included Avalanche and Sui lanes. It showed Post Fiat local account/certified-finality lanes around the same sub-100ms p50 class as the claim-critical packet, Avalanche C-Chain local transfer receipt near two seconds p50, and Sui local effects lanes around four milliseconds p50 in the tested local setup.

This context prevents the wrong claim. Post Fiat is not claiming the lowest local p50 among modern systems. The peer packet instead points to the next architectural question: whether Post Fiat should add an owned-value or certificate-first transfer lane for cases that do not need the full account-ledger coordination path.

Source notes