Post-Quantum Authentication of IoT Data on Ethereum: Signatures, the Calldata Floor, and Device-Signed Merkle Roots

Post-Quantum Authentication of IoT Data on Ethereum: Signatures, the Calldata Floor, and Device-Signed Merkle Roots Ming-Fong Sie Master Program in Intelligent Computing and Big Data, Chung Yuan Christian University, Taoyuan, Taiwan

arXiv:2611.08108v1 [cs.DC] 5 Nov 2026

E-mail: mingfong@cycu.edu.tw Abstract Field devices deployed today will still be producing records when quantum computers may break their signatures, so systems that anchor IoT data on blockchains need a post-quantum (PQ) authentication path now. We measure its cost on Ethereum under the current execution rules, including the EIP-7623 calldata floor and the EIP-7825 transaction cap, and under the calldata repricing scheduled for the Glamsterdam upgrade. We combine device-side measurements of ML-DSA, Falcon, SLHDSA, LMS and XMSS, reproduced costs of open-source Solidity verifiers, a new standard-compliant LMS/HSS verifier for SHA-256 and SHA-256/192, and complete transactions on an Osaka-rule EVM, priced with today’s verifiers and with proposed precompiles. Three results stand out. Signing every record costs 8.7 times as much as ECDSA even with an ML-DSA precompile, because the calldata floor rather than verification sets the price. When each device signs a Merkle root over 100 records, a standard LMS verifier available today costs about 3,350 gas per record, against 245 gas for ECDSA in the same design, and it is unaffected by the scheduled repricing, which raises floor-bound designs by up to 1.9 times. With the proposed precompiles, ML-DSA-44 costs 1,031 gas per record, and a hybrid ECDSA and ML-DSA signature adds only 2.5%. Post-quantum device authentication is therefore deployable on Ethereum without protocol changes, provided that the latency of batching and the data-availability properties of the chosen variant fit the application.

Keywords: post-quantum cryptography; ML-DSA; Falcon; LMS; hash-based signatures; Ethereum; gas; EIP-7623; IoT data authentication; Merkle tree

1

Introduction

Blockchains are used to anchor data produced by IoT devices so that it can later serve as tamper-evident evidence, for instance of agricultural production backing a loan in supply chain finance [1–3]. The authenticity of each record rests on the signature of the device that produced it, today almost always an elliptic-curve signature. Shor’s algorithm [4] would let a cryptographically relevant quantum computer recover a device’s signing key from its public key and forge new records in its name. Records anchored before such a computer exists remain protected by their on-chain timestamps, provided that the chain’s own history remains trustworthy, which depends on Ethereum’s consensus signatures being migrated in time. The pressing problem is therefore the devices: field units deployed now will still be producing records when quantum attacks become feasible, and their firmware and key infrastructure are hard to update remotely [5]. Systems deployed today should therefore be crypto-agile and able to authenticate records with post-quantum (PQ) signatures. 1

NIST has standardized ML-DSA [6] and SLH-DSA [7], approved the stateful hash-based schemes LMS and XMSS [8–10], and is standardizing Falcon [11]. Ethereum verifies none of them natively; precompiles for ML-DSA [12, 13] and Falcon [14] are draft proposals not scheduled for any upgrade, and Solidity verifiers cost up to millions of gas [15–17]. PQ signatures are also one to two orders of magnitude larger than ECDSA signatures, and Ethereum now charges data-heavy transactions a calldata floor (EIP-7623 [18]), caps the gas of a transaction (EIP-7825 [19]), and will raise the floor further in the scheduled Glamsterdam upgrade (EIP-7976 [20, 21]). Signing a Merkle root over a batch of messages is a classical way to amortize expensive signatures [22], recently revisited for PQ signatures [23]. We do not propose the construction. We measure what PQ authentication of IoT records costs on Ethereum, with and without such batching, and analyse the choices that determine the cost: what is posted, where keys are kept, which scheme is used, and which data-availability, liveness and latency properties each variant has. Contributions. 1. Device-side costs of ML-DSA, Falcon, SLH-DSA, LMS, HSS and XMSS from C benchmarks on x86-64 and ARM64 cores and published Cortex-M4 measurements, with uplink bytes and memory per design (Section 6.1). 2. Verification costs: reproduced costs of the ZKNOX ML-DSA and Falcon verifiers, and a new RFC 8554/SP 800-208-compliant LMS/HSS verifier for n = 32 and n = 24, executed for real, with its worst case derived from a regression on Winternitz chain steps (Section 6.2). 3. End-to-end costs under current and scheduled rules for per-record signatures and device-signed roots, with replay protection, compared with ECDSA and P-256 in the same design, including hybrid ECDSA and PQ signatures (Sections 6.3 to 6.6). 4. A validated cost model with closed-form break-even points, and an analysis of data-availability tiers and of alternatives to contract-level verification (Sections 4, 6.4 and 7). Relation to our earlier study.

This article reuses the transaction-execution approach of our cost study

of classical schemes [1] (ECDSA, P-256, BLS and identity-based signatures), which is available on request to editors and referees. The PQ schemes, all designs and variants, the LMS/HSS verifier and all measurements reported here are new.

2

Background

2.1

Post-quantum signatures

ML-DSA [6, 24] is a lattice scheme with fast signing and verification and large keys and signatures (1,312 and 2,420 bytes for ML-DSA-44, NIST security category 2; ML-DSA-65 and -87 reach categories 3 and 5). Falcon [11] has smaller signatures (656 bytes in the compressed encoding for Falcon-512, category 1) but signs with floating-point Gaussian sampling. SLH-DSA [7, 25] relies only on hash functions (7,856 to 17,088 bytes at category 1). The stateful hash-based schemes LMS [9] and XMSS [10], approved in SP 800-208 [8], have small public keys, moderate signatures and hash-only verification; with SHA-256 2

(n = 32) they correspond to category 5 and with SHA-256/192 (n = 24) to category 3. Each one-time key may be used only once, so the signer must keep a counter reliably [26]; a tree of height h yields 2h signatures, and HSS stacks trees to extend this. Because the schemes sit at different categories, our comparisons are between the parameter sets a deployment would choose, and Tables 2 and 3 list the category of each.

2.2

Ethereum gas rules

A transaction pays 21,000 gas of intrinsic cost, plus calldata, plus execution. A zero calldata byte counts as one token and a non-zero byte as four. Under EIP-7623 [18],
Gtx = 21,000 + max 4T + E, 10T ,

(1)

where T is the number of tokens and E the execution gas. When the floor 10T binds, a non-zero byte costs 40 gas and additional execution is free as long as E < 6T . EIP-7825 [19] caps every transaction at 224 gas. The Glamsterdam upgrade [21], live on the Sepolia testnet since October 2026 and targeted for mainnet in the fourth quarter of 2026, schedules EIP7̄976, which raises the floor to 64 gas per byte for zero and non-zero bytes alike [20], together with resource-based intrinsic gas (EIP-2780 [27]), separately metered state-creation gas (EIP-8037 [28]) and higher state-access costs (EIP-8038 [29]). Blob data (EIP4844 [30]) has a reserve price of 1/16 of the execution base fee per blob gas (EIP-7918 [31]); contracts can read only a blob’s commitment, and consensus clients keep blob contents for 4,096 epochs, about 18 days. Under EIP-4444 [32], execution clients need not serve old block bodies or receipts.

2.3

Proposed PQ precompiles

