Speed up smoke tests

[noonio]

The preview and preprod smoke tests take about 30 minutes each, almost entirely
waiting on protocol deadlines rather than on anything the scenario asserts. This
takes about 10 minutes off without narrowing any transaction's validity window.

Where the time went

Timestamps from run 29412843078
(mainnet, but blockTime is 20s on preview, preprod and mainnet alike). Job
total 27m51s:

phase	wall
checkout + nix develop .#exes	4m05s (cold cache only; a later run reached ClusterOptions in 32s)
--publish-hydra-scripts	56s
refuel Alice (faucet tx)	47s
seed wallet + node start	84s
Init to HeadIsOpen	28s
POST /commit to CommitRecorded	15s
CommitRecorded to DepositActivated	8m07s
increment to CommitFinalized	8s
L2 tx + snapshot	<1s
Decommit to DecommitFinalized	27s
Close to HeadIsClosed	47s
HeadIsClosed to ReadyToFanout	9m24s
Fanout to HeadIsFinalized	1s
returnFundsToFaucet	57s

Two waits account for ~17.5 of the 28 minutes. mkTestTiming sets
contestationPeriod = depositPeriod = depositActivation = 20 * blockTime = 400s.

Deposit activation. A deposit becomes active at
created + depositActivation, where created is the deposit tx's upper
validity bound, set a grace time ahead of the chain tip. Note that grace time
is not what it appears: Handlers.hs:283 reads

let graceTime = maxGraceTime `min` untilDeadline / 2

and a backticked function is infixl 9 against /'s infixl 7, so this is
min 200 untilDeadline / 2, a flat 100s for any deadline more than 200s
out, not the min 200 (untilDeadline / 2) it reads as. That is why the wait is
the observed 8m07s (100 + 400 = 500s) rather than the 600s the expression
suggests. Only depositActivation is ours to cut.

Contestation. The deadline is closeTxUpperBound + contestationPeriod,
with the close tx bounded at now + min contestationPeriod maxGraceTime, so
closing costs min cp 200 + cp = 200 + 400. Confirmed in the log: close posted
at 12:03:42, contestationDeadline 12:13:42.

What changed

New mkSmokeTiming, used by the hydra-cluster executable:
contestationPeriod = 10 * blockTime (200s), depositActivation = 1 * blockTime
(20s), depositPeriod unchanged at 20 * blockTime.

	before	after
deposit activation wait	500s	120s
contestation wait	600s	400s
close / contest / increment window	200s	200s
deposit active window	300s	300s

The contestation period stops exactly where min cp maxGraceTime would start
falling below 200s, so no transaction gets a shorter window than it has today
and nothing is more likely to expire. depositPeriod is deliberately not
shortened: it is not on the critical path (it sets how long a deposit stays
active, not how long anything waits), and the active window is
depositPeriod - graceTime, so cutting it towards the grace time closes the
window in which the increment can be posted. Since Expired is tested before
Active in determineNextDepositStatus, that failure mode is a run that hangs
to its full timeout rather than an error. Test.Hydra.Cluster.UtilSpec guards
this, along with the depositPeriod >= min cp maxGraceTime constraint that
deposit.ak's Claim path imposes on the increment tx.

singlePartyHeadFullLifeCycle now takes the timing constructor as a parameter,
so EndToEndSpec's devnet run keeps mkTestTiming (at 0.1s blocks the smoke
values would truncate to nonsense).

Alice's fuel and the deposit wallet are also funded by one faucet transaction
instead of two (refuelAndSeed, seedManyFromFaucet), saving a confirmation.
refuelIfNeeded is now refuelAndSeed ... [], a single implementation.

Risk

The one thing that changes is the derived unsyncedPeriod, which is half the
contestation period and so falls from 200s to 100s. On the direct backend drift
is sampled when a block arrives (handleOutOfSync runs from the Tick input,
whose only source is onRollForward) and so measures processing lag, where 100s
is ample. It is worth watching on --blockfrost-preview, whose follower only
observes blocks that already have a successor and therefore lags a block gap by
construction; --unsynced-period is the override if it shows up.

