
Every performance figure cites its file
Performance as measured in repo artifacts
Each number says whether the repo states it as a measurement, a configured value or a target.
You can check or dispute any figure here by opening the file it cites, and the label tells you how much weight it carries. A configured timeout is not a measurement, and a sizing target is not a result. The only measured numbers are local gateway latency runs recorded in the beta qualification log, which also records the 250 ms p50 threshold as unmet. Figures no repo file states are absent.
What it does
This is the one place Paxeer X performance figures appear. Every figure names the repo file that states it and says whether that file states it as a measurement, a configured value, or a target. The repo carries sizing targets, configured consensus and checkpoint bounds, a latency SLO, per-stage node instrumentation, and two load generators; the only numbers it records as measured are local gateway latency runs in the beta qualification log. Figures no repo file states are not carried here.
Key capabilities
- Labels every figure measured, configured or targeted, with the file that states it.
- Exports per-stage ABCI, commit and block-processing latency histograms from the node.
- Counts transactions, gas, optimistic processing and Giga executor fallbacks per block.
- Ships two load generators: a target-rate transaction client and a four-scenario benchmark script.
- Records measured latency runs, and unmet thresholds, in the beta qualification log.
- Gives operators a runbook procedure to measure seconds-per-block on a synced node.
Who it's for
Operators, integrators and reviewers who need a performance figure they can check against the repo.
Why it matters
Any number on this page can be reproduced or disputed by opening the file it cites, and the label says how much weight it carries: a configured timeout is not a measurement, and a sizing target is not a result. Numbers that no repo file supports are absent rather than repeated.
Differentiators
Block processing is instrumented stage by stage with OpenTelemetry histograms whose bucket boundaries are aligned to the stated latency SLO, so the exported metric can be read directly against the threshold it is meant to test.
Outcomes
- Trace any figure to the repo file that states it.
- Tell a measurement apart from a configured value or target.
- Measure seconds per block yourself with the operator runbook procedure.
Technical notes
- Measured: local gateway SEND latency runs in
spec/layerx-beta/qualification.kvx:8131,:8179and:8451. Each run is twenty real signed SENDs against a disposable local chain, with p50 between 1.85 s and 2.95 s and p99 between 2.97 s and 4.20 s across runs; post-merge native spans were preparation p50 38 ms, commit and write-ahead log 173 ms, publication including availability 299 ms, total batch 708 ms. The same entries record the 250 ms p50 threshold as unmet. - Targeted: LayerX guarantor hardware is sized for 4000 activities per second sustained, 250 ms batches, 2400-batch checkpoints and a 512-byte average canonical activity (
spec/layerx-protocol/docs/guarantors.md:46); block processing has a stated SLO of p50 ≤ 500 ms, p95 ≤ 1.5 s, p99 ≤ 2.5 s, encoded in the node's histogram buckets (node/metrics.go:18). - Configured: live Paxeer consensus timeouts are propose 1 s, propose_delta 500 ms, vote 50 ms, vote_delta 500 ms, commit 50 ms, bypass off (
docs/runbooks/paxeer-x-fork.md:179-180); local dev and benchmark chains set prevote, precommit and commit to 2000 ms (scripts/initialize_local_chain.sh:176-178,benchmark/benchmark.sh:245-247); the beta owner policy assumes 2-second Paxeer blocks and a 60-second checkpoint interval, and a checkpoint seals at 2400 batches or 600000 ms, whichever comes first (platform/hosted/human/beta-owner-policy.json:16-17,spec/layerx-protocol/docs/checkpointing.md:180-182). - Configured: the committed load generator targets 500 transactions per second across 500 accounts (
loadtest/config.json:9-10). The Autobahn generator writesmax_txs_per_block: 5000, which is clamped to the hard-coded cap of 2000, so that default has no effect (consensus/cmd/tendermint/commands/gen_autobahn_config.go:86,consensus/autobahn/types/block.go:78,consensus/config/autobahn.go:129). - Instrumentation:
app_abci_begin_block_duration,app_abci_check_tx_duration,app_abci_deliver_tx_duration,app_abci_deliver_batch_tx_duration,app_abci_commit_duration,app_block_process_duration,app_tx_count,app_tx_gas,app_optimistic_processing,app_giga_fallback_to_v2andapp_block_gas_wanted_ratio(node/metrics.go:78-184).benchmark/benchmark.shlogstps=<value>every five seconds over theevm,erc20,mixedanddefaultscenarios (benchmark/AGENTS.md:9-21). - Not committed: no benchmark or load-test result artifact is tracked in the repo, and the raw run output the qualification log cites under
qual-logs/is untracked.storage/README.md:5-11states PaxDB improvement ratios with no committed benchmark or dataset behind them. The fork runbook has operators measure seconds-per-block themselves rather than citing a known value (docs/runbooks/paxeer-x-fork.md:80-86). On the LayerX side one sequencer is active at a time and new activities stop if it is unavailable (docs/wiki/Sequencing.md:42-45), and an activity is not final at accept: the L0 to L4 ladder backs a batch with bonded re-execution, a challenge window and withdrawal limits rather than a validity proof (docs/wiki/Finality.md:5,:13-19). A LayerX activity costs 1/10 of a cent.
More in Network
One network, two execution domains
One network, two runtimes, one account
ExploreSecurity policy and project governance
Report privately, read the residual risks
ExploreStaged finality ladder L0 to L4
Five finality steps, each with a liable party
ExploreValidator set and node operation
One binary, four node modes
ExploreBuild on Paxeer.
Give your agent a wallet, set its policy, and settle your first call on LayerX.