Comparative Performance Analysis of NIST-Selected Post-Quantum Signature Schemes for Distributed Ledger Technology

Abstract

Distributed ledgers must migrate from elliptic-curve signatures to post-quantum alternatives, and the open question is no longer which primitives are available but which ledger resource they exhaust first. This paper identifies the binding constraint of a block-constrained ledger after migration and its margin: whether capacity is limited by transaction payload or by signature-verification throughput. The inputs are measurements of the three NIST-selected families—ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and FN-DSA (FIPS 206, in development)—across all nine parameter sets and three classical baselines on one x86-64 platform under WSL2. Under first-order analytical bounds, payload capacity is the binding constraint for every scheme at the block sizes, intervals, and transaction formats examined, with verification headroom from 124 to 1622 times for the post-quantum configurations. The verification advantage of ML-DSA is parameter-dependent: ML-DSA-44 verifies 1.47 times faster than the ECDSA secp256k1 ledger verifier, whereas ML-DSA-87, mandated by CNSA 2.0, is 1.67 times slower; absolute timings and these ratios may differ on other platforms. Five of the nine configurations are Pareto-optimal within their security level. The FN-DSA results reflect the liboqs 0.16.0 implementation and may change once FIPS 206 is finalized. An interleaved control-probe protocol holds the mean cross-run coefficient of variation to 1.35%.

1. Introduction

Every transaction in a distributed ledger is authenticated by a digital signature, and every signature scheme in production use—ECDSA over secp256k1 or P-256, and Ed25519—derives its security from the hardness of the discrete logarithm problem. Shor’s algorithm solves that problem in polynomial time on a sufficiently capable quantum computer [1]; Grover’s algorithm delivers a quadratic speedup against the hash and symmetric primitives on which the remainder of a ledger depends [2].

A distributed ledger is a managed information system whose integrity guarantees, storage economics, and throughput are all downstream of one cryptographic primitive. Changing that primitive is therefore not a component swap but a change to the capacity and governance properties of the information system itself, and the present paper is concerned with quantifying that change.

1.1. The Threat and Its Horizon

The two quantum results do not threaten a ledger equally. Grover’s quadratic advantage against proof-of-work is largely consumed by the overhead of quantum error correction and parallelizes poorly, so specialized classical hardware retains its advantage. The operative threat is Shor’s algorithm applied to the signature layer [3]. This asymmetry determines what must be migrated first.

The resource question relevant to ledgers is therefore the elliptic-curve discrete logarithm, not integer factorization. Roetteler et al. established that the ECDLP over an n-bit prime field can be computed with at most 9n + 2⌈log₂ n⌉ + 10 logical qubits [4]. For the 256-bit curves used in production ledgers, this is of the order of 2330 logical qubits, approximately a factor of 2.7 below contemporaneous estimates for RSA-2048. Elliptic-curve signatures are thus the earlier target, not the later one.

Estimates have moved consistently in one direction. Gidney and Ekerå required 20 million noisy physical qubits to factor RSA-2048 [5]; a subsequent revision reduced that figure to under one million under the same physical assumptions [6]. On the hardware side, a distance-7 surface code has been demonstrated below the error-correction threshold, with logical error suppressed by a factor of 2.14 ± 0.02 per two units of code distance and operation beyond break-even [7].

These are engineering milestones rather than cryptographically relevant quantum computers, and informed commentary continues to caution against reading them as imminent capability [8]. This measurement effort is one part of a broader research program on the cross-layer security, performance, and governance constraints of post-quantum migration for distributed ledgers [9]. Within that program, a companion study quantifies the empirical rate at which cryptographically relevant vulnerabilities appear in the National Vulnerability Database [10]. The migration case does not depend on resolving the disagreement over when such computers will exist, although its basis for signatures differs from that for encryption. The harvest-now–decrypt-later model concerns confidentiality: ciphertext recorded today can be decrypted once such a computer exists, so the exposure window is set by the longevity of the protected data rather than by policy-mandated migration deadlines [11]. A ledger signature protects authenticity instead, and its risk is forgery: an adversary able to derive a private key from a public key visible on the ledger can sign transactions that spend the associated funds. Which funds are exposed is therefore settled before such a computer exists, by the public keys already on the ledger, and the exposure lasts until those funds are moved to post-quantum keys (Section 1.2). The empirical record also shows that cryptographically relevant vulnerabilities are already over-represented among those exploited in practice [10]. For a ledger holding long-lived value, the planning horizon is therefore the migration schedule, not the threat schedule.

1.2. Why Distributed Ledgers Are a Distinct Case

A ledger differs from other cryptographic deployments in that its public keys are frequently visible on the public record, and its holdings cannot be rotated by administrative action.

Two exposure windows must be distinguished. The first is transient: between broadcast and confirmation, a transaction reveals its public key while remaining unconfirmed, for minutes on Bitcoin and seconds on Ethereum. The second is permanent: once a key has been used, it remains on-chain indefinitely, and any balance still controlled by it is exposed at rest.

Measurements of the second window are substantial. Industry analysis estimates that approximately 6.04 million BTC, or 30.2% of issued supply, sits in addresses whose public keys are exposed at rest [12]. The estimate classifies coins from on-chain data by whether the public key needed to spend them is already visible: by design in pay-to-public-key, bare multisignature, and Taproot outputs, or through an earlier spend from the same key in hashed output types [12]. It describes the state of the ledger rather than forecasting an attack, and the source presents it as such [12]. A subsequent reconciliation of the independent 2025–2026 estimates finds that they agree to within roughly five percentage points of supply [13]. It divides the exposed supply into approximately 2.3 million BTC held in dormant addresses that are effectively unmigratable and approximately 3.7 million that could still be moved to post-quantum addresses [13]. Both figures are approximate, and the split depends on how dormant coins are identified [13]. The distinction is relevant for protocol design: a migration mechanism that relies solely on voluntary key rotation cannot reach the first category.

1.3. Standardized Primitives and the Resource Obstacle

The availability obstacle has been removed. NIST published FIPS 203 [14], FIPS 204 [15], and FIPS 205 [16] in August 2024, standardizing ML-KEM, ML-DSA, and SLH-DSA, respectively. FN-DSA, derived from Falcon, remains in development as FIPS 206, for which no public draft had been released by September 2026 [17]. Migration deadlines have been set: NIST IR 8547 proposes deprecation of RSA and elliptic-curve cryptography after 2030, and disallowance after 2035 [11], and CNSA 2.0 mandates ML-KEM-1024 and ML-DSA-87 for national security systems [18].

What has not been removed is the resource obstacle. Post-quantum signatures are substantially larger than classical ones, and a ledger operates under a fixed block-capacity budget and a fixed inter-block interval. A worked example illustrates the magnitude: substituting ML-DSA-44 for ECDSA in a Bitcoin P2WPKH transaction grows it from approximately 109.5 to 696.75 virtual bytes [19]. Substituting the primitive without adapting the protocol therefore converts a cryptographic upgrade into a throughput regression.

The classical remedy for payload inflation does not transfer. Aggregation schemes that compress many signatures into one are central to capacity planning in existing ledgers [20], but the equivalent constructions for lattice signatures are nascent and achieve only small compression. Sequential half-aggregation of Dilithium at security level 2 achieves an aggregation rate of approximately 0.9927, and a previously proposed Falcon-based aggregate scheme has been shown insecure [21]. The payload lever available to a post-quantum ledger is therefore narrower than the one available to a classical one.

1.4. Related Work and the Gap

Three lines of work bear on the problem, and each stops short of the question addressed here.

Primitive-level benchmarking. Extensive performance data exist for the standardized schemes, principally in the context of transport-layer protocols [22] and embedded targets [23]. These studies report signature sizes and operation latencies but do not transform them into ledger-relevant quantities such as block occupancy or achievable transaction rate.

Ledger-level modeling. Studies that do make the transformation model the effect of substituting Dilithium or Falcon on block size, propagation delay, and fork risk [24]. Independent analyses report that authenticated lattice payloads grow from the 65–73-byte range of ECDSA to kilobyte scale, while verification overhead increases by a factor of two to five depending on deployment [25]. A recent benchmarking study measures seven post-quantum signature families against ECDSA on three computers and simulates their effect on blockchain workloads [26]. Related work integrates NIST-selected signatures into blockchain prototypes on computer and embedded platforms and reduces transaction size through public-key recovery [27]. A protocol-level study formalizes cryptographic protocols for personal-data protection on Ethereum and Hyperledger Fabric and integrates the NIST lattice standards ML-KEM and ML-DSA into the Hyperledger Fabric implementation [28]. It concludes that the roughly fifty-fold growth in signature size makes direct post-quantum substitution on public Layer 1 networks economically unfeasible and points instead to hybrid and Layer 2 designs [28]. These studies establish comparative benchmarking in a ledger context. The two closest to the present study differ from it in what they hold fixed. The benchmarking study in [26] compares each post-quantum security level with an ECDSA curve of the same level, from P-256 at level 1 to P-521 at level 5. A ledger, by contrast, keeps its curve when it changes the post-quantum parameter set, so the present study uses ECDSA over secp256k1, the curve of Bitcoin and Ethereum, as the baseline at every level. The protocol-level study in [28] works at the level of protocol design and implementation, whereas the present study measures all nine standardized parameter sets and converts the measurements into the payload and verification ceilings of one ledger model. What these studies do not provide is a test, on one platform and under one drift-controlled protocol, of which resource ceiling binds across all nine standardized parameter sets.

Production deployments. Production ledgers and protocol proposals have already made concrete, divergent choices: a post-quantum output type for Bitcoin [29], Falcon-signed state proofs on Algorand mainnet [30], a Winternitz-based opt-in vault on Solana [31], protocol-level XMSS on the Quantum Resistant Ledger since 2018 [32], a scheme approved for stateful use by NIST [33], and hash-based aggregate signatures targeted for the Ethereum consensus layer [34]. These deployments do not converge on one scheme, and the parameters reported here are what a comparison between them requires.

