Deep diveFrontier R&D

What post-quantum signatures would cost your ledger, and how to measure it

Key exchange gets most of the attention in post-quantum planning, but ledgers have a signature problem: every transaction carries one, every node verifies it and many designs keep it forever. The NIST signature standards produce keys and signatures far larger than the elliptic-curve schemes ledgers use today. This page sets out what the standards specify, where the cost lands in a ledger and how to measure it on your own traffic before deciding to migrate now, plan or monitor.

Reviewed 7 min read

On this page
  1. Why ledgers feel post-quantum signatures more than most systems
  2. Standards and terms behind post-quantum ledger signatures
  3. Key and signature sizes as stated in the standards
  4. Where signature cost lands in a ledger
  5. Hybrid signatures and crypto-agility in the transaction format
  6. Measuring signature costs on a test network
  7. Reading the results: migrate now, plan or monitor
  8. Threats to validity in post-quantum performance studies
  9. Questions and answers
  10. Sources

Why ledgers feel post-quantum signatures more than most systems

A TLS session signs a handshake once and discards it. A ledger signs every transaction, gossips each signature to every node, verifies it on every node and, in many designs, stores it in a history that is never deleted. Growth in signature size is multiplied by transaction volume, replica count and retention; verification cost is multiplied the same way and sits on the path to finality.

Ed25519 and ECDSA would be broken by a sufficiently capable quantum computer running Shor's algorithm, which is why NIST has standardised replacements and published an initial public draft, NIST IR 8547, on the transition to them8. Whether a payments team's ledger signatures need a migration plan now is one of the example questions behind our Frontier R&D practice1.

Standards and terms behind post-quantum ledger signatures

ML-DSA (FIPS 204)
The module-lattice-based digital signature algorithm, derived from CRYSTALS-Dilithium and positioned by NIST as its primary post-quantum signature standard2. It defines three parameter sets: ML-DSA-44, ML-DSA-65 and ML-DSA-87.
SLH-DSA (FIPS 205)
The stateless hash-based signature algorithm, derived from SPHINCS+ and intended as a backup to ML-DSA2. Its security rests on hash functions alone, at the price of much larger signatures.
FN-DSA (FIPS 206)
The signature algorithm based on FALCON. Its standard was still forthcoming at the time of writing6, so treat its parameters as provisional for planning.
Hybrid or composite signature
A post-quantum signature combined with a classical one so that security holds if either does. The IETF is specifying composite ML-DSA signatures for X.509 certificates7.
Crypto-agility
The ability to change signature scheme through configuration and versioned formats rather than a redesign of every component that touches a transaction.

Key and signature sizes as stated in the standards

Sizes come directly from the standards documents. Speed depends on implementation and hardware, so it is deliberately left for your own measurements.

SchemePublic keySignatureNotes for ledgers
Ed2551932 bytes564 bytes5The compact baseline in many ledgers and wallets today
ML-DSA-441,312 bytes32,420 bytes3Smallest ML-DSA set, claimed at NIST security category 23
ML-DSA-651,952 bytes33,309 bytes3Claimed at security category 33
ML-DSA-872,592 bytes34,627 bytes3Claimed at security category 53
SLH-DSA-SHA2-128s / SHAKE-128s32 bytes47,856 bytes4Tiny keys; the small-signature sets trade slower signing for size
SLH-DSA-SHA2-128f / SHAKE-128f32 bytes417,088 bytes4Faster signing than the small sets, at roughly double the signature size

FN-DSA is left out until FIPS 206 is final. ECDSA keys and signatures on the curves ledgers commonly use are of the same order as Ed25519's.

Where signature cost lands in a ledger

01One signed transaction02Wallets and signers03Gossip and mempool04Verification05History and state06Light clients,bridges
  1. One signed transaction

    Its signature, and in some designs its public key, travels through every stage below.

  2. Wallets and signers

    Signing time, key storage and hardware-module support for the new scheme.

  3. Gossip and mempool

    Every node receives every signature, so bandwidth scales with size times volume.

  4. Verification

    Each replica verifies before ordering or executing, putting verifier CPU on the path to finality.

  5. History and state

    Stored signatures and keys grow the ledger and every archive or mirror of it.

  6. Light clients, bridges

    Proofs and cross-chain verifiers may have to check large signatures in constrained environments.

Conceptual map of where a larger or slower signature adds cost in a typical ledger; the actual weights depend on the design and must be measured.

Hybrid signatures and crypto-agility in the transaction format

Few ledgers will switch schemes in one step. A hybrid approach attaches a classical and a post-quantum signature, or a composite of both, so security holds while either scheme does. The cost is additive: an ML-DSA-44 plus Ed25519 hybrid is larger than ML-DSA-44 alone, and both parts must be verified.

The decision that matters most comes earlier. A format with a versioned scheme identifier, room for variable-length keys and signatures, and accounts whose keys can rotate without changing identity lets a ledger adopt a new scheme by configuration. Fixed-length signature fields, or account identifiers derived from one classical key, turn any migration into a protocol fork. Checking for these constraints is often the cheapest useful output of a study.