EIP-8051 [12] proposes ML-DSA-44 verification at 4,500 gas with a pre-expanded 20,512-byte public key. EIP-8355 [13] takes standard encodings and charges 6,500, 9,000 and 13,500 gas for ML-DSA-44, -65 and -87 plus 6 gas per 32-byte message word. EIP-8052 [14] splits Falcon-512 verification into hashto-point (1,000 gas) and core (2,000 gas) precompiles. All three are drafts and none is scheduled for an upgrade; no precompile has been proposed for SLH-DSA, LMS or XMSS. P-256 verification is available since Osaka (EIP-7951 [33], 6,900 gas).

3

Related work

Fernández-Caramés and Fraga-Lamas [34] survey the exposure of blockchains to quantum attacks. Allende et al. [35] added a Falcon-512 signature to transactions of an Ethereum-based permissioned network and compared verification by contracts, a modified opcode and precompiles. Kysil et al. [17] implement W-OTS+, XMSS, SPHINCS+ and MAYO verifiers in the EVM with Keccak instead of the standardized hash functions, report 222,114 gas for W-OTS+ (w = 4), 4.36 million gas for XMSS and 11.6 million gas for SPHINCS+, and evaluate an optimistic “naysayer” mode in which signatures are only checked when challenged; they also note that a STARK proof costs about 5 million gas to verify on Ethereum. A SPHINCS variant with limited-signature parameters has been reported at about 150,000 gas [36]. PQ transaction signing via account abstraction and precompiles is under discussion [37], with signature aggregation identified as the binding constraint [38]; Virani [39] derives analytical gas 3

models for verification in smart accounts; and ZKNOX provides Solidity verifiers for Falcon and MLDSA [15, 16]. These works target transaction authorization or single verifications and do not quantify costs under the calldata floor and transaction cap. Our LMS/HSS verifier differs from the hash-based verifiers above in being compliant with RFC 8554 and SP 800-208 (SHA-256 and SHA-256/192), so that it verifies signatures from standard signers and hardware. Aguilar-Melchor et al. [23] formalize batch signatures, in which one signature authenticates a Merkle tree over many messages, and show that they let slow PQ signers reach high throughput in TLS. Our device-signed roots are an instance of this construction; we study its on-chain consequences. McGrew et al. [26] discuss state management for hash-based signatures. On the device side, pqm4 [40, 41] benchmarks PQ schemes on Cortex-M4 microcontrollers, Campos et al. [42] compare LMS and XMSS on a Cortex-M4, Pornin [43, 44] presents constant-time Falcon implementations for it, and liboqs [45] provides portable implementations. Our earlier study [1] found batched ECDSA with Merkle anchoring to be the cheapest classical design; ECDSA and P-256 in the same design serve as baselines here.

4

System model, threat model and designs

Setting.

IoT devices, such as the camera units of an agricultural monitoring system [3], produce 116-

byte records. An untrusted aggregator collects them and submits them to an anchoring contract on Ethereum; submission is permissionless, so a device or any other party can submit a signed root itself, and an aggregator cannot censor it. A registration authority (RA) registers each device’s public key; the contract stores a 32-byte commitment to it and, optionally, the key itself. The contract has no administrator or upgrade key. Hashing and encodings.

All on-chain hashing uses Keccak-256. A record leaf is H(0x00∥salt∥record),

where an optional per-record salt prevents brute-forcing low-entropy sensor records from published leaves; internal nodes are H(0x01∥ℓ∥r) [46], and an odd node is promoted unchanged to the next level. The batch tree over the accepted device roots uses the same rule. Per-record signatures bind (chainid, contract, cdev , idx, s, leaf ) with a per-device sequence number s, and device-signed roots bind M = H(chainid ∥ contract ∥ cdev ∥ idx ∥ e ∥ R ∥ k),

(2)

with key commitment cdev , epoch e, Merkle root R and record count k. The contract accepts s and e only if they exceed the device’s last accepted value. Threat model.

The adversary controls the aggregator and the network, may at some future time run a

quantum computer, and then knows every classical key whose public key has been revealed. The contract must accept only records signed by registered devices. • Registration. Registrations are authorized by an RA post-quantum signature over (chainid, contract, "register", idx, H(pk)) rather than by the RA’s ECDSA account. We evaluate ML-DSA-44 and LMS for the RA key; with LMS, the RA is stateful too, but registrations are rare. Revoking or rotating a device key and rotating the RA’s own key require messages signed with the current RA key, which is set once at deployment.

4

(a) Per-record signatures (PR) r1

IoT device

signs every record

r2

Aggregator

calldata

Aggregator

calldata

batches n records

r3

Contract

per transaction: n signatures × |σ | bytes n verifications ×V gas

Contract

per transaction: m signatures × |σ | bytes m verifications ×V gas optional: n = mk leaves × 32 B

verifies n signatures, anchors one Merkle root

. . k records, . k signatures

(b) Device-signed Merkle roots (DR) R

IoT device

hashes k records, signs the root once

batches m devices

verifies m root signatures (leaves optional)

h(r1 ) · · · h(rk ) post-quantum signature (|σ |: 656 B for Falcon-512 to 17,088 B for SLH-DSA-128f) V : verification gas

Figure 1: (a) Per-record signatures (PR): one signature per record. (b) Device-signed Merkle roots (DR): each device signs one root over its k records, and the contract verifies one signature per device. DR-L posts the leaf hashes in calldata, DR-B in a blob, and DR-0 and DR-0C post only the signed root. • Replay and liveness. Monotonic s and e prevent replay across batches, contracts and chains. Because e only has to increase, a withheld root leaves a visible gap but does not block later roots. For LMS the epoch can be the leaf index q; for two-level HSS it is the global index qtop 2hbottom + qbottom , which is monotonic across levels. • State rollback. A one-time key can be reused after a power loss before the counter is persisted, after restoring a backup, cloning a device or reflashing firmware. Devices should keep the counter in a monotonic hardware counter or secure element, advance it by a safety margin at boot, and never clone key material; if the epoch is the leaf index, the contract also refuses a second root signed with the same index. • Residual dependencies. The aggregator’s transaction signature remains ECDSA; a quantum adversary could forge it to submit or withhold batches, but not to make the contract accept unsigned records. Anchored history ultimately depends on Ethereum’s consensus (BLS) signatures, which are outside our scope. Designs.

With per-record signatures (PR), each record is signed and verified individually. With device-

signed Merkle roots (DR), each device signs M over the root of its k records of an epoch, and the contract verifies one signature per device and stores the root over all accepted device roots of the transaction, so that any record can be proven on-chain with a two-level Merkle path. We evaluate four DR variants (Figure 1): DR-L posts the k leaves, from which the contract recomputes R; DR-0 posts only (R, k, e), the signature and the key, and logs (idx, e, R, k) in an event; DR-0C is DR-0 with the key stored once on-chain as contract code (SSTORE2) and read with EXTCODECOPY; and DR-B is DR-0 with the leaves in a blob whose versioned hash the contract records. For ECDSA, the “on-chain key” is the 20-byte address, since the key itself is recovered from the signature. Data availability.

The variants differ in what is published and for how long it is guaranteed to remain

retrievable (Table 1). Only contract storage is permanent. Calldata and event logs are both part of the chain’s history, which execution clients may prune under EIP-4444 [32]; beyond that horizon, both

5

Table 1: Data-availability tiers of the designs. Tier

Content in our designs

Guaranteed retention

Who must keep it beyond

Contract storage Calldata (block bodies) Event logs (receipts) Blobs Off-chain

batch roots, epochs, key commitments, stored keys DR-L leaves; signatures and keys device roots (idx, e, R, k) DR-B leaves records, images; DR-0 leaves

permanent (state) published to all at submission; prunable under EIP-4444 as calldata about 18 days none

nobody archive nodes, indexers, parties as calldata parties, blob archivers parties