What remains unresolved. The direction of the problem is no longer in dispute: the protocol-level analysis in [28] identifies signature size as the dominant cost of migration on public Layer 1 networks. A recent requirements analysis of post-quantum signatures for public blockchains [35] likewise treats signature bytes as a first-order budget constraint on transaction authorization. What has not been measured is the margin. Payload inflation and verification overhead have each been quantified. However, no study known to the authors tests, under one set of ledger parameters, whether a post-quantum ledger is limited by the bytes it can carry or the signatures it can check, and by how much. The magnitude matters as much as the direction. If verification headroom—the factor by which verification capability exceeds the payload-limited transaction rate—is narrow, effort spent on payload reduction only moves the bottleneck; if it is wide, verification throughput can be set aside, and protocol design can concentrate on the transaction payload. The two answers lead to different designs, and only a measured margin distinguishes between them.

A second gap concerns comparability. Published figures for the same scheme differ across sources by amounts that exceed the differences between the schemes themselves, because they originate from different platforms, implementations, and measurement protocols. A ratio measured on one machine does not transfer to another, yet such ratios are routinely cited as though they were properties of the algorithms.

1.5. Contribution

The main contribution of this paper is the identification of the binding resource constraint of a block-constrained ledger after post-quantum migration, together with its margin. Section 1.4 locates the gap: payload inflation and verification overhead have each been quantified, but they have not been compared under one set of ledger parameters. Closing it requires the six defining parameters of all three NIST-selected signature families across nine parameter sets, together with three classical baselines, measured on a single platform under a single measurement protocol. The six parameters are the public-key, secret-key, and signature lengths and the key-generation, signing, and verification times. The benchmark is therefore a means to an end rather than the main result, although its findings are reported in Section 3.1, Section 3.2, Section 3.3 and Section 3.4. Equations (1)–(5) transform the measured values into first-order capacity bounds for a block-constrained ledger and identify which constraint binds. The bounds are first-order in the sense that they follow from the measured sizes and timings and a small set of stated ledger parameters, without simulating network, mempool, or consensus dynamics (Section 2.1.3).

The work addresses three research questions. RQ2 is the principal question; RQ1 establishes the measured inputs on which its answer rests, and RQ3 the protocol that makes those inputs comparable.

RQ1. Which measured size and timing parameters of the NIST-selected signature schemes determine the binding resource constraint in a block-constrained ledger model? Section 3.1, Section 3.2, Section 3.3 and Section 3.4 show that, on the measured platform, the verification-speed advantage of ML-DSA over ECDSA is parameter-dependent rather than general, and that within each NIST security level the post-quantum design space is multi-criteria, so no universal ranking exists.

RQ2. Under the reference block size and interval, and across the tested range of transaction formats, is ledger capacity bound by transaction payload (C1) or by signature-verification throughput (C2), and by what margin? Section 3.5 and Section 3.6 show that, in the first-order model, payload capacity binds for every scheme measured, with verification headroom of 124 to 1622 times the achievable transaction rate for the post-quantum configurations. Section 3.5 states the range of ledger parameters to which this answer applies.

RQ3. Does interleaved measurement with a control probe reduce the cross-run variability of scheme medians relative to sequential measurement? Section 2.4 shows that it does, and this constitutes a secondary methodological contribution. Under the interleaved protocol, scheme medians agree across three runs to a mean coefficient of variation of 1.35%, while the control probe varied by up to 37% within a single run.

Measurement bias arising from apparently innocuous properties of an experimental setup is documented in systems benchmarking more generally [36], as is the case for reporting dispersion rather than a single figure [37].

Cryptographic agility, understood as the capacity to change primitives without redesigning the protocol, is the design principle within which these results are intended to be applied [38]. Hybrid classical–post-quantum signatures [39] and agile transaction formats [40] are the mechanisms through which a ledger would exercise it. The present paper does not propose such a mechanism. It supplies the measured parameters on which the choice among them depends.

1.6. Structure

Section 2 states the problem formally, defines the derived quantities, and describes the measurement platform, protocol, and threats to validity. Section 3 presents the measured parameters, the derived bounds, and the sensitivity analysis. Section 4 discusses the design implications, and Section 5 concludes.

2. Materials and Methods

2.1. Problem Formulation

2.1.1. Measured Quantities

For each scheme, the following are measured directly: public-key length, secret-key length, and signature length, in bytes; and the wall-clock duration of key generation, signing, and verification of a 32-byte message. The message length corresponds to a transaction hash, which is the object a ledger signature covers [41].

2.1.2. Derived Quantities

Two ledger-relevant quantities are derived from the measured ones. Both are first-order capacity bounds under stated assumptions, not deployment measurements.

Transaction size under scheme s is as follows:

TxSize(s) = F + Sig(s) + PK(s),

(1)

where s denotes the signature scheme, F is the size in bytes of all non-cryptographic transaction fields, held constant across schemes, and Sig(s) and PK(s) are the measured signature and public-key lengths of scheme s in bytes (Section 3.1). Equation (1) assumes one signature and one public key per transaction. The reference value F = 118 bytes corresponds to a UTXO transaction model; Section 3.6 reports the sensitivity of all derived quantities to this choice over the range 0–400 bytes.

Equation (1) includes the public key because no standardized post-quantum signature scheme provides ECDSA-style public-key recovery from the signature. A public-key recovery mode has been demonstrated for Falcon in a blockchain setting, reducing transaction size by up to 17% [27], but it is not available in the standard library implementation measured here. An account-model ledger that today omits the public key from the transaction must carry it after migration or store it separately; the byte cost does not disappear.

Block occupancy and the two throughput ceilings follow:

TxPerBlock(s) = ⌊B/TxSize(s)⌋,

(2)

TPS_capacity(s) = TxPerBlock(s)/T,

(3)

TPS_verify(s) = 1000/t_verify(s),

(4)

TPS_effective(s) = min (TPS_capacity(s), TPS_verify(s)),

(5)

where B is the block size in bytes (1 MB at the reference configuration), T the inter-block interval in seconds (10 s), ⌊·⌋ the floor function, since only whole transactions fit in a block, and t_verify(s) the median single-threaded verification time of scheme s in milliseconds (Section 3.1), so that 1000/t_verify(s) is the number of verifications per second. TPS_capacity(s) is the payload-limited throughput, TPS_verify(s) the verification-limited throughput, and TPS_effective(s) the lower of the two, all in transactions per second. The verification headroom is the ratio TPS_verify(s)/TPS_capacity(s); a headroom above 1 means that payload capacity binds. Equation (5) makes explicit which of the two constraints binds: payload capacity, denoted C1, or verification throughput, denoted C2. The C1–C5 constraint vocabulary follows the cross-layer framework of [9]. Section 3.3 also reports a propagation-limited bound associated with C3. It is the rate, in transactions per second, at which blocks can be transmitted over a reference node uplink of 50 Mbps within a propagation budget of 10% of the block interval; both values are assumptions of the model.

2.1.3. Scope of the Model

Equations (1)–(5) exclude signature aggregation, payload compression, batch verification, multi-core verification, mempool dynamics, and fee-market feedback. Section 4 states the direction in which each of them moves the bounds and its practical consequence. Batch and multi-core verification raise only the C2 ceiling, and mempool dynamics and fee-market feedback act on realized throughput rather than on either ceiling, so none of these four changes the C1 ordering of the schemes. Aggregation and compression act on transaction size and could change that ordering by amounts not measured here.

2.2. Measurement Platform

All measurements were obtained on a single machine, whose configuration is given in Table 1. Reporting the platform in full is a precondition for reproducibility, since post-quantum signature performance depends on microarchitecture, compiler behavior, and implementation choices, as the divergence between published benchmark figures demonstrates [42].

Table 1. Platform configuration.

Component	Specification
Processor	Intel Core i7-10750H (Intel Corporation, Santa Clara, CA, USA), 2.60 GHz nominal, 6 cores/12 logical
Memory	7.6 GiB
Operating system	Ubuntu 26.04 LTS (Canonical Ltd., London, UK) under WSL2 (Microsoft Corporation, Redmond, WA, USA)
Kernel	6.18.33.2-microsoft-standard-WSL2
Compiler	GCC 15.2.0 (Free Software Foundation, Boston, MA, USA)
Runtime	Python 3.14.4 (Python Software Foundation, Beaverton, OR, USA)
Post-quantum library	liboqs 0.16.0/liboqs-python 0.16.0 [43]
Secondary classical anchors	OpenSSL 3.5.5 (OpenSSL Software Foundation, Newark, DE, USA) backend via the Python cryptography package 46.0.5, used for ECDSA P-256, Ed25519, and secp256k1 on the generic curve path
Ledger baseline library	libsecp256k1 (bitcoin-core/secp256k1), built from source at commit a9a61831bdcd, loaded as a shared library and invoked through the Python ctypes foreign-function interface

The measuring process was pinned to a single logical core throughout each run. The machine was mains-powered, otherwise idle, and no other user applications were running.

One property of this platform requires explicit statement. Under WSL2, the guest does not observe the instantaneous processor frequency:/proc/cpuinfo reports the static nominal value of 2592 MHz irrespective of the actual clock. Frequency scaling and thermal throttling are therefore not observable by inspection on this platform. This motivates the control-probe design described in Section 2.4, which detects machine-state drift from the timing data itself rather than from operating-system telemetry.

2.3. Measurement Conventions

The signed message is a fixed 32-byte value. This length is not arbitrary: in a distributed ledger, the object covered by a transaction signature is a hash digest, so 32 bytes is the operationally correct message size. A longer message would inflate the hash-based family disproportionately and would misrepresent the deployment case [41].