Testing

just lint and just check clean. just test green apart from
can open, close & fanout a Head using Blockfrost @requiresBlockfrost, which
fails identically on master and on a stashed tree, and only runs in the nightly
workflow.

Some runs also show devnet e2e tests failing with OutsideValidityIntervalUTxO
on a deposit transaction. The affected set differs every time and includes tests
this branch does not touch; they all use mkTestTiming, whose devnet deposit
window is max 10 slots, one second at the devnet's 0.1s slots, so it is thin
under load regardless of this change. Failures track run duration rather than
branch.

---

• CHANGELOG updated or not needed (test infrastructure only, nothing in the released node changes)
• Documentation updated or not needed (hydra-cluster/README.md)
• Haddocks updated or not needed
• No new TODOs introduced or explained herafter

[github-actions]

Transaction cost differences

No cost or size differences found

[github-actions]

End-to-end benchmark differences

Comparing 854be99 (PR) against merge-base 59737ae. Each runner measures both sides; every delta is the median over the same-machine pairs. Colored rows exceed the per-metric noise threshold with directional agreement (a calibrated heuristic, not a significance test); ≈ is within noise; uncolored rows are context. 🟢 = improvement, 🔴 = regression.

Round-trip latency (3 nodes, closed-loop, 3x250 txs)

Metric	master	PR	Δ
End-to-end TPS (tx/s)	174.90	175.31	≈ +1.4%
Sustained TPS, slope (tx/s)	178.02	177.95	≈ +1.8%
Backlog drain time (s)	0.01	0.01	🟢 -17.5%
Snapshots per second (/s)	119.16	119.56	≈ +1.6%
Avg txs per snapshot	1.47	1.47	≈ -0.2%
Avg. Confirmation Time (s)	0.017	0.017	≈ -1.6%
P50 confirmation (s)	0.017	0.016	≈ -2.1%
P95 confirmation (s)	0.022	0.022	≈ -0.6%
Tx validation time p50 (s)	0.005	0.005	≈ -0.0%
Alloc MB per confirmed tx	4.13	4.13	≈ -0.1%
Alloc MB per snapshot	6.07	6.04	≈ -0.3%
Mutator CPU s per 1k txs	13.11	13.08	≈ -1.1%
Max live MB (max node)	16.37	16.36	≈ -0.1%
Peak node RSS (MB)	126.83	126.68	≈ -0.1%
Invalid txs	0.00	0.00	≈ +0.0

Sustained load (3 nodes, 3x5000 txs)

Metric	master	PR	Δ
End-to-end TPS (tx/s)	775.09	787.84	≈ -0.4%
Sustained TPS, slope (tx/s)	1,196.36	1,239.56	≈ +1.9%
Backlog drain time (s)	18.87	18.52	≈ +0.2%
Snapshots per second (/s)	0.83	0.84	≈ +1.8%
Avg txs per snapshot	937.50	937.50	≈ +0.0%
Tx validation time p50 (s)	5.110	5.139	≈ -0.8%
Alloc MB per confirmed tx	3.77	3.81	≈ +0.6%
Alloc MB per snapshot	3,534.67	3,543.24	≈ -0.2%
Mutator CPU s per 1k txs	3.58	3.56	≈ -0.2%
Max live MB (max node)	80.95	80.31	≈ -1.0%
Peak node RSS (MB)	334.57	334.68	≈ -0.4%
Invalid txs	0.00	0.00	≈ +0.0

Plateau 1000 UTxO (1 node, 4000 txs)