depend on archive nodes, indexers or the parties’ own copies. The distinction between DR-L and DR-0 is therefore one of publication, not retention: DR-L publishes every leaf to all observers at submission time, so anyone can keep a copy, whereas with DR-0 the leaves are never published and only the parties hold them. Cost model.

For a DR transaction with m devices, Equation (1) gives per-record costs of DR-L: DR-0:

c(k) ≈ A/k + L, c(k) ≈ A/k,

A = 21,000/m +V + cb (|σ | + |pk|) + gdev ,

(3) (4)

where V is the verification gas, cb the calldata price per byte (16, or 40 when the floor binds), |pk| = 0

for DR-0C (whose key read is part of gdev ), gdev the per-device overhead (commitment SLOAD, 2,100 gas

when cold; epoch update; key hash; event; encoding), and L the cost of posting and hashing one leaf. The relative premium of a PQ scheme over ECDSA in DR-L is then (APQ − AEC )/(AEC + kL), which falls below a target x for

k ≥ k∗ (x) =

APQ − (1 + x)AEC , xL

(5)

whereas in DR-0 the premium is the constant ratio APQ /AEC . Section 6.4 fits A and L to the measurements. Stateful schemes under DR.

DR reduces signing to one signature per device per epoch. With daily

roots, an LMS tree of height 10 lasts 1,024 days (2.8 years), height 15 about 90 years, and a two-level HSS of two height-10 trees about 2,900 years. The device persists its counter once per epoch rather than once per record: with daily roots that is 365 writes per year, against about 52,000 for a record every ten minutes, a difference that matters for embedded flash rated for 104 –105 erase cycles per sector. We use LMS rather than XMSS because an LMS chain step costs one hash, whereas an XMSS chain step also derives a key and a bitmask, which roughly triples the hashing in verification [42].

5

Methodology

Device side.

Stateless schemes are timed with liboqs 0.16.0 [45] C benchmarks (mean of 1 s runs) on

an x86-64 Xeon core, ECDSA with libsecp256k1 and P-256 with OpenSSL; the liboqs Python binding gave results within 10% of the C figures. The same Python benchmark was run on an ARM64 Neoverse N2 core of a GitHub-hosted runner, through a workflow included in the repository. Stateful schemes are timed with liboqs’s C benchmark. Cortex-M4 figures are taken from pqm4 [41] (commit 6ff2be9), Campos et al. [42] (LMS, HSS and XMSS on an STM32F4 with SHA-256, reference implementations without tree caching) and Pornin [43, 44] (Falcon); times are given at 168 MHz. 6

Verifiers.

We reproduce the ZKNOX verifiers [15, 16] with Foundry 1.8.7 [47] using each repository’s

settings and test vectors (ETHDILITHIUM commits f9f4fe1 and f85ca80, ETHFALCON 43ac863). Our LMS/HSS verifiers use the SHA-256 precompile: one specialized for n = 32 and a generalized one for n ∈ {24, 32}, both validated against an independent implementation [48] on valid, tampered and wrongmessage inputs. The generalized verifier costs about 21% more than the specialized one for n = 32; we therefore compare n = 24 with n = 32 within the generalized verifier. LMS verification walks each Winternitz chain from the signed digit to its end, so its cost depends on the message; we regress the gas of 40 LMS-H10-W4 signatures on the number of chain steps and evaluate the fit at the maximum (Section A). Transactions.

Signed EIP-1559 transactions run on the EthereumJS VM 10.1.3 [49] with the Osaka

hardfork (EIP-7623, EIP-7825); contracts use Solidity 0.8.28 (optimizer 200 runs, via-IR). Calldata contains genuine keys and signatures. ECDSA is verified for real with ecrecover and LMS/HSS with our verifiers. ML-DSA, Falcon, SLH-DSA, P-256 and hybrid ECDSA+PQ signatures are priced by substitution: the contract calls an empty account with the full input, so that all costs other than verification are measured, including building the input in memory; we subtract the cost of these calls (2,600 gas for the first, cold, access and 100 for each later one) and add, per verification, the verification gas plus a 100-gas call per precompile invoked, since precompiles are always warm under EIP-2929 [50] and charge for their input only through their price. Hybrid signatures carry an ECDSA signature appended to the PQ signature and are charged the PQ price plus ecrecover. Solidity-verifier costs from Foundry already include the cold access, ABI encoding and the callee’s memory. Transaction gas is recomputed with Equation (1), which matched the VM on all 2,021 stub transactions. Ten LMS signatures measured in isolation predicted a ten-device transaction carrying the same signatures within 0.07% of its real execution. Configuration.

All measurements use the revised contract with replay protection and the relaxed epoch

rule of Section 4. Every device submits once before measurement, so that counter updates are steadystate writes. Batches contain 10 devices, except DR-L at k = 1,000, which uses 4 devices because 10 exceed the cap. The largest batch per transaction is found by bisection on actual transactions; for PR, records are split evenly over 10 devices.

6

Results

6.1

Device-side costs

Figure 2 and Tables 2 and 3 summarize the device side. On an x86-64 core, ML-DSA signs in 0.06– 0.11 ms, a few times slower than ECDSA, and verifies faster than P-256. The relative cost depends on the architecture: on ARM64, ML-DSA-44 signing is 1.5 times slower than on x86-64, whereas Falcon512 and SLH-DSA are faster. On a Cortex-M4, ML-DSA-44 signs in 23–72 ms depending on the stack budget, Falcon-512 in about 80 ms with 11 KB of RAM, and SLH-DSA-128f and -128s in 2.2 and 46 s. Per-record signing at one record every ten minutes would be feasible even for SLH-DSA; the argument for root signing on devices is energy and uplink volume, not throughput.

7

sign

(a) sign / verify (ms)

verify

64

0.0219 / 0.07

2,420

0.0606 / 0.018

3,309

0.0888 / 0.029

4,627

0.106 / 0.042

656

0.206 / 0.036

1,271

0.433 / 0.067

17,088

22.9 / 1.5

7,856

476 / 0.51

10−2

10−1

public key

65

0.0201 / 0.031

ECDSA secp256k1 ECDSA P-256 ML-DSA-44 ML-DSA-65 ML-DSA-87 Falcon-512 Falcon-1024 SLH-DSA-128f SLH-DSA-128s

signature

(b)

100

101

102

103

104

Time on one x86-64 core, C implementations (ms, log scale)

100

1,000

10,000

100,000

Size (bytes, log scale)

Figure 2: Stateless schemes on one x86-64 core (C implementations: liboqs, libsecp256k1, OpenSSL). (a) Mean signing and verification time; labels give sign / verify in ms. (b) Signature and public-key sizes. Table 2: Stateless schemes on the device side. x86-64: C implementations, mean. ARM64: liboqs Python binding, median. Cortex-M4: published average signing cycles at 168 MHz, with the implementation used. Cat.: NIST category. x86-64 (ms) ARM64 (ms)

Cortex-M4

Scheme

Cat.

Sign Verify

Sign Verify Implementation Sign (Mcyc.) at 168 MHz Stack / code (KB)

ECDSA secp256k1 ECDSA P-256 ML-DSA-44

– – 2

ML-DSA-65 ML-DSA-87 Falcon-512 Falcon-1024 SLH-DSA-128f SLH-DSA-128s

3 5 1 5 1 1

0.020 0.031 0.028 0.042 – 0.022 0.070 – – – 0.061 0.018 0.091 0.041 pqm4 m4f pqm4 m4fstack 0.089 0.029 0.130 0.067 pqm4 m4fstack 0.106 0.042 – – – 0.207 0.036 0.174 0.028 Pornin [44] 0.433 0.067 – – – 22.9 1.53 19.6 1.20 pqm4 476 0.51 407 0.41 pqm4