Timing uses a monotonic, high-resolution clock (time.perf_counter_ns) and records each individual operation rather than a batch total, so that the distribution—not only its center—is available for analysis. This follows established practice in cryptographic microbenchmarking [42].

2.4. Measurement Protocol

2.4.1. Repetition Budget and Warm-Up

Each timed block is preceded by ten warm-up executions whose timings are discarded so that instruction and data caches are populated, and any one-time library initialization is excluded from the measured interval.

The repetition count is chosen adaptively, separately for each (scheme, operation) pair, and in every round. Before the warm-up, five executions whose timings are not recorded estimate the cost c of one operation; the repetition count is then set to 2 s/c so that the timed block lasts approximately two seconds, bounded to the range [5, 2000]. These settings apply to runs 5–7; runs 1–4 used five warm-up executions and an upper bound of 1000 (Table A1). Adaptive budgeting is necessary because the schemes differ in cost by more than four orders of magnitude. A fixed repetition count large enough to give a stable estimate for ML-DSA verification (≈0.024 ms) would require some five hours for SLH-DSA-128s signing (≈476 ms). The bounds prevent the fastest operations from consuming an unbounded budget and guarantee a minimum sample for the slowest.

2.4.2. Statistical Treatment

Central tendency is reported as the median, with the 5th and 95th percentiles as the measure of spread. The percentiles of every operation, together with its sample size and the confidence interval of its median, are given in Table A2.

The median is not a stylistic preference. Operating-system scheduling produces a right-skewed timing distribution: the modal cost is the true cost of the operation, and a small number of samples are displaced upward by preemption, interrupt handling, and page faults. The arithmetic mean is sensitive to that tail, whereas the median estimates the modal cost. A single standard deviation would likewise conflate symmetric measurement noise with the asymmetric scheduling tail, which the percentile interval does not. Reporting a robust central estimate together with an explicit dispersion measure follows established practice in performance evaluation [37]. Confidence intervals for medians and for verification ratios are obtained by a hierarchical bootstrap that mirrors the interleaved design. The retained data form 20 (run, round) clusters, each representing one machine state: rounds 5–8 of run 5 and rounds 1–8 of runs 6 and 7. Each of the 4000 draws selects 20 clusters with replacement from all retained clusters, resamples the timings within each selected cluster with replacement, and records the median of the pooled resampled timings. For a verification ratio, the scheme and the baseline are computed from the same selected clusters in every draw so that drift common to both is not counted twice. Intervals are the 2.5th and 97.5th percentiles of the 4000 draws, generated with a fixed seed (20260905). The intervals refer to the median of the pooled timings; the point estimates in Section 3.1 and Section 3.2 are medians across runs (Section 2.5) and lie within them.

Sample size differs by more than two orders of magnitude between operations, because the repetition budget is set by time rather than by count (Section 2.4.1). Verification requires at least 3592 timings per run for each scheme (Table 2). The slowest operations rest on far fewer: SLH-DSA-128s signing on five timings per round, that is 20 in the truncated run 5 and 40 in each of runs 6 and 7, and SLH-DSA-256f signing on 103 to 206 per run (Table A2). For these operations, the 5th and 95th percentiles of a single run are set by one or two observations. The bootstrap interval is as narrow as those of verification (±0.7% for SLH-DSA-128s signing), but it rests on 100 timings and is correspondingly less reliable. None of the conclusions depends on that precision. The binding-constraint result rests on byte counts, which are exact, and on verification times; the smallest verification headroom, 124 times, could be reversed only by an error in verification time of two orders of magnitude. Signing times enter only the statement in Section 3.4 that SLH-DSA-128s signing, at about 476 ms, excludes the scheme from interactive transaction paths, which holds for any error of the size indicated by its cross-run coefficient of variation of 0.80% (Table 2).

Table 2. Cross-run reproducibility across the three interleaved runs used for the results (runs 5–7); each CV is computed over three values, the medians of runs 5–7; n is the smallest per-run number of timings behind those medians; the final column records the truncation applied to run 5 for the reason given in Section 2.4.5.

Scheme	KeyGen CV, %	Sign CV, %	Verify CV, %	Verify Min–Max, ms	n Per Run, Verify/Sign	CV Caveat
ECDSA P-256	1.90	1.36	0.17	0.0577–0.0579	8000/8000	Three run medians; run 5 truncated (Section 2.4.5)
ECDSA secp256k1	0.81	0.66	0.59	0.0349–0.0353	8000/8000	Three run medians; run 5 truncated (Section 2.4.5)
Ed25519	0.76	1.01	0.82	0.0916–0.0931	8000/8000	Three run medians; run 5 truncated (Section 2.4.5)
ML-DSA-44	1.04	3.25	1.82	0.0237–0.0245	8000/8000	Three run medians; run 5 truncated (Section 2.4.5)
ML-DSA-65	1.28	1.65	0.55	0.0374–0.0378	8000/8000	Three run medians; run 5 truncated (Section 2.4.5)
ML-DSA-87	0.83	1.89	2.29	0.0567–0.0593	8000/8000	Three run medians; run 5 truncated (Section 2.4.5)
FN-DSA-512	2.71	0.96	4.03	0.0381–0.0413	8000/8000	Three run medians; run 5 truncated (Section 2.4.5)
FN-DSA-1024	0.87	1.41	1.16	0.0742–0.0758	8000/8000	Three run medians; run 5 truncated (Section 2.4.5)
SLH-DSA-128f	1.47	2.02	1.04	1.3688–1.3956	5060/346	Three run medians; run 5 truncated (Section 2.4.5)
SLH-DSA-128s	0.83	0.80	0.96	0.4753–0.4834	8000/20	Three run medians; run 5 truncated (Section 2.4.5)
SLH-DSA-192f	2.22	1.24	1.35	1.9833–2.0366	3597/211	Three run medians; run 5 truncated (Section 2.4.5)
SLH-DSA-256f	1.06	1.07	1.40	1.9971–2.0528	3592/103	Three run medians; run 5 truncated (Section 2.4.5)

2.4.3. Measurement Order and Its Effect

The first protocol used (run 1) measured each scheme to completion before beginning the next. This ordering has a defect that was discovered empirically. An independent execution of the same protocol on a subsequent day (run 2) produced timings that were uniformly slower, but not by a uniform factor: the inflation relative to run 1 ranged from 1.23× to 2.38× for verification, from 1.28× to 2.57× for signing, and from 1.26× to 2.36× for key generation.

Heterogeneous inflation is diagnostic. A change in clock frequency alone would scale all schemes by the same factor. Inflation that varies by scheme instead indicates that the machine state changed during the run, so schemes measured late in the sequence were measured under different conditions than those measured early. Under sequential ordering, position in the measurement sequence is confounded with scheme identity, and the confound falls disproportionately on whichever schemes are measured last.

The consequence was material. The ratio of ML-DSA-87 verification to ECDSA P-256 verification—a quantity central to Section 3—was 1.064 in run 1 and 1.535 in run 2. One value supports the conclusion that ML-DSA at security level 5 is at parity with ECDSA; the other does not.

Neither established benchmarking frameworks such as eBACS [42] and pqm4 [23] nor published performance studies of post-quantum signatures in protocol contexts [22] address measurement-order confounding explicitly, which is why the countermeasure is described here in full rather than by reference.

2.4.4. Revised Protocol: Interleaving and a Control Probe

Two changes were made for runs 3 and 4.

Interleaved measurement. The repetition budget for each (scheme, operation) pair is divided into R rounds, and the measurement cycles through all schemes within each round. Every scheme therefore samples the same sequence of machine states, and position in the sequence is no longer confounded with scheme identity. R = 8 was used for both runs. An optional idle interval between rounds allows the processor to cool; run 3 used 3 s and run 4 used 20 s.

Control probe. At the start of every round, a fixed reference workload—ECDSA P-256 verification, 150 repetitions—is measured and its median recorded. The control is invariant by construction, so any change in its measured value is attributable to the machine rather than to the workload. This yields a drift detector that does not depend on operating-system frequency reporting, which, as noted in Section 2.2, is unavailable on this platform.

The measurement software additionally records each timing together with the identifier of the round in which it was taken and the control value for that round, so that every individual observation can be related to the machine state under which it was obtained.

Runs 5–7 used a revised version of this design, with R = 8 rounds and no idle interval between rounds. The control was extended to two probes, both measured at the start of every round: SHA-256 over a fixed 64 KiB buffer (200 repetitions), a workload that shares no code path with any scheme under test, and ECDSA P-256 verification (50 repetitions). The scheme order was reshuffled in every round from a recorded seed, and each scheme cycled through a pool of 32 independent key, message, and signature triples. Table A1 summarizes the protocol of every run.

2.4.5. Observed Drift and the Validity of the Interleaved Design

The control probe showed that drift is real and substantial. In run 3, the control median ranged from 0.0553 ms to 0.0876 ms across the eight rounds. The shape of the variation is informative: the median of the first four rounds is 0.0585 ms and of the last four 0.0713 ms, an increase of 22.0%, consistent with gradual thermal warming rather than an isolated transient. In run 4, with the inter-round interval increased from 3 s to 20 s, the total control spread fell from 46.0% to 29.1%, confirming both the thermal interpretation and the partial effectiveness of the countermeasure.

The critical observation is what happened to the scheme measurements while the machine drifted by these amounts. Table 2 reports the coefficient of variation (CV) of the per-run median across the three interleaved runs (runs 5–7), that is, the sample standard deviation of the three run medians divided by their mean. With three values, the CV indicates agreement between runs rather than estimating a population dispersion, and one discordant run changes it substantially.

The mean verification CV across schemes is 1.35%, and the maximum is 4.03%; nine of the twelve schemes agree to better than 1.5%. This is the central methodological result: the control probe varied by up to 37% within a single retained run (ECDSA verification probe, run 6, range relative to its minimum), while the reported scheme medians agree across runs to about 1.35% on average. Interleaving distributes gradual drift evenly across all schemes, and the median over rounds absorbs it. A genuine abrupt step, however, is not distributed evenly, because it falls on one side or the other of whichever round happens to contain it.