Metric	master	PR	Δ
End-to-end TPS (tx/s)	673.67	645.22	≈ -3.6%
Sustained TPS, slope (tx/s)	633.30	603.54	≈ -4.6%
Backlog drain time (s)	5.89	6.15	≈ +3.9%
Snapshots per second (/s)	2.30	1.45	-25.1%
Avg txs per snapshot	276.19	444.44	+41.7%
Tx validation time p50 (s)	2.607	2.266	≈ -8.0%
Alloc MB per confirmed tx	3.05	3.19	≈ +5.0%
Alloc MB per snapshot	836.81	1,427.21	+39.5%
Mutator CPU s per 1k txs	1.84	1.89	≈ -0.3%
Max live MB (max node)	20.89	26.17	🔴 +24.1%
Peak node RSS (MB)	151.06	162.13	≈ +5.2%
Invalid txs	0.00	0.00	≈ +0.0

---

• bench-results-m1: AMD EPYC 7763 64-Core Processor (4 vCPU, 16 GB)
• bench-results-m2: AMD EPYC 9V45 96-Core Processor (4 vCPU, 16 GB)
• bench-results-m3: INTEL(R) XEON(R) PLATINUM 8573C (4 vCPU, 16 GB)
• bench-results-m4: AMD EPYC 9V74 80-Core Processor (4 vCPU, 16 GB)
• Same-code spread across runners (End-to-end TPS), the noise an unpaired comparison would see:
  • Round-trip latency (3 nodes, closed-loop, 3x250 txs): branch 67.4%, master 63.0%
  • Sustained load (3 nodes, 3x5000 txs): branch 138.3%, master 132.6%
  • Plateau 1000 UTxO (1 node, 4000 txs): branch 110.9%, master 99.6%

Per-run raw values

Machine	Slot	Side	Scenario	E2E TPS	Outcome
bench-results-m1	1	branch	Round-trip latency (3 nodes, closed-loop, 3x250 txs)	166.65	ok
bench-results-m1	1	branch	Sustained load (3 nodes, 3x5000 txs)	669.93	ok
bench-results-m1	1	branch	Plateau 1000 UTxO (1 node, 4000 txs)	595.04	ok
bench-results-m1	2	master	Round-trip latency (3 nodes, closed-loop, 3x250 txs)	168.29	ok
bench-results-m1	2	master	Sustained load (3 nodes, 3x5000 txs)	683.97	ok
bench-results-m1	2	master	Plateau 1000 UTxO (1 node, 4000 txs)	646.95	ok
bench-results-m2	1	master	Round-trip latency (3 nodes, closed-loop, 3x250 txs)	261.73	ok
bench-results-m2	1	master	Sustained load (3 nodes, 3x5000 txs)	1,590.78	ok
bench-results-m2	1	master	Plateau 1000 UTxO (1 node, 4000 txs)	1,245.72	ok
bench-results-m2	2	branch	Round-trip latency (3 nodes, closed-loop, 3x250 txs)	272.80	ok
bench-results-m2	2	branch	Sustained load (3 nodes, 3x5000 txs)	1,596.18	ok
bench-results-m2	2	branch	Plateau 1000 UTxO (1 node, 4000 txs)	1,255.12	ok
bench-results-m3	1	branch	Round-trip latency (3 nodes, closed-loop, 3x250 txs)	183.97	ok
bench-results-m3	1	branch	Sustained load (3 nodes, 3x5000 txs)	802.61	ok
bench-results-m3	1	branch	Plateau 1000 UTxO (1 node, 4000 txs)	630.52	ok
bench-results-m3	2	master	Round-trip latency (3 nodes, closed-loop, 3x250 txs)	181.51	ok
bench-results-m3	2	master	Sustained load (3 nodes, 3x5000 txs)	811.48	ok
bench-results-m3	2	master	Plateau 1000 UTxO (1 node, 4000 txs)	700.39	ok
bench-results-m4	1	master	Round-trip latency (3 nodes, closed-loop, 3x250 txs)	160.59	ok
bench-results-m4	1	master	Sustained load (3 nodes, 3x5000 txs)	738.71	ok
bench-results-m4	1	master	Plateau 1000 UTxO (1 node, 4000 txs)	623.99	ok
bench-results-m4	2	branch	Round-trip latency (3 nodes, closed-loop, 3x250 txs)	162.92	ok
bench-results-m4	2	branch	Sustained load (3 nodes, 3x5000 txs)	773.08	ok
bench-results-m4	2	branch	Plateau 1000 UTxO (1 node, 4000 txs)	659.92	ok