– – 3.94 12.13 24.42 – 13.45 – 368.6 7,658

– – 23 ms 72 ms 145 ms – 80 ms – 2.2 s 45.6 s

– – 43.8 / 19.1 5.0 / 24.3 6.5 / 23.6 – RAM ≈11 – 2.4 / 4.8 2.5 / 5.1

For the stateful schemes, signing cost depends strongly on the implementation and tree shape. Reference LMS implementations without tree caching recompute the tree for every signature: 0.5 s for height 10 on the desktop and 22.6 s on a Cortex-M4, and 3 minutes with w = 8. A two-level HSS of height 5+5 signs in 1.6 s on the Cortex-M4, and traversal algorithms with cached nodes, used by liboqs’s XMSS (10.5 ms on the desktop), avoid the recomputation altogether. For daily roots, even 22.6 s of computation per day is small, but a device should use HSS with small subtrees or a caching implementation. DR also reduces what the device sends: an ML-DSA-44 device transmits 2,536 bytes per record with per-record signatures, against 140 bytes for k = 100 and 118 bytes for k = 1,000 with DR, an 18- to 22fold reduction; the device keeps the Merkle frontier, (⌈log2 k⌉ + 1) · 32 bytes (352 bytes for k = 1,000),

or 32k bytes if it buffers leaf hashes.

6.2

Verification costs

Table 4 lists the verification costs. Our reproductions match the published ML-DSA figures within 1.5% (0.3% for the optimized branch). NIST-compliant ML-DSA-44 and Falcon-512 cost 1.2 and 4.8 million gas; EVM-friendly variants, which replace SHAKE by Keccak and are not interoperable with standard signers, cost 0.85 and 1.55 million. Our standard-compliant LMS verifier costs about 0.27 million gas on average, four times less than the optimized NIST ML-DSA verifier and sixteen times less than the 8

Table 3: Stateful hash-based schemes. x86-64: liboqs 0.16.0 (C). Cortex-M4: Campos et al. [42], SHA256, reference implementations without tree caching (HSS there with two trees of height 5). Signature sizes include the 4-byte HSS header; plain LMS signatures are 4 bytes shorter. x86-64 Scheme

Cat. Signatures Key gen.

LMS H10, w = 4 (n = 32) LMS H10, w = 8 (n = 32) LMS H15, w = 4 (n = 32) HSS, two levels, w = 4 (n = 32) LMS H10, w = 4 (n = 24) XMSS-SHA2 10 256

5 5 5 5 3 5

210

210 215 220 / 210 210 210

Sign

Cortex-M4 Verify

Sign

Verify Signature (B)

0.49 s 0.50 s 0.24 ms 22.6 s 16 ms 2,512 3.7 s 3.7 s 1.70 ms 180 s 133 ms 1,456 15.1 s 15.0 s 0.23 ms – – 2,672 0.47 s 0.99 s 0.47 ms 1.6 s 18 ms 5,076 / 4,756 – – – – – 1,504 2.6 s 10.5 ms 1.32 ms 141 s 78 ms 2,500

Table 4: Verification gas per signature. Solidity ML-DSA and Falcon: published values next to our reproduction (“bench”: repository benchmark vector; “KAT”: known-answer test). LMS/HSS: our verifiers. Precompiles: proposed or deployed prices. Scheme

Implementation

ML-DSA-44

Solidity, NIST (ZKNOX main / optimized branch) Solidity, EVM-friendly (ZKNOX main / optimized branch) Precompile EIP-8355 (6,500 + 6 per message word) / EIP-8051 Solidity, NIST-compliant / EVM-friendly (ZKNOX) Precompile EIP-8052 Solidity, specialized (this work) Solidity, specialized (this work) Solidity, specialized (this work) Solidity, generalized (this work) Precompile EIP-7951 / ecrecover

Falcon-512 LMS-H10-W4, n = 32 LMS-H15-W4, n = 32 HSS (H10-W4)2 , n = 32 LMS-H10-W4, n = 24 / n = 32 P-256 / ECDSA

Published

Reproduced / measured

8.1M / 1,196,707 4.9M / 847,709 6,506 / 4,500 – 3,000 – – – – 6,900 / 3,000

8,128,360 / 1,192,929 (KAT) 4,833,650 / 845,438 (KAT) – 4,818,843 / 1,547,336 (bench) – mean 268,677 (246,817–294,342; 40 signatures); worst case 429,900 median 280,790 (257,155–294,955; 12 signatures) median 581,403 (557,297–605,010; 12 signatures) median 270,743 / 327,684 (6 signatures each) –

Keccak-based XMSS verifier of [17]. Its cost is linear in the number of Winternitz chain steps: 111,315 gas plus 322 gas per step (R2 = 0.996), with 420–570 steps observed and 990 in the worst case, which costs 429,900 gas, 60% above the mean; aggregators must set gas limits for this case. A larger tree adds little (height 15: +4%), two-level HSS doubles the cost, and SHA-256/192 (n = 24, category 3) reduces it by 17% and the signature by 40% compared with n = 32 in the same verifier. A Keccak instantiation would save roughly 140 gas per chain step at the price of interoperability.

6.3

Per-record signatures

Table 5 and Figure 3 report the PR design. With the proposed precompiles, an ML-DSA-44 record costs 112,490 gas (8.7 times ECDSA) and a Falcon-512 record 39,513 gas (3.0 times): the floor binds, every byte of signature and key costs 40 gas, and the verification adds nothing. With today’s Solidity verifiers a transaction holds 10 to 50 PQ-signed records. Whether a per-record cost of 10−4 ETH is acceptable depends on the application (Section 6.6); at scale, the decisive limit is capacity, about 530 ML-DSA-44 records per 60-million-gas block. Finding 1 Under EIP-7623, per-record PQ authentication is priced by signature and key size, not by verification; cheaper precompiles alone cannot make it competitive with ECDSA.

6.4

Device-signed Merkle roots

Tables 6 to 8 and Figure 4 report the device-root designs, each against ECDSA in the same design. With leaves posted (DR-L), the schemes with precompiles and LMS approach the cost of one leaf at k = 1,000: ML-DSA-44 with a precompile costs 5% more than ECDSA (82% more at k = 100), Falcon-512 2%, 9

Table 5: Per-record signatures (PR) with replay protection: one record per transaction, gas per record in batches of 50 (10 devices, 5 records each), and the largest batch under the cap (records split evenly over 10 devices, e.g. 520 = 10 × 52; ≈: estimated from the per-record cost). SLH-DSA rows are lower bounds (data cost only). Scheme

Verification

Individual

Per record, n = 50

Max. records/tx

ECDSA secp256k1 ML-DSA-44

ecrecover Solidity, NIST (optimized) Solidity, EVM-friendly (optimized) Precompile EIP-8355 Precompile EIP-8355 Precompile EIP-8355 Solidity, EVM-friendly Precompile EIP-8052 Solidity (this work) lower bound (data only) lower bound (data only)

64,675 1,313,896 966,405 177,660 238,620 317,090 1,633,265 91,780 360,215 ≥344,060 ≥712,250

12,971 >cap >cap 112,490 153,188 210,833 >cap 39,513 326,555 ≥319,585 invalid (>cap)

1,430 ≈13 ≈18 160 – – ≈10 520 50 – –

calldata (standard price)

EIP-7623 floor top-up

ML-DSA-65 ML-DSA-87 Falcon-512 LMS-H10-W4 SLH-DSA-128s SLH-DSA-128f

execution

12,971

ECDSA secp256k1

39,513