Run 5 contains such a step. Both control probes registered an abrupt drop roughly six operations into round 4, of 23% on the hash probe and 29% on the ECDSA verification probe (Figure 1 and Figure 2). Before the step, the hash probe in run 5 was 23.4–24.5% above the median across all 24 rounds of runs 5–7; after it, run 5 fell within the range of runs 6 and 7. The three schemes measured earliest in round 4 (Ed25519, FN-DSA-1024, SLH-DSA-128s) therefore have a run-level median dominated by the pre-step state, while the remaining schemes, measured later in round 4, already reflect the post-step state.

Figure 1. Hash control-probe duration per measurement round in the three interleaved runs. The shaded rounds 1–4 of run 5 precede the abrupt step change detected by both control probes and are excluded by the round filter (Section 2.4.5).

Figure 2. ECDSA P-256 verification control-probe duration per measurement round in the three interleaved runs; shading as in Figure 1.

Rounds 1–4 of run 5 are therefore excluded from all reported values; Figure 1 and Figure 2 show them shaded. The exclusion was decided after the step had been observed, so it is a post hoc decision, and it is reported as such. To make it reproducible, it is stated as a criterion applied to every round of runs 5–7: a round is excluded when its hash-probe value exceeds the median of all 24 rounds by more than 20%. The criterion selects rounds 1–4 of run 5 (+23.4% to +24.5%) and no other round; the largest deviation among the retained rounds is +12.2% (run 6, round 8). It rests on the hash probe because that workload shares no code path with the schemes. The ECDSA probe also shows isolated single-round excursions of +21% to +30% in run 6 (rounds 1, 6, and 8), which the hash probe does not show beyond +12.2% and which do not persist. The drift indicator recorded by the measurement software cannot serve as the criterion. It is expressed relative to a reference probe taken before the first round of each run, and in run 5 that reference was itself taken in the slower state.

Because the criterion was formulated after the data were seen, Table A3 reports the main results under three treatments of run 5: rounds 5–8 only, as reported; all eight rounds; and run 5 removed. The verification ratios in Section 3.2 change by at most 2.1% across the three treatments (ML-DSA-44: 0.680, 0.694, and 0.688), and the binding constraint, the Pareto sets, and the minimum post-quantum headroom of 124 times are unchanged. What the exclusion changes is the cross-run agreement: with all eight rounds of run 5, the mean verification CV rises from 1.35% to 5.16%, almost entirely through the three schemes measured before the step in round 4, whose CVs reach 12.1–16.8%. Pooling the original sequential runs with the interleaved ones raises the verification CV to between 10.6% and 51.5%, because run 2 executed uniformly slower on every scheme; this earlier finding remains the motivating illustration for the interleaved design.

Figure 1 and Figure 2 show the duration of the hash and ECDSA verification control probes in each measurement round of runs 5–7.

The ML-DSA-87 ratio that motivated the revision is correspondingly stabilized: 1.064 in run 1, 0.980 in run 3, and 0.962 in run 4, against the 1.535 obtained from the contaminated run. These values consistently show near parity with ECDSA P-256 (pooled ratio of runs 3 and 4: 0.970, 95% CI [0.953, 0.988], which excludes unity). These ratios are taken against the ECDSA P-256 anchor; runs 5–7 give 0.981, 1.024, and 1.014 for the same ratio (Table A1). Measured against the ECDSA secp256k1 verifier adopted as the ledger baseline in runs 5 to 7, the same parameter set is 1.671 times slower (95% CI [1.641, 1.696]), as reported in Section 3.2.

2.4.6. Run Selection

Seven runs were executed in total; Table A1 lists each with its protocol, control probes, idle interval, role in the paper, and any data excluded. Runs 1 and 2 executed the sequential protocol. Runs 3 and 4 executed an early version of the interleaved protocol. They are superseded by runs 5–7, which used the revised interleaved design of Section 2.4.4 after the ECDSA secp256k1 ledger baseline was added and which form the basis of all reported values. Run 2 in particular ran uniformly slower on every scheme and is reported rather than dropped, because excluding it silently would misrepresent how the protocol was arrived at. The same principle is applied to run 5: its first four rounds are excluded from all reported values by the criterion of Section 2.4.5; the run itself is retained, and Table A3 reports the results with and without the exclusion.

Runs 1, 3, and 4 remain useful as a validation set rather than a reporting one. They predate the ledger baseline, so the comparison with runs 5–7 uses the ratio of ML-DSA-87 to ECDSA P-256 verification: 1.064, 0.980, and 0.962, against 0.981 to 1.024 in runs 5–7 (Table A1). The first sequential run and both interleaved protocol versions therefore place ML-DSA-87 near parity with ECDSA P-256, whereas the slowed run 2 does not (1.535).

2.5. Reproducibility

The measurement software, the analysis software, raw per-operation timings for every run, the per-round control values, and the aggregated summaries are provided to the journal for verification during peer review. They are accompanied by the recorded software environment of every run and a description that maps every table and figure to the command that produces it (Data Availability Statement). Every reported table and figure is regenerated from the raw data by a single command, so that no manual step intervenes between measurement and presentation.

Reported values are the median across the three interleaved runs (runs 5–7). The analysis software accepts the outputs of both protocol versions in a single input file and dispatches on record structure so that sequential and interleaved runs can be aggregated without manual reconciliation.

2.6. Threats to Validity

Single platform. All measurements come from one x86-64 processor with one compiler and one set of library implementations, under WSL2. Absolute timings will differ on other microarchitectures, on bare metal, on constrained embedded targets [23], and where hardware acceleration is available. Timing ratios may differ as well, including the ratios between classical and post-quantum schemes in Section 3.2 and the 1.47- and 1.67-fold figures derived from them. The reason is that the schemes differ in their dependence on microarchitectural features, as the floating-point dependence of FN-DSA discussed below illustrates. The relative ordering of the schemes is expected to be more stable than the absolute figures, but this expectation was not tested here and should not be assumed. The byte counts, and therefore the C1 bounds, do not depend on the platform.

Asymmetric code paths for the baselines. The schemes are reached through three software paths (Table 1): ECDSA P-256 and Ed25519 through the OpenSSL backend of the cryptography package; the ECDSA secp256k1 ledger baseline through libsecp256k1, invoked with ctypes; and the post-quantum schemes through liboqs [43] and its Python wrapper. All three are invoked from Python. The post-quantum schemes and the ledger baseline share one foreign-function mechanism, since the liboqs Python wrapper is itself built on ctypes, but the wrapper code around the call differs: for libsecp256k1 it parses the public key and the DER-encoded signature in separate calls before verifying. Per-call overhead therefore differs between the three paths, and it was not measured separately. Comparisons within the post-quantum group, which share one path, are more precise than comparisons across the classical/post-quantum boundary. Every ratio that crosses that boundary—the ratios to ECDSA secp256k1 in Section 3, and the factors derived from them in Section 3.1, Section 3.2 and Section 3.4—combines the difference between the algorithms with the difference between their software paths. The classical baseline should accordingly be read as an order-of-magnitude reference rather than a precision measurement. This asymmetry cannot reverse the binding-constraint result of Section 3.5. Per-call overhead adds to every measured verification time, so a native measurement would lower t_verify(s) for every scheme, raise every C2 ceiling, and widen the headroom. It can change the cross-boundary ratios in Section 3.2 by an amount and in a direction that was not measured. A native baseline measured outside the Python interpreter, or a single foreign-function path for all schemes, would remove the asymmetry and is planned as follow-up work.

Floating-point dependence of FN-DSA. The reference implementation of FN-DSA uses floating-point arithmetic in key generation and signing, which makes its timing more sensitive to the floating-point unit than that of the module-lattice and hash-based alternatives. A fixed-point implementation of the signing procedure is reported to be approximately a factor of two slower than the original floating-point implementation [44], which confirms that the cost profile is implementation-dependent. The FN-DSA figures are correspondingly more platform-specific.

FN-DSA parameter-set provenance. FIPS 206 remained in development, with no public draft released, throughout this measurement effort (Section 1.3; [17]). The FN-DSA figures reported here reflect the parameter encoding implemented in liboqs 0.16.0 [43] (released 9 July 2026), the version confirmed running in this study’s own measurement environment. liboqs 0.16.0’s own release notes report no FN-DSA-specific changes for this release, consistent with FIPS 206 itself still having no published text to track against. Accordingly, the implementation should be understood as tracking the pre-standardization Falcon reference design, which liboqs reports as version 20211101 with PQClean patches, rather than a specific FIPS 206 text. By contrast, this same liboqs release removed SPHINCS+ in favor of SLH-DSA and has shipped the finalized FIPS 204 ML-DSA since release 0.12.0, so neither of those two families carries this caveat. In September 2026, the NIST FIPS 206 team proposed that the standard specify the signing procedure exactly in fixed-point arithmetic [45]; implementations conforming to the final standard may therefore differ from the one measured here in key-generation and signing time. Should FIPS 206’s parameter encoding also change upon finalization, the FN-DSA byte counts in Table 3, Table 4, Table 5, Table 6 and Table 7 may require revision as well. Verification, which uses only integer arithmetic, is the operation least exposed to these changes. The FN-DSA results should therefore be read as results for liboqs 0.16.0 and re-measured once FIPS 206 is finalized; the other eight parameter sets, standardized under the finalized FIPS 204 and FIPS 205, are not affected.

Virtualized environment. Measurements were taken under WSL2 rather than on bare metal, adding a virtualization layer between workload and hardware and removing the guest’s visibility of the processor clock. The control probe compensates for the second of these. The first cannot be excluded, and its effect on absolute timings and on timing ratios was not measured against a bare-metal run.

