A transaction makes a round trip: the client submits it, the network reaches consensus, RPC ingests the ledger, and the client reads it back. This tool splits the 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.
End-to-end latency is the sum of six slices. The network slices are hardcoded constants from an assumed 50 ms client↔RPC round trip. Every other slice is a P99 latency.
The model assumes a 50 ms client↔RPC round trip (RTT). It uses two fixed constants:
By design, the model never measures network time.
The in-RPC duration of the sendTransaction endpoint — network time excluded.
The ledger close interval, counted once per ledger close on the transaction's path (N). 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 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 in-RPC duration of the getTransaction endpoint for an ingested transaction —
network time excluded. This value is an estimate. A measured value will replace it after a query
benchmark.
Pick a phase to load its fixed goal; the run list narrows to runs paced for it.