Workflow run

[github-actions]

Transaction costs

Transaction costs

Sizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using arbitrary values and results are not fully deterministic and comparable to previous runs.

Metadata
Generated at	2026-08-28 13:41:13.098158592 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νHead	1d511733200df551c8cd8cddb3160ed39087af815638be37a1b80ffd	12962
μHead	603f261bc5a01f5f4ed988cc07a40a130b94e6820c28e9affde82d9e*	4971
νDeposit	eafae2c32f99ab347c7bb15961e0e84c74305f9088c1a7b8abf88e7f	2117
νCRS	09db7ee6cf7a4b358dd5c8a2f19d2c048336ffc5a01ef35a47ca7072	2736

• The minting policy hash is only usable for comparison. As the script is parameterized, the actual script is unique per head.

Init transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	5473	9.48	3.12	0.50
2	5571	9.84	3.22	0.50
3	5667	10.13	3.31	0.51
5	5858	11.16	3.64	0.53
10	6342	13.73	4.46	0.58
50	10182	35.53	11.29	0.97
100	14983	62.26	19.65	1.46
114	16327	69.50	21.91	1.59

Cost of Increment Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	2822	20.88	7.49	0.70
2	2954	22.37	8.64	0.72
3	3084	22.79	9.43	0.74
5	3348	25.39	11.60	0.79
10	4003	30.00	16.39	0.89
50	9244	72.36	56.30	1.75
75	12519	97.83	80.96	2.27

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	642	18.50	6.69	0.58
2	772	19.46	7.66	0.60
3	904	20.46	8.65	0.62
5	1166	22.37	10.59	0.66
10	1821	27.14	15.44	0.76
50	7063	68.16	54.91	1.61
75	10343	93.20	79.42	2.13

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	670	17.76	11.66	0.61
2	796	18.75	12.64	0.63
3	931	19.70	13.61	0.65
5	1194	21.66	15.57	0.69
50	7086	67.76	60.09	1.64
74	10238	92.21	83.78	2.15

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	701	21.49	14.90	0.66
2	831	22.65	15.94	0.68
3	963	23.76	16.96	0.71
5	1226	26.07	19.02	0.75
10	1885	31.66	24.13	0.86
50	7117	79.56	65.74	1.78
66	9214	98.54	82.33	2.14

FanOut transaction costs

Involves spending head output and burning head tokens. Uses ada-only UTXO for better comparability.
Rows first grow the UTxO set at a fixed 10 parties, then show the largest set that still fits per number of parties (burning more participation tokens leaves less room for outputs).

Parties	UTxO	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
10	0	0	5645	23.70	43.00	1.14
10	1	57	5678	26.05	45.51	1.18
10	5	284	5813	36.28	55.83	1.34
10	10	568	5982	50.26	69.12	1.56
10	20	1139	6323	82.76	97.10	2.04
1	20	1138	6043	76.54	95.13	1.96
5	20	1138	6167	79.31	96.00	1.99
10	20	1139	6323	82.76	97.10	2.04
20	20	1137	6631	90.08	99.38	2.13
50	15	854	7394	95.05	92.01	2.15

PartialFanOut transaction costs

Largest chunk of ada-only outputs that can be distributed in one partial fanout step, computed dynamically. The last row is the maximum total UTxO count where at least one output can still be distributed.

Total UTxO	Distributed	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
11	10	571	988	35.29	66.46	1.20
25	23	1308	1427	68.58	99.53	1.73
30	23	1311	1430	68.58	99.53	1.73
40	23	1310	1429	68.58	99.53	1.73
50	23	1310	1429	68.58	99.53	1.73
100	23	1310	1429	68.58	99.53	1.73
150	23	1309	1428	68.58	99.53	1.73
200	23	1310	1429	68.58	99.53	1.73
200	23	1308	1423	68.58	99.53	1.73