Single-threaded verification. Verification throughput is reported for one thread, whereas production validators verify in parallel across cores. The reported verification ceiling is therefore conservative by roughly the core count, which strengthens rather than weakens the conclusion of Section 3.5.

Table 3. Measured parameters of classical and NIST-selected post-quantum signature schemes.

Scheme	Family	Level	PK, B	SK, B	Sig, B	KeyGen, ms	Sign, ms	Verify, ms
ECDSA P-256	classical	–	33	138	72	0.0160	0.0256	0.0578
ECDSA secp256k1	classical	–	33	32	72	0.0189	0.0263	0.0350
Ed25519	classical	–	32	32	64	0.0347	0.0345	0.0922
ML-DSA-44	ML-DSA	2	1312	2560	2420	0.0241	0.0575	0.0238
ML-DSA-65	ML-DSA	3	1952	4032	3309	0.0392	0.0885	0.0375
ML-DSA-87	ML-DSA	5	2592	4896	4627	0.0604	0.1130	0.0585
FN-DSA-512	FN-DSA	1	897	1281	752	5.1303	0.1725	0.0398
FN-DSA-1024	FN-DSA	5	1793	2305	1462	14.9468	0.3407	0.0756
SLH-DSA-128f	SLH-DSA	1	32	64	17,088	0.9722	22.9315	1.3911
SLH-DSA-128s	SLH-DSA	1	32	64	7856	61.7941	476.0891	0.4756
SLH-DSA-192f	SLH-DSA	3	48	96	35,664	1.4311	37.4459	2.0199
SLH-DSA-256f	SLH-DSA	5	64	128	49,856	3.6245	76.2770	2.0171

Note: Median across the three interleaved runs (runs 5 to 7). Message: 32-byte transaction hash. Public- and secret-key lengths are fixed for every scheme, as are ML-DSA and SLH-DSA signature lengths. FN-DSA signature length varies between signatures; the value given is the liboqs declared maximum (752 B and 1462 B; observed per-run medians 658–661 B and 1276–1277 B), because block capacity must accommodate the longest signature a scheme can emit. The SLH-DSA parameter sets measured are the SHA2 parameter sets in the pure (non-pre-hash) signing mode of FIPS 205. Figure 3 and Figure 4 present these data graphically.

Table 3. Measured parameters of classical and NIST-selected post-quantum signature schemes.

Scheme	Family	Level	PK, B	SK, B	Sig, B	KeyGen, ms	Sign, ms	Verify, ms
ECDSA P-256	classical	–	33	138	72	0.0160	0.0256	0.0578
ECDSA secp256k1	classical	–	33	32	72	0.0189	0.0263	0.0350
Ed25519	classical	–	32	32	64	0.0347	0.0345	0.0922
ML-DSA-44	ML-DSA	2	1312	2560	2420	0.0241	0.0575	0.0238
ML-DSA-65	ML-DSA	3	1952	4032	3309	0.0392	0.0885	0.0375
ML-DSA-87	ML-DSA	5	2592	4896	4627	0.0604	0.1130	0.0585
FN-DSA-512	FN-DSA	1	897	1281	752	5.1303	0.1725	0.0398
FN-DSA-1024	FN-DSA	5	1793	2305	1462	14.9468	0.3407	0.0756
SLH-DSA-128f	SLH-DSA	1	32	64	17,088	0.9722	22.9315	1.3911
SLH-DSA-128s	SLH-DSA	1	32	64	7856	61.7941	476.0891	0.4756
SLH-DSA-192f	SLH-DSA	3	48	96	35,664	1.4311	37.4459	2.0199
SLH-DSA-256f	SLH-DSA	5	64	128	49,856	3.6245	76.2770	2.0171

Note: Median across the three interleaved runs (runs 5 to 7). Message: 32-byte transaction hash. Public- and secret-key lengths are fixed for every scheme, as are ML-DSA and SLH-DSA signature lengths. FN-DSA signature length varies between signatures; the value given is the liboqs declared maximum (752 B and 1462 B; observed per-run medians 658–661 B and 1276–1277 B), because block capacity must accommodate the longest signature a scheme can emit. The SLH-DSA parameter sets measured are the SHA2 parameter sets in the pure (non-pre-hash) signing mode of FIPS 205. Figure 3 and Figure 4 present these data graphically.

Table 4. Verification time relative to the ECDSA secp256k1 ledger baseline on the measurement platform.

Scheme	Verify, ms	Ratio to ECDSA secp256k1	Ratio 95% CI	Interpretation
ECDSA secp256k1	0.0350	1.000	[1.000, 1.000]	baseline (production ledger curve)
ECDSA P-256	0.0578	1.651	[1.630, 1.670]	1.65× slower
Ed25519	0.0922	2.634	[2.606, 2.660]	2.63× slower
ML-DSA-44 (level 2)	0.0238	0.680	[0.675, 0.695]	1.47× faster
ML-DSA-65 (level 3)	0.0375	1.071	[1.051, 1.083]	1.07× slower
ML-DSA-87 (level 5)	0.0585	1.671	[1.641, 1.696]	1.67× slower
FN-DSA-512 (level 1)	0.0398	1.137	[1.103, 1.174]	1.14× slower
FN-DSA-1024 (level 5)	0.0756	2.160	[2.104, 2.184]	2.16× slower

Note: Median across runs 5–7 on the platform of Table 1. The confidence intervals capture run-to-run and round-to-round variability on this platform; they do not include the systematic differences between software paths (Section 2.6) or between platforms. The ratios cross the classical/post-quantum implementation boundary and should not be transferred to other environments (Section 3.2).

Table 4. Verification time relative to the ECDSA secp256k1 ledger baseline on the measurement platform.

Scheme	Verify, ms	Ratio to ECDSA secp256k1	Ratio 95% CI	Interpretation
ECDSA secp256k1	0.0350	1.000	[1.000, 1.000]	baseline (production ledger curve)
ECDSA P-256	0.0578	1.651	[1.630, 1.670]	1.65× slower
Ed25519	0.0922	2.634	[2.606, 2.660]	2.63× slower
ML-DSA-44 (level 2)	0.0238	0.680	[0.675, 0.695]	1.47× faster
ML-DSA-65 (level 3)	0.0375	1.071	[1.051, 1.083]	1.07× slower
ML-DSA-87 (level 5)	0.0585	1.671	[1.641, 1.696]	1.67× slower
FN-DSA-512 (level 1)	0.0398	1.137	[1.103, 1.174]	1.14× slower
FN-DSA-1024 (level 5)	0.0756	2.160	[2.104, 2.184]	2.16× slower

Note: Median across runs 5–7 on the platform of Table 1. The confidence intervals capture run-to-run and round-to-round variability on this platform; they do not include the systematic differences between software paths (Section 2.6) or between platforms. The ratios cross the classical/post-quantum implementation boundary and should not be transferred to other environments (Section 3.2).

Table 5. First-order bounds for a block-constrained distributed ledger.

Scheme	Sig Inflation	Tx Size, B	Tx/Block	Capacity Retention	Verify Rate, Verifications/s	Capacity TPS	Headroom	C3, tx/s	Binding Constraint
ECDSA P-256	1.0×	223	4484	100.0%	17,301	448.4	39×	2802.6	capacity (C1)
ECDSA secp256k1	1.0×	223	4484	100.0%	28,571	448.4	64×	2802.6	capacity (C1)
Ed25519	0.9×	214	4672	104.2%	10,846	467.2	23×	2920.5	capacity (C1)
ML-DSA-44	33.6×	3850	259	5.8%	42,017	25.9	1622×	162.3	capacity (C1)
ML-DSA-65	46.0×	5379	185	4.1%	26,667	18.5	1441×	116.1	capacity (C1)
ML-DSA-87	64.3×	7337	136	3.0%	17,094	13.6	1257×	85.1	capacity (C1)
FN-DSA-512	10.4×	1767	565	12.6%	25,126	56.5	445×	353.7	capacity (C1)
FN-DSA-1024	20.3×	3373	296	6.6%	13,228	29.6	447×	185.2	capacity (C1)
SLH-DSA-128f	237.3×	17,238	58	1.3%	719	5.8	124×	36.2	capacity (C1)
SLH-DSA-128s	109.1×	8006	124	2.8%	2103	12.4	170×	78.0	capacity (C1)
SLH-DSA-192f	495.3×	35,830	27	0.6%	495	2.7	183×	17.4	capacity (C1)
SLH-DSA-256f	692.4×	50,038	19	0.4%	496	1.9	261×	12.4	capacity (C1)

Note: First-order capacity bounds, not deployment measurements. Excludes signature aggregation, compression, batch verification, multi-core verification, mempool dynamics, and fee-market feedback. Headroom is the ratio of verification-limited to capacity-limited throughput. Capacity retention is transactions per block relative to the ECDSA secp256k1 baseline.

Table 5. First-order bounds for a block-constrained distributed ledger.

Scheme	Sig Inflation	Tx Size, B	Tx/Block	Capacity Retention	Verify Rate, Verifications/s	Capacity TPS	Headroom	C3, tx/s	Binding Constraint
ECDSA P-256	1.0×	223	4484	100.0%	17,301	448.4	39×	2802.6	capacity (C1)
ECDSA secp256k1	1.0×	223	4484	100.0%	28,571	448.4	64×	2802.6	capacity (C1)
Ed25519	0.9×	214	4672	104.2%	10,846	467.2	23×	2920.5	capacity (C1)
ML-DSA-44	33.6×	3850	259	5.8%	42,017	25.9	1622×	162.3	capacity (C1)
ML-DSA-65	46.0×	5379	185	4.1%	26,667	18.5	1441×	116.1	capacity (C1)
ML-DSA-87	64.3×	7337	136	3.0%	17,094	13.6	1257×	85.1	capacity (C1)
FN-DSA-512	10.4×	1767	565	12.6%	25,126	56.5	445×	353.7	capacity (C1)
FN-DSA-1024	20.3×	3373	296	6.6%	13,228	29.6	447×	185.2	capacity (C1)
SLH-DSA-128f	237.3×	17,238	58	1.3%	719	5.8	124×	36.2	capacity (C1)
SLH-DSA-128s	109.1×	8006	124	2.8%	2103	12.4	170×	78.0	capacity (C1)
SLH-DSA-192f	495.3×	35,830	27	0.6%	495	2.7	183×	17.4	capacity (C1)
SLH-DSA-256f	692.4×	50,038	19	0.4%	496	1.9	261×	12.4	capacity (C1)

