A transaction makes a round trip: the client submits it, the network reaches consensus, RPC ingests the ledger, and the client reads it back. The trip crosses several systems. This tool splits the end-to-end (E2E) latency into its parts and compares two things: the fixed goal the team set for a phase, and the current state measured by a benchmark run. It models hot ingestion only — ledgers RPC ingests live as they close. It does not model backfill.
End-to-end latency is the sum of four slices along the transaction path. Each slice is a P99 latency (the 99th percentile). A different part of the stack owns each slice.
The ledger close interval, counted once per ledger close on the transaction's path (N). The Stellar Core team owns this slice. In phases 1–2 a transaction spans 2 closes — it waits for the next ledger, not the one in the current vote. In phase 3, Core's consensus + execution pipelining requires 3 closes for a transaction to complete. The calculator below shows the value for the selected phase.
The time for a transaction to travel from the client to Stellar RPC v2. This value is an estimate. A measured value from RPC v2 will replace it.
The time from meta available in captive core (the externalized ledger) to ingested in RPC. The benchmarks measure this slice. It is the slice this project makes faster.
The time from ingested in RPC to the client having that information, for example a GetTransaction call. This value is an estimate. A measured value will replace it after a query benchmark.
Pick a phase to load its fixed goal. Pick a run to measure the current state. Both E2E totals are derived from the formula — never controlled directly. The E2E budget the team declared for the phase is drawn as a ceiling on each bar.