PartialFanOut transaction costs (with native tokens)

Largest chunk of native-token outputs that can be distributed in one partial fanout step, computed dynamically. The last row is the maximum total UTxO count where at least one output can still be distributed.

Total UTxO	Distributed	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
11	10	1010	1488	42.27	68.94	1.29
25	21	2121	2368	76.71	99.20	1.83
30	21	2079	2324	76.71	99.20	1.83
40	21	2436	2698	76.71	99.30	1.85
50	21	2058	2303	76.71	99.20	1.83
100	21	2247	2501	76.69	99.25	1.84
150	21	2583	2853	76.71	99.35	1.85
200	21	2121	2369	76.71	99.20	1.83
200	21	2037	2277	76.71	99.20	1.83

FinalPartialFanOut transaction costs (with native tokens)

Terminal partial fanout step (FanoutProgress → Final) with outputs carrying a native token. Burns all head tokens and proves accumulator exhaustion via BLS proof.

Distributed	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	101	5521	22.51	44.43	1.14
5	505	5840	36.06	55.94	1.34
10	990	6221	54.18	70.71	1.61
10	1030	6260	54.18	70.73	1.61

End-to-end benchmark results

End-to-end benchmark results

This page is intended to collect the latest end-to-end benchmark results produced by Hydra's continuous integration (CI) system from the latest master code.

Please note that these results are approximate as they are currently produced from limited cloud VMs and not controlled hardware. Rather than focusing on the absolute results, the emphasis should be on relative results, such as how the timings for a scenario evolve as the code changes.

Generated at 2026-08-28 13:45:13.772395934 UTC

Baseline Scenario

Number of nodes	1
Number of txs	300
Load mode	open-loop
Avg. Confirmation Time (ms)	206.2
P99	209.4ms
P95	209.3ms
P50	205.9ms
Tx validation time p50 (ms)	131.3
End-to-end TPS	1405.11 tx/s
Backlog drain time (s)	0.2
Snapshots observed	3
Snapshots per second	14.05 /s
Avg txs per snapshot	100.0
Peak node RSS (MB)	144.4
Number of Invalid txs	0
Fanout outputs	2

Three local nodes

Number of nodes	3
Number of txs	900
Load mode	open-loop
Avg. Confirmation Time (ms)	891.5
P99	948.9ms
P95	948.4ms
P50	880.6ms
Tx validation time p50 (ms)	445.2
End-to-end TPS	942.18 tx/s
Backlog drain time (s)	0.9
Snapshots observed	3
Snapshots per second	3.14 /s
Avg txs per snapshot	300.0
Peak node RSS (MB)	145.8
Number of Invalid txs	0
Fanout outputs	4

Scenario benchmark results

Scenario benchmark results

This page collects results from the scenario matrix: every combination of cluster size, UTxO shape, and incremental-ops mode is exercised by CI from the latest master code and reported below.

Numbers are approximate. They come from cloud VMs rather than controlled hardware, so the useful signal is the relative change between cells and between commits, not the absolute throughput.

Generated at 2026-08-28 13:58:01.135767376 UTC

Summary across cells

TPS columns are rates (transactions per second); Wall clock (s) is the measured elapsed time from the first tx submission to the last confirmation. Times are rounded to one decimal.