Note: First-order capacity bounds, not deployment measurements. Excludes signature aggregation, compression, batch verification, multi-core verification, mempool dynamics, and fee-market feedback. Headroom is the ratio of verification-limited to capacity-limited throughput. Capacity retention is transactions per block relative to the ECDSA secp256k1 baseline.

Table 6. Transactions per 1 MB block as a function of the assumed fixed-field size. Signature lengths follow the same basis as Table 3: fixed lengths as specified for ECDSA P-256, ML-DSA and SLH-DSA, and the declared maximum for FN-DSA-512 (752 bytes), which exceeds the observed median by about 15%.

F, Bytes	ECDSA P-256	ML-DSA-44	ML-DSA-87	FN-DSA-512	SLH-DSA-256f
0	9523	267	138	606	20
45 (account model)	6666	264	137	590	20
118 (UTXO model)	4484	259	136	565	19
200	3278	254	134	540	19
300	2469	248	132	513	19
400	1980	242	131	488	19

Table 6. Transactions per 1 MB block as a function of the assumed fixed-field size. Signature lengths follow the same basis as Table 3: fixed lengths as specified for ECDSA P-256, ML-DSA and SLH-DSA, and the declared maximum for FN-DSA-512 (752 bytes), which exceeds the observed median by about 15%.

F, Bytes	ECDSA P-256	ML-DSA-44	ML-DSA-87	FN-DSA-512	SLH-DSA-256f
0	9523	267	138	606	20
45 (account model)	6666	264	137	590	20
118 (UTXO model)	4484	259	136	565	19
200	3278	254	134	540	19
300	2469	248	132	513	19
400	1980	242	131	488	19

Table 7. Summary of results.

#	Finding	Key Figures	Status
R1	Signature inflation spans two orders of magnitude within the standardized set	10.4× to 692.4× relative to ECDSA	Measured; byte counts do not depend on the platform
R2	The ML-DSA verification advantage over the ECDSA secp256k1 baseline is parameter-dependent and reverses at level 5	1.47× faster at ML-DSA-44; 1.67× slower at ML-DSA-87 (ratio 1.671, 95% CI [1.641, 1.696])	Measured on one platform; ratio crosses software paths (Section 2.6); comparator differs from that of [26] (Section 3.2)
R3	Pareto optimality must be assessed within NIST security level; five of the nine configurations are optimal in their own level	L1 FN-DSA-512; L2 ML-DSA-44; L3 ML-DSA-65; L5 ML-DSA-87 and FN-DSA-1024; the four dominated sets are all SLH-DSA	Derived from measured sizes and verification times
R4	The payload leader carries a disproportionate key-generation cost	FN-DSA-512 at 271× the ECDSA secp256k1 baseline; ML-DSA-44 at 1.3×	Measured on one platform; FN-DSA tied to liboqs 0.16.0
R5	In the first-order model, payload capacity, not verification throughput, is the binding constraint for every scheme measured	Headroom 124× to 1622× for the post-quantum configurations	Derived (first-order analytical bound); robust to F over 0–400 B; scope as in Section 3.5

Table 7. Summary of results.

#	Finding	Key Figures	Status
R1	Signature inflation spans two orders of magnitude within the standardized set	10.4× to 692.4× relative to ECDSA	Measured; byte counts do not depend on the platform
R2	The ML-DSA verification advantage over the ECDSA secp256k1 baseline is parameter-dependent and reverses at level 5	1.47× faster at ML-DSA-44; 1.67× slower at ML-DSA-87 (ratio 1.671, 95% CI [1.641, 1.696])	Measured on one platform; ratio crosses software paths (Section 2.6); comparator differs from that of [26] (Section 3.2)
R3	Pareto optimality must be assessed within NIST security level; five of the nine configurations are optimal in their own level	L1 FN-DSA-512; L2 ML-DSA-44; L3 ML-DSA-65; L5 ML-DSA-87 and FN-DSA-1024; the four dominated sets are all SLH-DSA	Derived from measured sizes and verification times
R4	The payload leader carries a disproportionate key-generation cost	FN-DSA-512 at 271× the ECDSA secp256k1 baseline; ML-DSA-44 at 1.3×	Measured on one platform; FN-DSA tied to liboqs 0.16.0
R5	In the first-order model, payload capacity, not verification throughput, is the binding constraint for every scheme measured	Headroom 124× to 1622× for the post-quantum configurations	Derived (first-order analytical bound); robust to F over 0–400 B; scope as in Section 3.5

3. Results

3.1. Measured Primitive Parameters

The measured parameters of all twelve configurations are given in Table 3.

Three properties of the measured set are worth isolating.

Signature inflation spans two orders of magnitude within the standardized set. Relative to the 72-byte ECDSA P-256 signature, signature length grows by factors of 10.4 (FN-DSA-512), 33.6 (ML-DSA-44), 64.3 (ML-DSA-87), and 692.4 (SLH-DSA-256f). The general statement that post-quantum signatures are larger—established across the migration literature [25]—is therefore too coarse to guide a design decision: the standardized schemes differ from one another by more than the smallest of them differs from the classical baseline.

Signature and public-key size move in opposite directions across families. SLH-DSA carries the smallest public key in the comparison—32 bytes at the 128-bit level, smaller than the 33-byte compressed ECDSA point—while carrying the largest signature. ML-DSA inflates both: 2592 and 4627 bytes at parameter set 87. FN-DSA is the only family whose signature (752 B at parameter set 512) is smaller than its public key (897 B). For a ledger that stores keys and signatures in different places, or retains them for different periods, these are materially different profiles, and an aggregate transaction-size metric conceals the difference. The same asymmetry has been reported as decisive for deployment of SLH-DSA on constrained hardware [46].

Verification does not uniformly become slower after migration. ML-DSA-44 verifies in 0.0238 ms against 0.0350 ms for ECDSA secp256k1, and FN-DSA-512 in 0.0398 ms. Within the lattice families, the trade is parameter-dependent: only ML-DSA-44 buys verification speed with bytes, while ML-DSA-65 and FN-DSA-512 stay within 14% of the ledger baseline. Only the hash-based family is slower on both axes simultaneously, by factors of 13.59 to 57.71 on verification (Figure 5). Figure 3 and Figure 4 show the key and signature lengths of the twelve configurations and the composition of one transaction under Equation (1).

Figure 3. Public-key, secret-key, and signature length of the twelve configurations (log scale). Data from Table 3.

Figure 3. Public-key, secret-key, and signature length of the twelve configurations (log scale). Data from Table 3.

Figure 4. Composition of one transaction under Equation (1): fixed fields (F = 118 B), public key, and signature, as a share of transaction size. Data from Table 3.

Figure 4. Composition of one transaction under Equation (1): fixed fields (F = 118 B), public key, and signature, as a share of transaction size. Data from Table 3.

Figure 5. Verification time relative to the ECDSA secp256k1 ledger baseline (log scale). Bars to the left of 1 verify faster than the baseline, bars to the right slower; error bars are 95% bootstrap confidence intervals. The ratios cross the classical/post-quantum implementation boundary and are specific to the measurement platform (Section 2.6). Data from Table 4.

Figure 5. Verification time relative to the ECDSA secp256k1 ledger baseline (log scale). Bars to the left of 1 verify faster than the baseline, bars to the right slower; error bars are 95% bootstrap confidence intervals. The ratios cross the classical/post-quantum implementation boundary and are specific to the measurement platform (Section 2.6). Data from Table 4.

3.2. The Verification-Speed Advantage Is Parameter-Dependent

A recent benchmarking study reports that ML-DSA can verify faster than ECDSA, especially at higher security levels: on an ARM-based laptop, 0.14 ms against 0.88 ms at level 5 [26]. In that study, the ECDSA comparator changes with the security level, from P-256 at level 1 to P-521 at level 5. A ledger keeps one curve whatever post-quantum parameter set it adopts, so the present comparison uses the ECDSA secp256k1 verifier at every level. Table 4 gives the verification time of the lattice-based and classical configurations relative to that baseline.

The advantage is real but decays monotonically with the parameter set and reverses at security level 5. Across the three ML-DSA parameter sets, the ratio moves from 0.680 to 1.071 to 1.671; the same pattern holds within FN-DSA, from 1.137 at parameter set 512 to 2.160 at 1024. The decay within each family compares parameter sets measured through one software path, whereas the point at which a family crosses the classical baseline depends on that baseline and on its path (Section 2.6). The within-family trend is therefore the more robust of the two findings. Any protocol design that assumes a verification surplus over the ledger’s ECDSA verifier at the highest security level proceeds on an assumption this measurement does not support. Since CNSA 2.0 mandates ML-DSA-87 specifically for national security systems [18], this is the parameter set for which the assumption is least safe.

The measurement is stable enough to carry the conclusion: across runs 5–7 the ML-DSA-87 verification median stays between 0.0567 and 0.0593 ms, a cross-run coefficient of variation of 2.29% (Table 2), and its ratio to ECDSA secp256k1 is 1.671 with a 95% CI of [1.641, 1.696].