Falcon-512, EIP-8052

112,490

ML-DSA-44, EIP-8355

153,188

ML-DSA-65, EIP-8355

210,833

ML-DSA-87, EIP-8355

326,555

LMS-H10-W4, Solidity

319,585

SLH-DSA-128s, data only 0

50,000

100,000

150,000

200,000

250,000

300,000

350,000

Gas per record (batches of n = 50 records from 10 devices, replay-protected contract)

400,000

Figure 3: Composition of the per-record cost of PR batches (n = 50, 10 devices, replay-protected contract). Where the EIP-7623 floor binds, the hatched part is its surcharge over the standard calldata price, and execution below 6T , including verification, adds nothing. and our LMS verifier 22% (19% with n = 24). With only roots posted (DR-0, DR-0C), costs fall as 1/k and the relative premium is larger, from 1.6 times ECDSA (Falcon-512 with precompile) to 65 times (Falcon-512 in Solidity), while absolute costs stay small: at k = 100, 1,031 gas per record for ML-DSA44 with precompile and on-chain key, 3,350 gas for LMS (4,963 in the worst case) and 2,991 gas for LMS with n = 24. P-256, the curve of most IoT secure elements, costs 3% (DR-L) to 18% (DR-0) more than secp256k1. A hybrid ECDSA and PQ signature, as recommended for the transition period, adds at most 2% in DR-L and 2.5% (ML-DSA-44) to 11% (Falcon-512) in DR-0C over the PQ signature alone. The cost model of Equation (3) predicts the 4-device, k = 1,000 measurements within 0.4–10.5%, underestimating them slightly because memory costs grow superlinearly in very large transactions. It gives a direct rule for choosing k: for the premium over ECDSA to fall below 25% with leaves posted, Falcon-512 with a precompile needs about 120 records per root, ML-DSA-44 about 390, LMS about 800–900, and NIST ML-DSA in Solidity about 3,700. Finding 2 Device-signed roots make post-quantum authentication of IoT records deployable on Ethereum today. A standard LMS verifier in Solidity costs 3,350 gas per record (4,963 in the worst case) at k = 100 when only roots are posted, and 1,791 gas at k = 1,000 when every record hash is published; 10

Table 6: DR-L (leaves posted, keys in calldata): gas per record and factor relative to ECDSA in the same design. 10 devices per transaction; † 4 devices. Scheme

k = 10 k = 100 k = 1,000† vs. ECDSA (k=100 / 1,000)

Verification

ECDSA secp256k1 ECDSA P-256 ML-DSA-44

ecrecover 3,821 EIP-7951 4,273 Precompile EIP-8355 16,834 Solidity, NIST (optimized) 128,866 ML-DSA-65 Precompile EIP-8355 22,942 Falcon-512 Precompile EIP-8052 8,227 Solidity, EVM-friendly 160,724 Hybrid ECDSA + ML-DSA-44 EIP-8355 + ecrecover 17,170 Hybrid ECDSA + Falcon-512 EIP-8052 + ecrecover 8,547 LMS-H10-W4, n = 32 Solidity (this work) 34,607 LMS-H10-W2, n = 32 Solidity (this work) 38,747 LMS-H10-W8, n = 32 Solidity (this work) 152,155 LMS-H10-W4, n = 24 Solidity, generalized (this work) 31,444 SLH-DSA-128s lower bound (data only) 33,447

1,558 1,604 2,831 14,097 3,443 1,972 17,267 2,867 2,003 4,675 5,047 16,481 4,345 4,494

1,473 1,478 1,551 2,738 1,586 1,505 3,050 1,556 1,510 1,791 1,829 2,928 1,747 1,615

1/1 1.03 / 1.00 1.82 / 1.05 9.0 / 1.86 2.2 / 1.08 1.27 / 1.02 11.1 / 2.07 1.84 / 1.06 1.29 / 1.03 3.0 / 1.22 3.2 / 1.24 10.6 / 1.99 2.8 / 1.19 2.9 / 1.10

Table 7: Root-only designs: gas per record with keys in calldata (DR-0) or stored on-chain (DR-0C), factor relative to the cheaper ECDSA root-only variant (k = 100), and the largest number of devices per transaction. LMS-H15 and HSS were measured in a separate run with the same contract. Scheme

Verification

DR-0 (key in calldata) DR-0C (key on-chain) vs. ECDSA Max. devices/tx k=100 k=1,000 k=100 k=1,000 (k=100) (key placement)

ECDSA secp256k1 ecrecover 245 ECDSA P-256 EIP-7951 290 ML-DSA-44 Precompile EIP-8355 1,555 ML-DSA-44 Precompile EIP-8051 (expanded key) – ML-DSA-44 Solidity, NIST (optimized) 12,746 ML-DSA-65 Precompile EIP-8355 2,167 Falcon-512 Precompile EIP-8052 695 Falcon-512 Solidity, EVM-friendly 15,934 Hybrid ECDSA + ML-DSA-44 EIP-8355 + ecrecover 1,590 Hybrid ECDSA + Falcon-512 EIP-8052 + ecrecover 726 LMS-H10-W4, n = 32 Solidity (this work) 3,350 worst case 4,963 LMS-H10-W4, n = 24 Solidity, generalized (this work) 2,991 LMS-H15-W4, n = 32 Solidity (this work) 3,456 HSS (H10-W4)2 , n = 32 Solidity (this work) 6,884 SLH-DSA-128s lower bound (data only) 3,217

25 284 29 322 156 1,031 – 1,142 1,275 12,572 217 1,386 69 387 1,593 15,828 159 1,057 73 428 335 3,455 496 – 299 3,026 346 – 688 – 322 3,204

28 32 103 114 1,257 139 39 1,583 106 43 345 – 303 – – 320

1 1.18 4.2 4.7 51 5.7 1.6 65 4.3 1.7 13.7 20.3 12.2 14.1 28.1 13.1

689 (calldata) 656 (calldata) 166 (on-chain) 58 (on-chain) 13 (on-chain) – 404 (on-chain) 10 (on-chain) 161 (on-chain) – ≈50 (calldata) ≈33 (calldata) 56 (calldata) – – –

for LMS, the premium over ECDSA in the same design ranges from 19% to about 20 times, depending on the variant, k and hash length.

6.5

Key registration and storage

Table 9 lists registration costs. Storing an ML-DSA-44 key on-chain costs 309,403 gas more than registering its commitment and saves about 52,000 gas per root submission, paying off after six submissions; it also makes EIP-8051’s 20,512-byte expanded keys usable (114,142 gas per device root). Under Glamsterdam, EIP-8037 meters state creation separately and EIP-8038 raises state-access costs [28, 29], which will make on-chain key storage, registration and the per-batch root write more expensive; the break-even shifts accordingly.

6.6

Sensitivity, rollups and fees

Calldata repricing.

Under the Glamsterdam floor, floor-bound designs become 1.4 to 1.9 times more

expensive, whereas LMS is unaffected (Table 10); LMS’s premium over ECDSA falls from 3.0 to 2.0 11

Table 8: Cost model for DR-L, Equation (3), fitted on k = 10 and k = 100 (10 devices): per-device term A, per-leaf term L, error of the prediction at k = 1,000, and the smallest k at which the premium over ECDSA falls below 25% and 10% (Equation (5)). A (gas)

L (gas)

Error at k=1,000

k∗ (25%)

k∗ (10%)

25,144 29,656 155,589 1,275,211 69,500 158,922 332,578 301,100 321,700

1,307 1,307 1,275 1,345 1,277 1,278 1,349 1,334 1,277

−9.4% −9.3% −7.6% −4.2% −10.3% −7.5% −5.9% −6.2% −0.8%