Scenario	Txs	Wall clock (s)	End-to-end TPS (tx/s)	Sustained TPS (tx/s)	Avg conf (ms)	P95 conf (ms)
Nodes=1, Constant, fire and forget	30	0.0	1095.54	n/a	26.7	27.1
Nodes=1, Constant, wait for tx valid	30	0.1	214.72	214.39	4.6	5.7
Nodes=1, Growing, fire and forget	30	0.0	1021.29	n/a	28.7	29.1
Nodes=1, Growing, wait for tx valid	30	0.2	173.07	174.32	5.7	6.9
Nodes=1, Mixed, fire and forget	30	0.0	1074.12	n/a	27.0	27.7
Nodes=1, Mixed, wait for tx valid	30	0.2	190.16	187.27	5.2	6.3
Nodes=2, Constant, fire and forget	60	0.1	1079.11	n/a	53.9	55.4
Nodes=2, Constant, wait for tx valid	60	0.4	147.16	144.08	13.4	16.4
Nodes=2, Growing, fire and forget	60	0.1	859.34	n/a	67.2	69.5
Nodes=2, Growing, wait for tx valid	60	0.5	109.26	107.59	18.1	22.7
Nodes=2, Mixed, fire and forget	60	0.1	1036.36	n/a	56.4	57.2
Nodes=2, Mixed, wait for tx valid	60	0.5	119.02	114.39	16.6	20.9
Nodes=3, Constant, fire and forget	90	0.1	729.64	n/a	109.3	115.8
Nodes=3, Constant, wait for tx valid	90	0.8	114.67	113.30	25.7	33.1
Nodes=3, Growing, fire and forget	90	0.1	620.45	n/a	142.4	144.7
Nodes=3, Growing, wait for tx valid	90	2.4	38.08	40.19	77.9	168.3
Nodes=3, Mixed, fire and forget	90	0.1	697.46	n/a	126.5	127.7
Nodes=3, Mixed, wait for tx valid	90	0.9	98.28	95.98	30.3	38.9

Nodes=1, Constant, fire and forget

Number of nodes	1
Number of txs	30
Load mode	open-loop
Avg. Confirmation Time (ms)	26.7
P99	27.2ms
P95	27.1ms
P50	26.9ms
Tx validation time p50 (ms)	12.4
End-to-end TPS	1095.54 tx/s
Backlog drain time (s)	0.0
Snapshots observed	2
Snapshots per second	73.04 /s
Avg txs per snapshot	15.0
Peak node RSS (MB)	129.7
Number of Invalid txs	0
Fanout outputs	2

Nodes=1, Constant, wait for tx valid

Number of nodes	1
Number of txs	30
Load mode	closed-loop
Avg. Confirmation Time (ms)	4.6
P99	6.1ms
P95	5.7ms
P50	4.4ms
Tx validation time p50 (ms)	1.6
End-to-end TPS	214.72 tx/s
Sustained TPS	214.39 tx/s
Backlog drain time (s)	0.0
Snapshots observed	30
Snapshots per second	214.72 /s
Avg txs per snapshot	1.0
Peak node RSS (MB)	128.5
Number of Invalid txs	0
Fanout outputs	2

Nodes=1, Growing, fire and forget

Number of nodes	1
Number of txs	30
Load mode	open-loop
Avg. Confirmation Time (ms)	28.7
P99	29.2ms
P95	29.1ms
P50	28.9ms
Tx validation time p50 (ms)	12.1
End-to-end TPS	1021.29 tx/s
Backlog drain time (s)	0.0
Snapshots observed	2
Snapshots per second	68.09 /s
Avg txs per snapshot	15.0
Peak node RSS (MB)	130.3
Number of Invalid txs	0
Fanout outputs	31

Nodes=1, Growing, wait for tx valid

Number of nodes	1
Number of txs	30
Load mode	closed-loop
Avg. Confirmation Time (ms)	5.7
P99	7.4ms
P95	6.9ms
P50	5.6ms
Tx validation time p50 (ms)	1.6
End-to-end TPS	173.07 tx/s
Sustained TPS	174.32 tx/s
Backlog drain time (s)	0.0
Snapshots observed	30
Snapshots per second	173.07 /s
Avg txs per snapshot	1.0
Peak node RSS (MB)	130.4
Number of Invalid txs	0
Fanout outputs	31

Nodes=1, Mixed, fire and forget

Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.