Reconciliation with the reported figure. The two results answer different questions because they use different comparators. The level-5 figures in [26], 0.1402 ms for ML-DSA and 0.8847 ms for ECDSA, correspond to a ratio of about 6.3 taken against ECDSA over P-521; the present ratio of 1.671 is taken against ECDSA over secp256k1. Where the two studies share a comparator, they agree in direction: at the lowest level, against ECDSA P-256, ref. [26] reports 0.0529 ms for ML-DSA and 0.0788 ms for ECDSA on the ARM-based laptop, and the present measurement gives 0.0238 ms for ML-DSA-44 and 0.0578 ms for ECDSA P-256 (Table 3).

The level-5 ratio in [26] is therefore a ratio to P-521 verification on that platform rather than to a ledger verifier, and it does not transfer to a ledger whose curve stays fixed. Ratios of this kind depend on the comparator, the implementation, and the platform and should be re-measured in the target environment rather than cited. This applies equally to the ratios reported in Table 4.

3.3. Derived Bounds for a Block-Constrained Ledger

Applying Equations (1)–(5) at the reference configuration—1 MB (10⁶ B) block, 10-s interval, UTXO transaction model with F = 118 bytes—gives the first-order bounds of Table 5. They are analytical bounds computed from the measured parameters, not measurements of a deployed ledger. Capacity retention in Table 5 is the number of transactions per block under a scheme relative to the ECDSA secp256k1 baseline, and headroom is the ratio of verification-limited to capacity-limited throughput.

Capacity retention—the fraction of classical block occupancy surviving migration—ranges from 12.6% for FN-DSA-512 to 0.4% for SLH-DSA-256f. Expressed the other way, and within the first-order model of Equation (2), restoring the classical throughput of 4484 transactions per block would require enlarging the block from 1 MB to 7.9 MB under FN-DSA-512, 17.3 MB under ML-DSA-44, 32.9 MB under ML-DSA-87, and 224.4 MB under SLH-DSA-256f (Figure 6). These results place a quantitative bound on the qualitative narrowing of block-capacity margins identified in analyses of the transition [41].

Figure 6. Transactions per block (the first-order C1 bound of Equation (2)) as a function of block payload capacity, for the ECDSA secp256k1 baseline and five representative parameter sets (log–log scale). The dotted vertical line marks the reference 1 MB block; at that point the baseline achieves 4484 transactions per block, while restoring that same throughput requires 7.9 MB under FN-DSA-512, 17.3 MB under ML-DSA-44, 32.9 MB under ML-DSA-87, and 224.4 MB under SLH-DSA-256f (Section 3.3). Per-transaction sizes are given in the legend. Data from Table 5.

3.4. The Post-Quantum Design Space Is Multi-Criteria

Figure 7 plots the two throughput-relevant criteria against each other for the nine post-quantum configurations, with bubble area proportional to key-generation time. A configuration is Pareto-optimal within its security level if no other configuration at the same level achieves at least as many transactions per block and at least as high a verification rate, with a strict improvement on at least one of the two. A deployment fixes its security level before it selects a scheme, so the frontier is computed within each NIST level rather than across the whole set:

• at level 1, FN-DSA-512—565 transactions per 1 MB block, 25,126 verifications/s—dominates both SLH-DSA-128 variants on both axes;
• at levels 2 and 3 the single lattice set available in each is optimal by construction (ML-DSA-44, 259 transactions per block and 42,017 verifications/s; ML-DSA-65, 185 and 26,667, dominating SLH-DSA-192f), and at level 5 the choice remains open between ML-DSA-87 (136 transactions per block, 17,094 verifications/s) and FN-DSA-1024 (296 and 13,228), each optimal on one axis and both dominating SLH-DSA-256f.

Figure 7. Block occupancy (transactions per 1 MB block) against verification rate (verifications per second) for the nine post-quantum configurations; bubble area is proportional to the logarithm of key-generation time. Filled markers are Pareto-optimal within their NIST security level (L1–L5); hollow markers are dominated. Both axes are first-order quantities derived from the measured parameters (Equations (2) and (4)). Data from Table 3 and Table 5.

Figure 7. Block occupancy (transactions per 1 MB block) against verification rate (verifications per second) for the nine post-quantum configurations; bubble area is proportional to the logarithm of key-generation time. Filled markers are Pareto-optimal within their NIST security level (L1–L5); hollow markers are dominated. Both axes are first-order quantities derived from the measured parameters (Equations (2) and (4)). Data from Table 3 and Table 5.

Five of the nine configurations are therefore Pareto-optimal at their own level, and the four that are dominated are all hash-based. Across levels, the two axes trade off sharply: FN-DSA-512 admits 2.18 times more transactions per block than ML-DSA-44, which in turn verifies 1.67 times faster. Comparing across levels is not a deployment choice, however, so an across-set frontier understates the number of defensible options.

The key-generation column of Figure 8 introduces the axis on which the payload leader is weakest. Key generation costs 5.1303 ms for FN-DSA-512 against 0.0241 ms for ML-DSA-44, a factor of 213 between the level-1 and level-2 optima, and 271 relative to the ECDSA secp256k1 baseline. ML-DSA-44’s own key-generation penalty is a factor of 1.3. For a ledger in which addresses are generated frequently, or in which key generation runs on constrained hardware, this is a first-order constraint rather than a footnote.

Figure 8. Resource profile of each configuration relative to the ECDSA secp256k1 baseline for the six measured parameters. Cell values are ratios to the baseline; color is on a logarithmic scale, with white marking parity, blue lower and red higher cost. Data from Table 3.

The hash-based family exhibits the sharpest internal trade-off in the study. The two SLH-DSA parameter sets at the 128-bit level differ by a factor of 2.2 in signature size (17,088 B for the f variant against 7856 B for the s variant) and by a factor of 20.8 in signing time in the opposite direction (22.93 ms against 476.09 ms). SLH-DSA-128s signing is 18,102 times slower than ECDSA signing, excluding it from any interactive transaction path irrespective of its favorable signature size.

Selecting a post-quantum signature scheme for a ledger is therefore a parametric decision determined by which architectural constraint binds, not a universal ranking. This accounts for the divergence of independent engineering decisions across production ledgers without requiring any of them to be in error. It is also consistent with the divergent choices visible in the production and draft protocol designs reviewed in Section 1.4, in which post-quantum resilience is treated as a property of structural balance among coupled constraints rather than of primitive strength alone [9]. Figure 7 shows where each post-quantum configuration lies on the two axes.

Figure 8 shows all six measured parameters of each configuration relative to the baseline.

3.5. Payload Capacity Is the Binding Constraint in the First-Order Model

The final column of Table 5 carries the result with the clearest design consequence. In the first-order model of Equations (1)–(5), the binding constraint at the reference configuration is C1, transaction payload capacity, and not C2, verification throughput, for every scheme measured, including the classical baseline (Figure 9).

Figure 9. Payload-limited (C1, circles) and verification-limited (C2, diamonds) throughput of every configuration at the reference block size and interval (log scale). Both are first-order analytical bounds from Equations (3) and (4), not measured deployment throughput. The payload ceiling is the lower of the two in every case, so C1 binds. Data from Table 5.

The margin is wide. In the model, verification capability exceeds the achievable transaction rate by factors of 1622 for ML-DSA-44, 1257 for ML-DSA-87, and 445 for FN-DSA-512. Even the classical baseline is capacity-bound at 64×; migration to ML-DSA-44 amplifies the existing imbalance by a further factor of 25.

In the model, the crossover lies two to three orders of magnitude above the reference block data rate of 0.1 MB/s. Verification begins to bind only when the block data rate B/T exceeds approximately 161.8 MB/s for ML-DSA-44 and 44.4 MB/s for FN-DSA-512. Because the capacity ceiling scales with B/T while the verification ceiling is independent of both, the binding constraint and the headroom depend on block size and interval only through the block data rate B/T, up to the integer rounding in Equation (2). The crossover rates above therefore apply to any combination of the two parameters. At a 10-s block interval, these correspond to block sizes of approximately 1.62 GB and 444 MB, one to three orders of magnitude beyond current practice. The figures are moreover conservative, since verification here is single-threaded while production validators verify across multiple cores, which raises the C2 ceiling and moves the crossover further away. Figure 9 compares the payload-limited and verification-limited throughput of every configuration.

Scope of the result. The identification of C1 as binding is a result of the model examined and the parameters to which it was applied: a ledger whose capacity is set by a block size B and an inter-block interval T, block data rates B/T below the crossover values above, one signature and one public key per transaction, and fixed fields of 0–400 B (Section 3.6). It is not a statement about all DLT architectures. Ledgers whose signature load differs from one signature per transaction change the terms of Equations (1)–(5) and require their own evaluation; examples are permissioned ledgers that attach several endorsements to each transaction and consensus protocols in which every block carries signatures from many validators. The same applies to ledgers whose capacity is not set by block size and interval.

3.6. Sensitivity to the Transaction Model

Because derived quantities depend on the assumed size F of the non-cryptographic transaction fields, Table 6 reports block occupancy across a range of F values spanning plausible ledger formats.

Deviation from the UTXO model across the full range 0–400 bytes is +3.1 to −6.6% for ML-DSA-44, +1.5 to −3.7% for ML-DSA-87, +7.3 to −13.6% for FN-DSA-512 and +5.3 to 0.0% for SLH-DSA-256f. The post-quantum results are insensitive to F because the signature dominates the transaction by one to three orders of magnitude.

The classical baseline is not insensitive: it varies from 9523 to 1980 transactions per block, a range of +112.4 to −55.8%, because its 72-byte signature is comparable in size to F itself.

Two consequences for interpretation follow. First, the conclusions of Section 3.4 and Section 3.5—the Pareto structure and the identification of C1 as binding—rest on post-quantum payload magnitudes and are robust across the full range examined. Second, the capacity-retention percentages in Table 5, being ratios against the classical baseline, are sensitive to F and are valid for the stated UTXO model only; they should be recomputed for any ledger whose transaction format differs materially.