Measuring signature costs on a test network

  1. Capture a traffic profile

    Model a representative period of transactions: types, sizes, arrival patterns and the share of multi-signature transactions, which multiply signature overhead.

    Output
    Traffic model

  2. Mirror production in a test network

    Run the same node software, replica count and network conditions, with a build that switches signature scheme through configuration.

    Output
    Instrumented test network

  3. Choose candidate configurations

    Typically the current scheme, one or two ML-DSA sets, an SLH-DSA set if hash-only assumptions matter to you, and a hybrid. Fix the library and version for each.

    Output
    Candidate matrix

  4. Measure the cost centres together

    Record transaction size on the wire, gossip bandwidth per node, ledger and archive growth per day of traffic and verifier CPU at peak, plus signing time on the weakest client device you support.

    Output
    Measurements per candidate

  5. Check keys and tooling

    Test whether the wallets, hardware security modules and signing services you depend on support each scheme, and how existing accounts would rotate keys.

    Output
    Tooling gap list

  6. Compare against capacity headroom

    Express each cost against the headroom in your capacity plan, so results translate directly into infrastructure decisions.

    Output
    Headroom analysis

Reading the results: migrate now, plan or monitor

This page stops at measurement. The wider migration programme, starting from a cryptographic inventory, is covered on our quantum computing page.

  • If

    Signed records must stay trustworthy for many years and the format already supports scheme changes.

    Then

    Begin a hybrid migration, starting with new accounts and long-lived keys.

    Long-lived signatures are exposed longest, and an agile format keeps the change incremental.

  • If

    Costs fit within headroom but the format cannot carry larger or variable-length signatures.

    Then

    Prioritise the format change now and schedule the scheme switch behind it.

    The format change is the long pole; the switch itself is quick once it is done.

  • If

    Measured costs exceed headroom for every post-quantum candidate.

    Then

    Plan capacity and protocol work, such as state pruning or signature aggregation research, and keep measuring as implementations mature.

    Waiting without a plan leaves no room to act if timelines shorten.

  • If

    Signatures protect only short-lived actions and keys rotate often.

    Then

    Monitor standards and implementations and keep your cryptographic inventory current.

    Exposure is limited, and maturing implementations may lower the cost.

Threats to validity in post-quantum performance studies

Immature implementations

Early signalResults for the same scheme vary widely between libraries.

MitigationTest more than one maintained implementation, record versions and treat early numbers as provisional.

Hardware acceleration differences

Early signalTest hosts have vector instructions that production nodes or client devices lack.

MitigationBenchmark on production-equivalent hardware and the weakest supported client.

Unrepresentative traffic

Early signalThe test mix lacks the multi-signature or large transactions seen in production.

MitigationDerive the traffic model from production records and check it against observed sizes.

Questions and answers

Why not wait for FN-DSA, which has smaller signatures?

FN-DSA is expected to give more compact signatures than ML-DSA, but its standard was not final at the time of writing and its signing procedure is harder to implement safely. Measuring ML-DSA now still shows whether your format and capacity can absorb larger signatures, which is the harder engineering question. Rerun the study for FN-DSA once FIPS 206 is published.

Do signatures and key exchange have to move at the same time?

Not necessarily. Key exchange protects confidentiality, and data captured today could be decrypted later, which is why many programmes start there. Ledger signatures protect integrity and authorisation, where the risk is future forgery rather than retrospective decryption. The priority depends on how long signatures must stay trustworthy and how hard your format is to change.

Does a hybrid signature double the verification cost?

It adds the classical verification to the post-quantum one, and the classical part is usually the smaller share. Size overhead is additive as well. Whether that matters depends on your headroom, so hybrid configurations belong in the candidate matrix and should be measured on the same network and traffic profile as single-scheme options.

Is a signature performance study the same as a migration plan?

No. The study answers what each scheme would cost in your system and whether your formats can carry it. A migration plan also covers the cryptographic inventory across all systems, prioritisation by data lifetime, vendor and hardware-module readiness, sequencing and governance. The study feeds that plan and can change its order of work.

Sources

  1. Frontier R&D: questions that justify research — ColdAI
  2. NIST Releases First 3 Finalized Post-Quantum Encryption Standards — National Institute of Standards and Technology · checked 10 October 2026
  3. FIPS 204: Module-Lattice-Based Digital Signature Standard (Table 2, key and signature sizes) — National Institute of Standards and Technology · checked 10 October 2026
  4. FIPS 205: Stateless Hash-Based Digital Signature Standard (Table 2, parameter sets) — National Institute of Standards and Technology · checked 10 October 2026
  5. RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA) — Internet Research Task Force (IRTF) · checked 10 October 2026
  6. Internet-Draft: FN-DSA in X.509 certificates (refers to the forthcoming FIPS 206) — IETF LAMPS working group · checked 10 October 2026
  7. Composite ML-DSA for use in X.509 Public Key Infrastructure (Internet-Draft) — IETF LAMPS working group · checked 10 October 2026
  8. NIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards — National Institute of Standards and Technology · checked 10 October 2026

More in Frontier R&D

Back to Frontier R&D

Next step

Measure post-quantum signature costs on your ledger

Tell us your ledger platform, current signature scheme and transaction volumes. We will propose a candidate matrix and test-network design, and say what existing data can answer before any experiment.

Scope a signature study