Number of nodes	1
Number of txs	30
Load mode	open-loop
Avg. Confirmation Time (ms)	27.0
P99	27.7ms
P95	27.7ms
P50	27.2ms
Tx validation time p50 (ms)	11.7
End-to-end TPS	1074.12 tx/s
Backlog drain time (s)	0.0
Snapshots observed	2
Snapshots per second	71.61 /s
Avg txs per snapshot	15.0
Peak node RSS (MB)	129.4
Number of Invalid txs	0
Fanout outputs	2

Nodes=1, Mixed, wait for tx valid

Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.

Number of nodes	1
Number of txs	30
Load mode	closed-loop
Avg. Confirmation Time (ms)	5.2
P99	7.1ms
P95	6.3ms
P50	5.0ms
Tx validation time p50 (ms)	1.6
End-to-end TPS	190.16 tx/s
Sustained TPS	187.27 tx/s
Backlog drain time (s)	0.0
Snapshots observed	30
Snapshots per second	190.16 /s
Avg txs per snapshot	1.0
Peak node RSS (MB)	142.9
Number of Invalid txs	0
Fanout outputs	2

Nodes=2, Constant, fire and forget

Number of nodes	2
Number of txs	60
Load mode	open-loop
Avg. Confirmation Time (ms)	53.9
P99	55.4ms
P95	55.4ms
P50	54.3ms
Tx validation time p50 (ms)	26.9
End-to-end TPS	1079.11 tx/s
Backlog drain time (s)	0.1
Snapshots observed	2
Snapshots per second	35.97 /s
Avg txs per snapshot	30.0
Peak node RSS (MB)	144.1
Number of Invalid txs	0
Fanout outputs	3

Nodes=2, Constant, wait for tx valid

Number of nodes	2
Number of txs	60
Load mode	closed-loop
Avg. Confirmation Time (ms)	13.4
P99	22.4ms
P95	16.4ms
P50	12.9ms
Tx validation time p50 (ms)	4.4
End-to-end TPS	147.16 tx/s
Sustained TPS	144.08 tx/s
Backlog drain time (s)	0.0
Snapshots observed	60
Snapshots per second	147.16 /s
Avg txs per snapshot	1.0
Peak node RSS (MB)	143.9
Number of Invalid txs	0
Fanout outputs	3

Nodes=2, Growing, fire and forget

Number of nodes	2
Number of txs	60
Load mode	open-loop
Avg. Confirmation Time (ms)	67.2
P99	69.5ms
P95	69.5ms
P50	66.8ms
Tx validation time p50 (ms)	28.7
End-to-end TPS	859.34 tx/s
Backlog drain time (s)	0.1
Snapshots observed	2
Snapshots per second	28.64 /s
Avg txs per snapshot	30.0
Peak node RSS (MB)	144.9
Number of Invalid txs	0
Fanout outputs	62

Nodes=2, Growing, wait for tx valid

Number of nodes	2
Number of txs	60
Load mode	closed-loop
Avg. Confirmation Time (ms)	18.1
P99	24.5ms
P95	22.7ms
P50	17.7ms
Tx validation time p50 (ms)	5.2
End-to-end TPS	109.26 tx/s
Sustained TPS	107.59 tx/s
Backlog drain time (s)	0.0
Snapshots observed	60
Snapshots per second	109.26 /s
Avg txs per snapshot	1.0
Peak node RSS (MB)	144.6
Number of Invalid txs	0
Fanout outputs	62

Nodes=2, Mixed, fire and forget

Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.

Number of nodes	2
Number of txs	60
Load mode	open-loop
Avg. Confirmation Time (ms)	56.4
P99	57.3ms
P95	57.2ms
P50	56.7ms
Tx validation time p50 (ms)	21.9
End-to-end TPS	1036.36 tx/s
Backlog drain time (s)	0.1
Snapshots observed	2
Snapshots per second	34.55 /s
Avg txs per snapshot	30.0
Peak node RSS (MB)	143.1
Number of Invalid txs	0
Fanout outputs	3

Nodes=2, Mixed, wait for tx valid

Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.