3.7. Summary of Findings

Table 7 collects the five findings established in Section 3.1, Section 3.2, Section 3.3, Section 3.4, Section 3.5 and Section 3.6, together with their key figures and evidentiary status.

4. Discussion

Two design implications follow from Section 3.5 for block-constrained ledgers within the scope stated there, and they are the operative output of this study.

Verification parallelization optimizes a non-binding constraint. A consensus protocol that exploits the verification speed of ML-DSA to shorten block validation is optimizing a resource already in surplus by two to three orders of magnitude. Because achievable throughput is bounded by Equation (3), which contains no verification term, the resulting gain in transaction rate is approximately zero at the block sizes examined. Such work is not without value: verification cost still sets the hardware a validator needs, and therefore the threshold for participating in validation, a channel treated as distinct from throughput in work on post-quantum consensus signatures [34]. Its benefit should not, however, be claimed in units of throughput.

Payload reduction is the primary lever on the binding constraint at a fixed block size and interval. Signature aggregation [47], compression, and transaction-format redesign act directly on TxSize in Equation (1) and therefore on capacity-limited throughput, and the measured inflation factors bound the gain available. Moving from ML-DSA-44’s 3850-byte transaction to FN-DSA-512’s 1767 bytes increases block occupancy by a factor of 2.18 (Section 3.4). The two schemes sit at different NIST security levels, so this is a change in security level rather than a same-level substitution; it is reported for illustration, not as a deployment recommendation. At level 5, the analogous move from ML-DSA-87 to FN-DSA-1024 increases occupancy by almost the same factor, 2.18, but FN-DSA-1024 verifies 1.29 times slower than ML-DSA-87 and carries a key-generation penalty of about 247-fold. Any compression method must therefore be evaluated against the transaction-size baseline of the security level actually deployed, not against the unmodified ML-DSA-44 figure. The aggregation techniques available for classical signatures do not transfer directly to the standardized post-quantum schemes [21], so the payload lever is presently narrower than in classical deployments. The block data rate B/T is the other quantity in Equations (2) and (3). It raises the C1 ceiling in proportion when blocks are enlarged, or the interval is shortened, but it also raises the propagation load associated with C3 and the growth of the stored ledger, and the model holds it fixed. Layer 2 designs [28] move transactions off the base layer and lie outside the model.

Factors outside the model. The six factors excluded from Equations (1)–(5) do not act on the same term, and their practical consequences differ accordingly. Table 8 sets out the term each one acts on and its consequence for the result of Section 3.5.

Table 8. Factors excluded from the first-order model and their consequence for the binding-constraint result.

Factor	Term It Acts on	Direction of Effect	Consequence for the C1 Result
Multi-core verification	C2: verification rate per validator	Raises the C2 ceiling, by up to the core count if scaling is linear	Strengthens it; headroom grows by the same factor
Batch verification	C2: verification cost per signature	Raises the C2 ceiling where the scheme supports it	Strengthens it
Signature aggregation	C1: Sig(s) in Equation (1)	Lowers TxSize and raises the C1 ceiling	Narrows the headroom; cannot reverse it for classical or lattice schemes; reported lattice aggregation rate about 0.9927 [21]
Compression and format redesign	C1: Sig(s), PK(s) and F	Lowers TxSize and raises the C1 ceiling	As for aggregation; public-key recovery reduces Falcon transactions by up to 17% [27]
Mempool dynamics	Realized throughput below both ceilings	Lowers realized throughput	None on which ceiling is lower
Fee-market feedback	Transaction mix and size distribution	Changes which transactions are included	None on the ceilings; affects the cost of each transaction

Note: Directions follow from Equations (1)–(5); magnitudes are not measured here except where stated.

Three practical implications follow from Table 8. First, the factors that act on C2 strengthen the C1 conclusion; their value lies in validator hardware requirements, not in throughput. Second, the factors that act on C1 narrow the headroom, but within limits that the data fix. The fixed fields alone (F = 118 B) cap throughput at 847 transactions per second at the reference configuration, below the slowest classical or lattice verification rate, 10,846 per second for Ed25519 (Table 5). No reduction confined to signatures and public keys can therefore make verification binding for these schemes. Only SLH-DSA-128f, SLH-DSA-192f, and SLH-DSA-256f verify more slowly than that cap (719, 495, and 496 per second), and for them the cryptographic payload would have to shrink by factors of 811, 425, and 596 before verification binds. Third, mempool dynamics and fee-market feedback determine how much of the ceiling is used and by which transactions, not where the ceiling lies.

The temporal dimension of the threat reinforces the priority. For ledger signatures, the relevant exposure is not the harvest-now–decrypt-later risk to encrypted data [11] but the public keys already visible on the ledger, which leave the funds they control open to forgery until those funds are moved (Section 1.2). Empirical evidence reported in Section 1 also indicates that cryptographically relevant vulnerabilities are already overrepresented among those exploited in practice [10]. Migration schedules are therefore constrained from both ends: the exposed supply argues for an early start, while the payload bound quantified here sets how fast the network can absorb the migration transactions.

Read as an information-management problem, the result relocates the difficulty. For block-constrained ledgers of the kind modeled here, migration to post-quantum cryptography is principally a storage and transmission problem rather than a computation problem. It should be planned with instruments appropriate to that class—format design, aggregation, and explicit capacity budgeting—rather than with computational optimization. Cryptographic agility [38], hybrid signatures [39], and agile transaction formats [40] are the mechanisms available; the parameters reported here determine which of them a given architecture needs.

Limitations. The bounds are first-order analytical bounds from a single platform, with the qualifications set out in Section 2.6 and the scope stated in Section 3.5; Table 8 gives the direction in which each factor outside the model would move them. Extension of the protocol to bare metal, to a second processor architecture, to post-quantum candidates beyond the NIST portfolio and to embedded and accelerated targets remains open.

5. Conclusions

Replacing the signature primitive of a distributed ledger with a post-quantum alternative cannot be treated as a cryptographic substitution alone: without adapting the protocol, it converts a cryptographic upgrade into a throughput regression. The differences among the standardized schemes are greater than the difference between the smallest scheme and the classical baseline. The resource profile of the chosen parameter set, rather than the availability of standardized primitives, therefore now determines what a migration can achieve.

This study identified which resource binds a block-constrained distributed ledger after post-quantum migration and by what margin. To answer that question, it measured the three NIST-selected post-quantum signature families across all nine parameter sets, together with three classical baselines, on a single platform under a single drift-controlled protocol. The measurements were then transformed into first-order capacity and verification ceilings for a block-constrained distributed ledger.

The main results are the following:

• Signature inflation spans two orders of magnitude within the standardized set, from 10.4 to 692.4 times the ECDSA P-256 signature, so the general statement that post-quantum signatures are larger is too coarse to guide a design decision;
• On the measured platform, the verification-speed advantage of ML-DSA over the ECDSA secp256k1 ledger verifier is parameter-dependent: it holds at parameter set 44 (1.47× faster) and reverses at parameter set 87 (1.67× slower);
• Pareto optimality must be assessed within each NIST security level: five of the nine configurations (FN-DSA-512, ML-DSA-44, ML-DSA-65, ML-DSA-87, and FN-DSA-1024) are optimal within their own level, while the level-1 leader FN-DSA-512 carries a 271-fold key-generation penalty, so no scheme dominates and selection is architecture-dependent;
• In the first-order model, and at the block sizes, intervals, and transaction formats examined, the binding constraint is payload capacity rather than verification throughput for every scheme, with verification headroom of 124 to 1622 times the achievable transaction rate for the post-quantum configurations, a result robust to the assumed transaction format over the range 0–400 bytes;
• Interleaved measurement with an independent control probe holds cross-run agreement to a mean coefficient of variation of 1.35%, although the control probe varied by up to 37% within a single run, because interleaving distributes gradual drift evenly across all schemes.

For block-constrained ledgers within the examined range, and at a fixed block size and interval, the practical consequence of these findings concerns where protocol effort should go. It should be directed at the transaction payload—aggregation, compression, format redesign—rather than at verification throughput, which is not the limiting resource in that model. The methodological consequence is that cross-platform performance ratios, including those reported here, should be re-measured rather than cited, and that benchmarking protocols in this field should control for measurement order explicitly.

Despite these contributions, the following limitations must be recognized. The bounds are first-order analytical bounds, not deployment measurements, and they apply to the ledger parameters examined rather than to all DLT architectures. They are derived from one x86-64 platform measured under WSL2 rather than on bare metal, and absolute timings and timing ratios may differ on other architectures and with other implementations. The classical and post-quantum schemes were also measured through different software paths, which affects every ratio between the two groups. Verification throughput is reported for a single thread, which makes the verification ceiling conservative. The FN-DSA figures track the pre-standardization Falcon reference design implemented in liboqs 0.16.0, because FIPS 206 remained in development throughout the measurement effort. They may change once FIPS 206 is finalized; the plan proposed for it in September 2026 specifies the signing procedure in fixed-point arithmetic [45]. The exclusion of the first four rounds of run 5 was decided after the step change had been observed; its effect is reported in Table A3. The model also excludes signature aggregation, compression, batch and multi-core verification, mempool dynamics, and fee-market feedback, whose directions of effect are set out in Table 8.

Further work should re-measure on bare metal and on a second processor architecture, add a native baseline measured outside the Python interpreter, extend the protocol to post-quantum candidates beyond the NIST portfolio and to embedded and accelerated targets, and re-measure the FN-DSA parameter sets once FIPS 206 is finalized.

These figures fit within a broader body of post-quantum signature performance evidence, from NIST’s round-three benchmarking of candidate schemes [48] to large-scale production measurements of post-quantum signature overhead on the public Internet [49]. In the end, the post-quantum resilience of a distributed ledger is a property of the balance among signature size, verification cost, and protocol design rather than of the strength of a single primitive.