Endorser blocks: forging, propagation, acquiring, certifying

• cardano-node 2026w42 (2d6a2a66415cc1d58c18ed3ee83ce719713fc97d)
• Dijkstra limits: 40,000 B of references (maxEndorserBlockReferencesSize), 260,000 B of transactions (maxEndorserBlockTxsSize)
• 2-in 2-out transactions, 2 destination keys, 374 B each
• Offered load (token bucket configured limit, not the one the cluster achieved): 0.85 tx/s per target (0.32 KB/s), 43.4 tx/s aggregate (16.25 KB/s) over 51 targets
• 51 nodes · AP (Sydney) 17 · EU (Frankfurt) 17 · US (N. Virginia) 17
• Mempool timeout overrides: 5.0 s capacity (MempoolTimeoutCapacity), 1.0 s soft (MempoolTimeoutSoft), 3.0 s hard (MempoolTimeoutHard)
• TxSubmissionLogicVersion = TxSubmissionLogicV2

Setup

Topology

51 pools · 3 regions: AP 17, EU 17, US 17 · torus-dense · 306 producer entries = 204 links (102 reciprocated) · 153 intra-region links, 51 inter-region · every pool has exactly 8 link partners · diameter 4, radius 4, mean shortest path 2.48 hops · peer sharing off (PeerSharing false in the node's configuration), so a node talks only and always to its listed producers

Full graph

Intra-region links only

Inter-region links only

Node positions are identical in all three views; hover a node to highlight its links everywhere and read its degrees. Region colours: EU green, US red, AP blue. Links are drawn undirected; direction and each pool's producer list are in the adjacency table.

Adjacency table

Node	Region	Out intra	Out inter	In intra	In inter	Producers (outbound)
node-0	EU	4	2	4	2	node-1, node-2, node-3, node-48, node-15, node-33
node-1	US	4	2	4	2	node-2, node-0, node-4, node-49, node-16, node-34
node-2	AP	4	2	4	2	node-0, node-1, node-5, node-50, node-17, node-35
node-3	EU	4	2	4	2	node-4, node-5, node-6, node-0, node-18, node-36
node-4	US	4	2	4	2	node-5, node-3, node-7, node-1, node-19, node-37
node-5	AP	4	2	4	2	node-3, node-4, node-8, node-2, node-20, node-38
node-6	EU	4	2	4	2	node-7, node-8, node-9, node-3, node-21, node-39
node-7	US	4	2	4	2	node-8, node-6, node-10, node-4, node-22, node-40
node-8	AP	4	2	4	2	node-6, node-7, node-11, node-5, node-23, node-41
node-9	EU	4	2	4	2	node-10, node-11, node-12, node-6, node-24, node-42
node-10	US	4	2	4	2	node-11, node-9, node-13, node-7, node-25, node-43
node-11	AP	4	2	4	2	node-9, node-10, node-14, node-8, node-26, node-44
node-12	EU	4	2	4	2	node-13, node-14, node-15, node-9, node-27, node-45
node-13	US	4	2	4	2	node-14, node-12, node-16, node-10, node-28, node-46
node-14	AP	4	2	4	2	node-12, node-13, node-17, node-11, node-29, node-47
node-15	EU	4	2	4	2	node-16, node-17, node-18, node-12, node-30, node-48
node-16	US	4	2	4	2	node-17, node-15, node-19, node-13, node-31, node-49
node-17	AP	4	2	4	2	node-15, node-16, node-20, node-14, node-32, node-50
node-18	EU	4	2	4	2	node-19, node-20, node-21, node-15, node-33, node-0
node-19	US	4	2	4	2	node-20, node-18, node-22, node-16, node-34, node-1
node-20	AP	4	2	4	2	node-18, node-19, node-23, node-17, node-35, node-2
node-21	EU	4	2	4	2	node-22, node-23, node-24, node-18, node-36, node-3
node-22	US	4	2	4	2	node-23, node-21, node-25, node-19, node-37, node-4
node-23	AP	4	2	4	2	node-21, node-22, node-26, node-20, node-38, node-5
node-24	EU	4	2	4	2	node-25, node-26, node-27, node-21, node-39, node-6
node-25	US	4	2	4	2	node-26, node-24, node-28, node-22, node-40, node-7
node-26	AP	4	2	4	2	node-24, node-25, node-29, node-23, node-41, node-8
node-27	EU	4	2	4	2	node-28, node-29, node-30, node-24, node-42, node-9
node-28	US	4	2	4	2	node-29, node-27, node-31, node-25, node-43, node-10
node-29	AP	4	2	4	2	node-27, node-28, node-32, node-26, node-44, node-11
node-30	EU	4	2	4	2	node-31, node-32, node-33, node-27, node-45, node-12
node-31	US	4	2	4	2	node-32, node-30, node-34, node-28, node-46, node-13
node-32	AP	4	2	4	2	node-30, node-31, node-35, node-29, node-47, node-14
node-33	EU	4	2	4	2	node-34, node-35, node-36, node-30, node-48, node-15
node-34	US	4	2	4	2	node-35, node-33, node-37, node-31, node-49, node-16
node-35	AP	4	2	4	2	node-33, node-34, node-38, node-32, node-50, node-17
node-36	EU	4	2	4	2	node-37, node-38, node-39, node-33, node-0, node-18
node-37	US	4	2	4	2	node-38, node-36, node-40, node-34, node-1, node-19
node-38	AP	4	2	4	2	node-36, node-37, node-41, node-35, node-2, node-20
node-39	EU	4	2	4	2	node-40, node-41, node-42, node-36, node-3, node-21
node-40	US	4	2	4	2	node-41, node-39, node-43, node-37, node-4, node-22
node-41	AP	4	2	4	2	node-39, node-40, node-44, node-38, node-5, node-23
node-42	EU	4	2	4	2	node-43, node-44, node-45, node-39, node-6, node-24
node-43	US	4	2	4	2	node-44, node-42, node-46, node-40, node-7, node-25
node-44	AP	4	2	4	2	node-42, node-43, node-47, node-41, node-8, node-26
node-45	EU	4	2	4	2	node-46, node-47, node-48, node-42, node-9, node-27
node-46	US	4	2	4	2	node-47, node-45, node-49, node-43, node-10, node-28
node-47	AP	4	2	4	2	node-45, node-46, node-50, node-44, node-11, node-29
node-48	EU	4	2	4	2	node-49, node-50, node-0, node-45, node-12, node-30
node-49	US	4	2	4	2	node-50, node-48, node-1, node-46, node-13, node-31
node-50	AP	4	2	4	2	node-48, node-49, node-2, node-47, node-14, node-32

Latency

cardano-cli ping round trips over the node-to-node handshake, measured at cluster start by each pool's healthcheck against its producers: 918 samples over 6 region pairs. Milliseconds.

Not an ICMP ping: cardano-cli ping opens a TCP connection and runs the node-to-node handshake, so each sample is an application-level round trip through both nodes' network stacks and mux, which is what the Cardano protocols actually experience. The TCP connect column is the bare TCP round trip from the same tool, the closest stand-in for a raw ping. SEM = SD / sqrt(n). The spread is 568x, from 0.51 ms within AP to 288.36 ms between AP and EU, and it is the floor under every interval in this report.

tx-centrifuge

The load generator, a closed-loop driver. A workload is a self-contained circuit: its own disjoint partition of funds, single-use UTxOs, its own builder turning funds into transactions, its own token-bucket rate limit, its own injection targets and its own observer following the chain. Every transaction spends funds and creates outputs, and an output becomes spendable again only once that workload's observer has seen its transaction reach the confirmation depth, so the transactions form chains gated by the chain itself and the funds budget is the buffer bridging confirmation latency. With on_exhaustion = error, a workload that cannot recycle funds as fast as it spends them runs that buffer to zero and fails the run rather than quietly slowing down.

• 51 workloads and 51 observers, one of each per pool: every workload drives its own pool and no other (51 of 51), and its observer follows that same pool rather than a shared one (51 of 51)
• builder value, every transaction 2-in 2-out with 2 destination signing key per builder, fee 1,000,000
• rate limit: token_bucket, scope per_target, at 0.85 tx/s per target, 43.4 tx/s offered in aggregate (16.25 KB/s at the 374 B measured transaction size)
• recycling on_confirm at confirmation depth 3, over a nodetonode observer
• initial funds from genesis-funds (genesis_utxo_keys), scope per_workload, so a fund returned by a workload can only be taken up by that same workload
• on_exhaustion = error · max_batch_size = 0

The generator runs on the explorer machine in eu-central-1, which forges nothing, so every transaction crosses the network before the pool that must place it in a block ever sees it: the round trip a workload pays is the EU row for its target's region in the table above. Each workload holds two buffers of its own, funds waiting to be built and built transactions waiting to be delivered.

1. Forging, generated load

Every EB forging found, nothing filtered. A block that lost its height battle, that was rolled away from, or that no other node ever adopted still counts.

Totals

By region

Endorser block contents

What an endorser block holds. An endorser block is a list of (tx hash, size) references and nothing else, so its size is that list's size.

3,279 of 3,289 EB forgings sit exactly at the run's largest EB, 695 references.

The transaction closure is what binds this run. Its transactions are 374 B each, so its largest endorser block holds 695 of them: 25,718 B of references against the 40,000 B cap (64.3%), and 259,930 B of transactions against the 260,000 B the closure allows (100.0%). The one that reaches 100% is the one that stopped the endorser block from growing.

The other run of this pair, 2026-10-22-23-20-e651d-w42notxsub-value-leios-workload-all-n2n-40k260k-1i1o1w-nomadperf-dira-nom, is the control for exactly this: its transactions are 200 B, its largest endorser block holds 1,110 references for 39,963 B (99.9% of the reference cap), and their closure is 222,000 B (85.4% of the closure cap). With 374 B transactions the closure fills first, with 200 B transactions the reference list does, off the same two caps. So the binding cap moved with the transaction size, and nothing else changed.

2. Propagation, fetching the EB references

Three instants are used:

• The forger forges the endorser block (Consensus.LeiosKernel.BlockForged)
• The forger announces it over the network (LeiosNotify.Remote.Send.BlockAnnouncement)
• A peer finishes receiving the endorser block's bytes over the network (LeiosFetch.Remote.Receive.Block)

Endorser blocks whose hash was forged more than once, and so referenced by more than one ranking block, are left out of this section.

Announcing

The forger alone: from forging the endorser block to sending its first announcement of it.

Fetching

From the forger's first announcement of the endorser block to that endorser block first arriving at a peer, one sample per node and endorser block, 164,150 of them. An endorser block is its list of transaction references, and that list is what arrives; the transactions themselves are fetched separately and are not in this section. Repeated deliveries of the same endorser block are counted under Activity, never timed here.

Spread over the cluster

One value per endorser block: the delay by which that share of the other nodes had first received it, measured from the forger's first announcement as above. The 100% row holds each endorser block's slowest node, so it sits above the table of every node and endorser block.

By region

Activity

The same events counted instead of timed, and counted per node and endorser block: for one endorser block, how many announcements a node sent out, and how many times it fetched the endorser block. Anything above one is a repeat the protocol paid for.

Times a node fetched the same endorser block

Inbound: the node pulling the endorser block from a peer. One means it fetched it once, more than one means it fetched the same endorser block again.

263,423 fetches in all, of which 99,273 brought an endorser block the node already had. The most one node fetched a single endorser block was 7 times.

By region of the receiving node

3. Acquiring, the EB written down

A delivered endorser block is not yet held: until its write is durable the body still reads as not-held, which is why the same endorser block can be fetched again meanwhile. Consensus.LeiosKernel.BlockAcquired is the moment that ends: the node has the reference list stored and claims to hold it, registering which referenced transactions it still needs. This is the step from arrival to that claim, which includes waiting for the single writer, and how often the same endorser block was stored again.

Writing

Spread over the cluster

One value per endorser block: the delay by which that share of the other nodes had first stored it, each measured from that node's own fetch of the endorser block. The 100% row holds each endorser block's slowest node, so it sits above the table of every node and endorser block.

By region

Activity

Counted per node and endorser block, like section 2: how many times a node wrote the same endorser block down. This one is local, nothing crosses the network.

208,814 writes in all, of which 44,664 were of an endorser block the node had already written. The most one node wrote a single endorser block was 5 times.

By region of the writing node

4. Closures, the transactions an EB references

An endorser block is a list of references. The transactions themselves are a separate transfer, and a node has the closure once it holds all of them: Consensus.LeiosKernel.BlockTxsAcquired. Counted per node and endorser block, on the same endorser blocks as sections 2 and 3.

Obtaining

A voter has until 7 s after the announcing block's slot onset to hold and validate the transactions: lHdrWait 3 s then lVoteWindow 4 s, both fixed in LeiosVoting.hs rather than read from genesis. 0 of 164,150 closures were obtained later than that, counted from the endorser block's forging.

Spread over the cluster

One value per endorser block: the delay by which that share of the other nodes had first obtained the closure, each measured from that node's own fetch of the endorser block. The 100% row holds each endorser block's slowest node, so it sits above the table of every node and endorser block.

By region

Activity

Times a node obtained the same closure

167,109 closures obtained in all, of which 2,959 were of one the node already had. The most one node obtained a single closure was 4 times.

By region of the obtaining node

5. Certifying

Counted on the blocks the whole cluster took. A block qualifies when all 50 nodes other than its forger adopted it, every peer it has of the 51 in the cluster: 3,217 of the run's 3,309 walkable blocks. Both sides of the ratio are held to it, so an announcement made by a block only part of the cluster held, and a certificate carried by one, are both out. No battle or fork filter is applied: nothing here asks what happened at a contested height, and the walk the blocks come from keeps every side of every fork.

Totals

By region

What happened to every endorser block

Hover a stage for what it counts and which trace says so. The stages down to Never reached quorum count endorser blocks; the rows under it count voter decisions, one per trace event, which is why they sum past 100%. Nothing is gated here, not even the run's opening epochs, so these counts are wider than section 2's.

When the transactions reach a node's own chain

The end of the line for an endorser block: a node adopts a ranking block that carries its certificate, and only then are those transactions on that node's chain. Measured from the endorser block's forging, over the 82,600 cases, one node and one endorser block each, where it happened.

6. Forks

Every switch a node made off a chain it already had, one row per node and switch (ChainDB.AddBlockEvent.SwitchedToAFork). A contest is one pair of tips, so a contest the whole cluster lived through counts once. Both rates below are contests per 1,000 blocks on the chain, so runs of different length compare directly.

The slot rate is the control and the height rate is the signal: two leaders in one slot is fixed by activeSlotsCoeff and cannot be engineered away, while a height battle is a node forging on a parent a sibling already had, which is propagation losing a race and is free to move. Reading the height rate without the control beside it cannot tell a propagation regression from a run that simply drew more forks.

What the nodes paid