Number of nodes	2
Number of txs	60
Load mode	closed-loop
Avg. Confirmation Time (ms)	16.6
P99	22.2ms
P95	20.9ms
P50	16.8ms
Tx validation time p50 (ms)	5.1
End-to-end TPS	119.02 tx/s
Sustained TPS	114.39 tx/s
Backlog drain time (s)	0.0
Snapshots observed	60
Snapshots per second	119.02 /s
Avg txs per snapshot	1.0
Peak node RSS (MB)	144.5
Number of Invalid txs	0
Fanout outputs	3

Nodes=3, Constant, fire and forget

Number of nodes	3
Number of txs	90
Load mode	open-loop
Avg. Confirmation Time (ms)	109.3
P99	115.9ms
P95	115.8ms
P50	111.4ms
Tx validation time p50 (ms)	47.5
End-to-end TPS	729.64 tx/s
Backlog drain time (s)	0.1
Snapshots observed	3
Snapshots per second	24.32 /s
Avg txs per snapshot	30.0
Peak node RSS (MB)	143.8
Number of Invalid txs	0
Fanout outputs	4

Nodes=3, Constant, wait for tx valid

Number of nodes	3
Number of txs	90
Load mode	closed-loop
Avg. Confirmation Time (ms)	25.7
P99	38.3ms
P95	33.1ms
P50	24.8ms
Tx validation time p50 (ms)	7.0
End-to-end TPS	114.67 tx/s
Sustained TPS	113.30 tx/s
Backlog drain time (s)	0.0
Snapshots observed	62
Snapshots per second	79.00 /s
Avg txs per snapshot	1.5
Peak node RSS (MB)	145.0
Number of Invalid txs	0
Fanout outputs	4

Nodes=3, Growing, fire and forget

Number of nodes	3
Number of txs	90
Load mode	open-loop
Avg. Confirmation Time (ms)	142.4
P99	144.8ms
P95	144.7ms
P50	143.3ms
Tx validation time p50 (ms)	43.8
End-to-end TPS	620.45 tx/s
Backlog drain time (s)	0.1
Snapshots observed	2
Snapshots per second	13.79 /s
Avg txs per snapshot	45.0
Peak node RSS (MB)	145.2
Number of Invalid txs	0
Fanout outputs	0

Nodes=3, Growing, wait for tx valid

Number of nodes	3
Number of txs	90
Load mode	closed-loop
Avg. Confirmation Time (ms)	77.9
P99	191.4ms
P95	168.3ms
P50	43.7ms
Tx validation time p50 (ms)	12.0
End-to-end TPS	38.08 tx/s
Sustained TPS	40.19 tx/s
Backlog drain time (s)	0.0
Snapshots observed	62
Snapshots per second	26.23 /s
Avg txs per snapshot	1.5
Peak node RSS (MB)	145.0
Number of Invalid txs	0
Fanout outputs	0

Nodes=3, Mixed, fire and forget

Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.

Number of nodes	3
Number of txs	90
Load mode	open-loop
Avg. Confirmation Time (ms)	126.5
P99	127.8ms
P95	127.7ms
P50	127.0ms
Tx validation time p50 (ms)	41.5
End-to-end TPS	697.46 tx/s
Backlog drain time (s)	0.1
Snapshots observed	2
Snapshots per second	15.50 /s
Avg txs per snapshot	45.0
Peak node RSS (MB)	144.9
Number of Invalid txs	0
Fanout outputs	4

Nodes=3, Mixed, wait for tx valid

Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.

Number of nodes	3
Number of txs	90
Load mode	closed-loop
Avg. Confirmation Time (ms)	30.3
P99	39.6ms
P95	38.9ms
P50	30.0ms
Tx validation time p50 (ms)	9.0
End-to-end TPS	98.28 tx/s
Sustained TPS	95.98 tx/s
Backlog drain time (s)	0.0
Snapshots observed	60
Snapshots per second	65.52 /s
Avg txs per snapshot	1.5
Peak node RSS (MB)	145.6
Number of Invalid txs	0
Fanout outputs	4