– 0 389 3,699 119 399 893 809 909

– 15 1,003 9,276 328 1,027 2,260 2,050 2,303

Scheme / verification ECDSA, ecrecover P-256, EIP-7951 ML-DSA-44, EIP-8355 ML-DSA-44, Solidity NIST Falcon-512, EIP-8052 Hybrid ECDSA + ML-DSA-44 LMS-H10-W4, n = 32 LMS-H10-W4, n = 24 SLH-DSA-128s (data only) (a) leaves posted (DR-L)

(b) root only (DR-0); PQ keys stored on-chain

1,000,000

Gas per record

100,000 10,000 1,000

ECDSA secp256k1 (same design) ML-DSA-44, precompile EIP-8355 Falcon-512, precompile EIP-8052 LMS-H10-W4, Solidity (today) ML-DSA-44, Solidity NIST (today) Falcon-512, Solidity EVM-friendly (today)

100 10 1

1

10

100

Records per device-signed root, k

1,000

1

10

100

1,000

Records per device-signed root, k

10,000

Figure 4: Device-signed roots: gas per record versus records per signature k. (a) DR-L, leaves posted (10 devices; 4 for k = 1,000). (b) Root only, each scheme with its cheaper key placement (PQ schemes with precompiles: DR-0C; ECDSA and LMS: DR-0). ECDSA is shown in the same design in both panels. times with leaves posted and from 13.7 to 10.1 times with roots only. A further increase to 96/96 would raise floor-bound designs by 2.0–2.8 times and, for the first time, LMS with posted leaves (+27%). Glamsterdam’s other repricings change the intrinsic cost (EIP-2780), state creation (EIP-8037, outside the transaction cap) and state access (EIP-8038), which affect registration, key storage and the per-batch storage write but not the leaf and signature costs that dominate our results. Blob cost.

A blob holds 4,096 field elements of 31 usable bytes, i.e. 3,968 leaves, and transactions

pay for whole blobs. At the EIP-7918 reserve price, a blob costs the equivalent of 8,192 gas, so DRB would add about 2 gas per leaf for full blobs, 8 for a 1,000-leaf batch and 82 for a 100-leaf batch, multiplied by the ratio of the market to the reserve blob price. These are estimates; we did not execute blob transactions. Rollups.

On a rollup the dominant cost is the data posted to Ethereum, which compression cannot

reduce for high-entropy signatures. For ML-DSA-44, per-record signatures post 2,965 bytes per record against 28–73 bytes with device-signed roots, a 40- to 100-fold reduction (10 bytes for Falcon-512 with DR-0C, 19–30 for LMS). DR-0 with LMS and DR-0C with ML-DSA-44 post almost the same data (29.5 12

Table 9: Registration gas (one-time per device). Scheme

Commitment (key in calldata)

Key stored on-chain

PQ-authorized by RA signature

74,570 100,200 59,499 840,830 45,589

383,973 522,755 294,125 4,550,102 111,635

171,650 (precompile) / 1,305,054 (Solidity) – – – 371,525 (Solidity, real)

ML-DSA-44 ML-DSA-65 Falcon-512 ML-DSA-44, EIP-8051 key LMS-H10-W4

Table 10: Gas per record under the current floor, the Glamsterdam floor (EIP-7976, scheduled) and a hypothetical further increase, recomputed with Equation (1) from the measured execution and byte counts; and calldata bytes per record, the quantity a rollup posts to Ethereum. PR at n = 50, DR at k = 100. Design Scheme / verification PR PR PR PR DR-L DR-L DR-L DR-0 DR-0 DR-0C DR-0C

10/40 (now) 64/64 (Glamsterdam)

ECDSA 12,971 ML-DSA-44, precompile 112,490 Falcon-512, precompile 39,513 LMS-W4, Solidity 326,555 ECDSA 1,558 ML-DSA-44, precompile 2,831 LMS-W4, Solidity 4,675 ECDSA 245 LMS-W4 (n = 32 / n = 24), Solidity 3,350 / 2,991 ML-DSA-44, precompile 1,031 Falcon-512, precompile 387

96/96 Bytes/record

24,264 36,186 190,152 285,018 72,597 108,685 326,555 326,555 2,381 3,560 4,695 7,032 4,675 5,926 333 488 3,350 / 2,991 3,350 / 2,991 1,807 2,700 681 1,011

373 2,965 1,128 2,811 36.9 73.0 61.5 4.9 29.5 / 19.3 27.9 10.3

and 27.9 bytes); on a rollup where execution is cheap, the choice of scheme then nearly disappears and Solidity verifiers become competitive. Fees and capacity.

A record costs its gas times the base fee plus the priority fee. At 0.1, 1 and

10 gwei base fee plus 0.1 gwei priority, a per-record ML-DSA-44 signature with precompile costs 2.3 × 10−5 , 1.2 × 10−4 and 1.1 × 10−3 ETH, LMS with root signing (k = 100) 6.7 × 10−7 , 3.7 × 10−6 and

3.4 × 10−5 ETH, and ML-DSA-44 with precompile and on-chain keys 2.1 × 10−7 , 1.1 × 10−6 and 1.0 ×

10−5 ETH. With the 60-million block gas limit at the time of writing (November 2026) [51], a block could anchor about 4,600 records with per-record ECDSA, 530 with per-record ML-DSA-44 and about 58,000 with device-signed ML-DSA-44 roots (k = 100), ignoring other traffic. Glamsterdam is expected to enable higher gas limits, which scale these capacities but not the per-transaction results.

7

Discussion

When is on-chain verification worth its premium?

Two alternatives avoid verifying device signa-

tures in the contract. Proof-based aggregation: an aggregator proves that it verified m device signatures, and the contract verifies one proof. Under a PQ requirement the proof cannot be wrapped in a pairingbased SNARK, the usual way to shrink on-chain cost, so a STARK must be verified directly, at about 5 million gas [17]; with a proof of the order of 100 kilobytes in calldata, a proof costs some 6–9 million gas. Against DR-0C with ML-DSA-44 (about 103,000 gas per device root) this breaks even at roughly 60–90 devices per proof, and against LMS (about 335,000 gas) at roughly 18–27 devices; beyond that, aggregation is cheaper on-chain, at the price of a prover, its hardware and its latency. Optimistic anchoring: 13

the contract records each device’s root and a hash of its signature without verifying it, and verifies only when challenged [17]; this costs roughly the ECDSA root-only figure per device, about 25,000 gas, independent of the PQ scheme, but requires watchers, a challenge window during which records are not final, and availability of the signatures during that window. Contract-level verification is worth its premium when other contracts must consume records immediately and trustlessly, for example to release a loan instalment when a production milestone is anchored, without relying on provers, watchers or challenge periods; at small fleet sizes it is also the cheapest of the three. Choosing a design.

If every record hash should be published to all observers at submission, DR-L with

k chosen from Table 8 brings all schemes close to the cost of a leaf. If the parties can keep the leaves themselves, DR-0 is an order of magnitude cheaper. A camera recording every ten minutes produces 144 records per day, so daily roots correspond to k ≈ 150. Root signing adds latency: with daily roots, a record waits up to a day before it is authenticated on-chain, and records buffered on a device that

fails before signing are lost unless the device forwards them immediately and signs their hashes later. Applications that need records on-chain within minutes can combine ECDSA per record with a periodic PQ root over the already anchored record hashes, at the DR-0 cost for the PQ layer. Which scheme today.

Without precompiles, LMS is the cheapest standard-compliant option, about

four times cheaper to verify than the optimized NIST ML-DSA verifier, robust to calldata repricing, and with n = 24 (category 3) 11% cheaper still in DR-0. Its price is statefulness: the counter must be persisted and protected against rollback, and the tree must be sized for the device’s lifetime, which HSS extends at twice the verification cost. ML-DSA is stateless and simpler on devices; Falcon has the smallest signatures and, with a precompile, the lowest on-chain cost, but its signing is harder to implement securely on microcontrollers. SLH-DSA is a conservative fallback; a SPHINCS variant with limited-signature parameters has been verified on-chain for about 150,000 gas [36], but it is not the standardized parameter set, so we report only data costs. A hybrid ECDSA and PQ signature costs little more than the PQ signature alone and is a sensible default during the transition. Limitations.

No measurement was taken on IoT hardware: device figures come from x86-64 and

ARM64 server cores and from published Cortex-M4 results, and energy was not measured. We did not execute blob transactions or measure on a rollup, and the aggregation and optimistic alternatives are analysed, not implemented. Precompile results depend on draft prices, although Figure 3 shows that per-record costs are insensitive to them. The Solidity verifiers are experimental and unaudited, as are our LMS/HSS verifiers. The results reflect the Osaka rules and the repricing scheduled for Glamsterdam; the released harness can recompute them for later changes.

8

Conclusion

Signing every IoT record with a post-quantum signature is uneconomical at scale on Ethereum and remains so with the proposed precompiles, because the EIP-7623 floor prices every signature byte, and the scheduled Glamsterdam repricing makes it worse. Signing Merkle roots on the device changes this: with roots over a hundred records, PQ authentication costs about a thousand gas per record with precompiles and stored keys, and a few thousand gas with a standard LMS verifier that runs on Ethereum today and 14

is unaffected by the repricing. These costs exceed those of ECDSA in the same design by a factor that the cost model makes explicit, and they come with batching latency and data-availability properties that must match the application. Devices deployed now can therefore be given a post-quantum authentication path without waiting for protocol changes.

Data and code availability The device-side benchmarks, the anchoring contracts, the LMS/HSS verifiers, the transaction harnesses, the scripts reproducing the Solidity verifier measurements, and all raw results are available at https:// github.com/Siemingfong/pq-iot-auth (release v2.3), archived at Zenodo under DOI 10.5281/zenodo.23970176; release v2.2, DOI 10.5281/zenodo.23969084, contains the code of an earlier version of this manuscript.

Author contributions The author is solely responsible for the conceptualization, methodology, software, investigation, formal analysis, visualization and writing of this article.

Acknowledgements The author thanks the ZKNOX team for releasing their Solidity verifiers and the pqm4 contributors for their public benchmarks.

Funding This research did not receive any specific grant from funding agencies in the public, commercial, or not-for-profit sectors.

Declaration of competing interest The author is a co-founder and the chief executive officer of Conzen.AI, a company developing privacypreserving computation for financial compliance and supply chain traceability. The company did not fund this study and had no role in its design, analysis or reporting.

Declaration of generative AI and AI-assisted technologies in the research and writing process The author used Claude (Anthropic) to assist with writing the benchmark code and Solidity contracts, running the experiments, analysing data, preparing figures, and drafting and editing the text. All code, measurements and text were reviewed by the author, who takes full responsibility for the content of the publication.

15

A

Worst case of LMS verification

For LMOTS with w = 4 and n = 32, the message digest Q has 64 base-16 digits ai and the checksum S = ∑i (15 − ai ) ≤ 960 is shifted left by 4 bits and contributes three further digits c1 , c2 , c3 , the hexadecimal digits of S. The verifier walks 15 − ai steps on each message chain and 15 − c j on each checksum chain, i.e. S + 45 − ds(S) steps in total, where ds(S) is the hexadecimal digit sum of S. Over 0 ≤ S ≤ 960, this is maximal at S = 960 = 0x3C0, with ds = 15, giving 990 steps; the 40 measured signatures required

420–570 steps. The regression of verification gas on steps, 111,315 + 322 · steps with R2 = 0.996, gives 429,900 gas at 990 steps.

References [1] Ming-Fong Sie. Authenticating IoT data on Ethereum after Pectra and Fusaka: A cost study of signature schemes, batching and anchoring for agricultural supply chain finance. Manuscript submitted for publication, 2026. [2] Jingze Wu, Ming-Fong Sie, Seth Austin Harding, Chien-Lung Lin, San-Tai Wang, and Shih-wei Liao. Multi-layer aggregate verification for IoT blockchain. In 2021 3rd Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS), pages 43–44. IEEE, 2021. doi: 10.1109/BRAINS52497.2021.9569817. [3] Ming-Fong Sie, Jingze Wu, Seth Austin Harding, Chien-Lung Lin, San-Tai Wang, and Shih-wei Liao. Secured multi-layer blockchain framework for IoT aggregate verification. Advances in Science, Technology and Engineering Systems Journal, 7(3):106–115, 2022. doi: 10.25046/aj070312. [4] Peter W. Shor. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM Journal on Computing, 26(5):1484–1509, 1997. [5] Michele Mosca. Cybersecurity in an era with quantum computers: Will we be ready?

IEEE

Security & Privacy, 16(5):38–41, 2018. [6] National Institute of Standards and Technology. Module-lattice-based digital signature standard. FIPS 204, NIST, 2024. [7] National Institute of Standards and Technology. Stateless hash-based digital signature standard. FIPS 205, NIST, 2024. [8] David A. Cooper, Daniel C. Apon, Quynh H. Dang, Michael S. Davidson, Morris J. Dworkin, and Carl A. Miller. Recommendation for stateful hash-based signature schemes. Special Publication 800-208, NIST, 2020. [9] David McGrew, Michael Curcio, and Scott Fluhrer. Leighton-Micali hash-based signatures. RFC 8554, Internet Research Task Force, 2019. [10] Andreas Hülsing, Denis Butin, Stefan Gazdag, Joost Rijneveld, and Aziz Mohaisen. XMSS: eXtended Merkle Signature Scheme. RFC 8391, Internet Research Task Force, 2018.

16

[11] Pierre-Alain Fouque, Jeffrey Hoffstein, Paul Kirchner, Vadim Lyubashevsky, Thomas Pornin, Thomas Prest, Thomas Ricosset, Gregor Seiler, William Whyte, and Zhenfei Zhang. Falcon: FastFourier lattice-based compact signatures over NTRU, specification v1.2. NIST Post-Quantum Cryptography Standardization, https://falcon-sign.info, 2020. [12] EIP-8051: Precompile for ML-DSA signature verification. Ethereum Improvement Proposals, https://eips.ethereum.org/EIPS/eip-8051, 2025. [13] Danno Ferrin. EIP-8355: Precompiles for ML-DSA verification. Ethereum Improvement Proposals, https://eips.ethereum.org/EIPS/eip-8355, 2026. [14] EIP-8052: Precompile for Falcon support. Ethereum Improvement Proposals, https://eips. ethereum.org/EIPS/eip-8052, 2025. [15] ZKNOX.

ETHDILITHIUM: ML-DSA verification for the EVM.

https://github.com/

ZKNoxHQ/ETHDILITHIUM, main commit f9f4fe1 and branch exp/packed-verifier commit f85ca80, 2026. [16] ZKNOX. ETHFALCON: Falcon verification for the EVM. https://github.com/ZKNoxHQ/ ETHFALCON, commit 43ac863, 2026. [17] Ruslan Kysil, István András Seres, Péter Kutas, and Nándor Kelecsényi. poqeth: Efficient, postquantum signature verification on Ethereum. Cryptology ePrint Archive, Paper 2025/091, 2025. [18] EIP-7623: Increase calldata cost. Ethereum Improvement Proposals, https://eips.ethereum. org/EIPS/eip-7623, 2025. [19] EIP-7825: Transaction gas limit cap.

Ethereum Improvement Proposals, https://eips.

ethereum.org/EIPS/eip-7825, 2025. [20] Toni Wahrstätter. EIP-7976: Further increase calldata cost. Ethereum Improvement Proposals (draft), https://eips.ethereum.org/EIPS/eip-7976, 2025. [21] Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo, and Parithosh Jayanthi. EIP-7773: Hardfork meta – glamsterdam. Ethereum Improvement Proposals, https://eips.ethereum.org/EIPS/ eip-7773, 2026. [22] Ralph C. Merkle. A digital signature based on a conventional encryption function. In Advances in Cryptology – CRYPTO ’87, volume 293 of LNCS, pages 369–378. Springer, 1988. [23] Carlos Aguilar-Melchor, Martin R. Albrecht, Thomas Bailleux, Nina Bindel, James Howe, Andreas Hülsing, David Joseph, and Marc Manzano. Batch signatures, revisited. In Topics in Cryptology – CT-RSA 2024, volume 14643 of LNCS, pages 163–186. Springer, 2024.

doi:

10.1007/978-3-031-58868-6 7. [24] Léo Ducas, Eike Kiltz, Tancrède Lepoint, Vadim Lyubashevsky, Peter Schwabe, Gregor Seiler, and Damien Stehlé. CRYSTALS-Dilithium: A lattice-based digital signature scheme. IACR Transactions on Cryptographic Hardware and Embedded Systems, 2018(1):238–268, 2018.

17

[25] Daniel J. Bernstein, Andreas Hülsing, Stefan Kölbl, Ruben Niederhagen, Joost Rijneveld, and Peter Schwabe. The SPHINCS+ signature framework. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 2129–2146, 2019. [26] David McGrew, Panos Kampanakis, Scott Fluhrer, Stefan-Lukas Gazdag, Denis Butin, and Johannes Buchmann. State management for hash-based signatures. In Security Standardisation Research – SSR 2016, volume 10074 of LNCS, pages 244–260. Springer, 2016. [27] EIP-2780: Resource-based intrinsic transaction gas. Ethereum Improvement Proposals, https: //eips.ethereum.org/EIPS/eip-2780, 2026. [28] EIP-8037: State creation gas cost increase. Ethereum Improvement Proposals, https://eips. ethereum.org/EIPS/eip-8037, 2026. [29] EIP-8038: State-access gas cost update.

Ethereum Improvement Proposals, https://eips.

ethereum.org/EIPS/eip-8038, 2026. [30] EIP-4844: Shard blob transactions. Ethereum Improvement Proposals, https://eips.ethereum. org/EIPS/eip-4844, 2024. [31] EIP-7918: Blob base fee bounded by execution cost. Ethereum Improvement Proposals, https: //eips.ethereum.org/EIPS/eip-7918, 2025. [32] EIP-4444: Bound historical data in execution clients. Ethereum Improvement Proposals, https: //eips.ethereum.org/EIPS/eip-4444, 2021. [33] EIP-7951: Precompile for secp256r1 curve support. Ethereum Improvement Proposals, https: //eips.ethereum.org/EIPS/eip-7951, 2025. [34] Tiago M. Fernández-Caramés and Paula Fraga-Lamas. Towards post-quantum blockchain: A review on blockchain cryptography resistant to quantum computing attacks. IEEE Access, 8:21091– 21116, 2020. [35] Marcos Allende, Diego López León, Sergio Cerón, Adrián Pareja, Erick Pacheco, Antonio Leal, Marcelo Da Silva, Alejandro Pardo, Duncan Jones, David Worrall, Ben Merriman, Jonathan Gilmore, Nick Kitchener, and Salvador E. Venegas-Andraca. Quantum-resistance in blockchain networks. Scientific Reports, 13:5664, 2023. doi: 10.1038/s41598-023-32701-6. [36] Ethereum Research. SPHINCS-minus: Efficient stateless post-quantum signature verification on the EVM. https://ethresear.ch/t/25165, 2026. [37] Ethereum Foundation. Post-quantum precompiles: EIP-8051 and EIP-8052 explained. https: //pq.ethereum.org/blog/pq-precompiles-eip-8051-8052/, 2025. [38] Ethereum Magicians. The real blocker for post-quantum Ethereum isn’t the math – it’s aggregation (and we don’t have it yet). Information brief prepared for the Ethereum Foundation, https:// ethereum-magicians.org/t/27839, 2026.

18

[39] Ankita Virani. PQSigAbstract: A modular post-quantum signature verification architecture for Ethereum. University of Colorado Boulder, https://scholar.colorado.edu/downloads/ pz50gz04f, 2026. [40] Matthias J. Kannwischer, Joost Rijneveld, Peter Schwabe, and Ko Stoffelen. pqm4: Testing and benchmarking NIST PQC on ARM Cortex-M4. In Second NIST PQC Standardization Conference, 2019. [41] pqm4 contributors. pqm4: Post-quantum crypto library for the ARM Cortex-M4, benchmark results. https://github.com/mupq/pqm4/blob/master/benchmarks.md, commit 6ff2be9, accessed November 2026, 2026. [42] Fabio Campos, Tim Kohlstadt, Steffen Reith, and Marc Stöttinger. LMS vs XMSS: Comparison of stateful hash-based signature schemes on ARM Cortex-M4.

In Progress in Cryptol-

ogy – AFRICACRYPT 2020, volume 12174 of LNCS, pages 258–277. Springer, 2020.

doi:

10.1007/978-3-030-51938-4 13. [43] Thomas Pornin. New efficient, constant-time implementations of Falcon. Cryptology ePrint Archive, Paper 2019/893, 2019. [44] Thomas Pornin. A RAM-efficient implementation of Falcon. Cryptology ePrint Archive, Paper 2026/1915, 2026. [45] Douglas Stebila and Michele Mosca. Post-quantum key exchange for the Internet and the Open Quantum Safe project. In Selected Areas in Cryptography – SAC 2016, volume 10532 of LNCS, pages 14–37. Springer, 2017. [46] Ben Laurie, Adam Langley, and Emilia Kasper. Certificate transparency. RFC 6962, Internet Engineering Task Force, 2013. [47] Foundry contributors. Foundry: a toolkit for Ethereum application development. https://github. com/foundry-rs/foundry, 2026. [48] hsslms: LMS and HSS hash-based signatures (RFC 8554) in Python. Python Package Index, version 0.1.3, https://pypi.org/project/hsslms/, 2024. [49] EthereumJS contributors. EthereumJS monorepo: VM, EVM and related libraries. https:// github.com/ethereumjs/ethereumjs-monorepo, 2025. [50] EIP-2929: Gas cost increases for state access opcodes. Ethereum Improvement Proposals, https: //eips.ethereum.org/EIPS/eip-2929, 2020. [51] EIP-7935: Set default gas limit to 60m.

Ethereum Improvement Proposals, https://eips.

ethereum.org/EIPS/eip-7935, 2025.

19

Related documents

• Mind the Gap: Policy vs Reality in Post-Quantum TLS Deployment#422202
• PPP Extensible Authentication Protocol (EAP)#136974
• SILMARILS-MV: Information-Theoretically Secure Multi-Verifier Signatures with Dealer-Free Key Issuance and Linear Aggregation for Permissioned Blockchains#1446859
• SILMARILS-MV: Information-Theoretically Secure Multi-Verifier Signatures with Dealer-Free Key Issuance and Linear Aggregation for Permissioned Blockchains#1442310
• NIST SP 800-56Ar3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography#3018