CRYSTALS-Dilithium's 2420-Byte Signatures: The Blockchain Throughput Problem

The Signature Size Problem Nobody Talks About

Post-quantum cryptography has a cost that rarely appears in the headline comparisons between ECDSA and CRYSTALS-Dilithium. The security improvements are real. The NIST standardisation under FIPS 204 is thorough. But the signature size increase is not a rounding error: at the lowest security level, a Dilithium2 signature is 2420 bytes. ECDSA on the secp256k1 curve, used by Bitcoin and Ethereum, produces a 64-byte signature. That is a 37.8-fold increase in the data that every transaction must carry on-chain.

For a blockchain that processes a few transactions per second, that overhead is manageable. For any network trying to handle real payment volume at 1,000 or 10,000 transactions per second, the implications cascade through block size limits, propagation latency, storage growth, and fee markets. This article works through the arithmetic, examines what it means for chains that simply bolt post-quantum signatures onto an existing architecture, and explains how QuanChain's design addresses the problem structurally rather than hoping the numbers will work out.

Why Are Dilithium Signatures So Large?

CRYSTALS-Dilithium is built on the Module Learning With Errors (MLWE) problem, a lattice-based mathematical structure that resists both classical and quantum attacks. ECDSA derives its small output from the algebraic compactness of elliptic curves: a single 256-bit scalar encodes a private key, and the signature is two 256-bit integers. Lattice-based schemes work differently.

A Dilithium signature consists of several components. There is a commitment hash, a response vector, and a hint vector that allows the verifier to reconstruct the full verification without the signer revealing their private key. Each component is a polynomial or set of polynomials over a ring of integers, and those polynomials require substantially more bytes to represent than a pair of 256-bit scalars. The hint vector alone adds hundreds of bytes at higher security levels. None of this is avoidable with the current construction: the mathematical problem that makes Dilithium quantum-resistant is also the reason it is verbose.

NIST standardised three security levels in FIPS 204, each with a different size profile. The table below shows the full picture, alongside ECDSA and FALCON-512, a more compact lattice signature scheme that was also standardised by NIST.

FALCON-512 is the most compact NIST-approved post-quantum signature scheme, at 666 bytes. That is still 10.4 times larger than ECDSA. Dilithium occupies the middle range, and SPHINCS+ (hash-based, which requires no new mathematical assumptions) is enormous. The question is what any of these numbers mean for a live network processing transactions at scale.

What Does 2420 Bytes Do to Bitcoin's Block Capacity?

A standard Bitcoin transaction with one input and two outputs requires roughly 250 bytes under the current ECDSA architecture. The signature accounts for 64 of those bytes. A 1 MB block can therefore hold approximately 4,000 transactions. Bitcoin's long-run average throughput is about 7 TPS, with a theoretical maximum closer to 14 TPS under current block limits.

Now replace the 64-byte ECDSA signature with a 2420-byte Dilithium2 signature. The same transaction balloons to approximately 2,606 bytes. A 1 MB block can now hold 383 transactions. That is a 90% reduction in block capacity from the signature upgrade alone, before accounting for the public key, which grows from 33 bytes to 1,312 bytes per input. Include the public key and the per-transaction overhead reaches roughly 3,827 bytes, reducing block capacity to about 261 transactions: a 93.5% reduction.

That math does not improve at higher security levels. Dilithium5 would carry a 4,595-byte signature and a 2,592-byte public key, pushing a single-input transaction past 7,000 bytes and reducing Bitcoin's block capacity to fewer than 150 transactions. Throughput would fall below 1 TPS. Fee pressure would increase in direct proportion to the scarcity of block space, making Bitcoin unusable for anything other than high-value settlement. Our analysis of Bitcoin's quantum vulnerability covers the full scope of the migration challenge.

What Happens to Ethereum Gas Costs?

Ethereum charges gas proportional to calldata bytes. A standard ERC-20 token transfer costs around 21,000 gas for base cost, plus 16 gas per non-zero calldata byte. A Dilithium2 signature adds 2,420 bytes of calldata to every transaction: 38,720 additional gas per transfer. At a gas price of 10 gwei and an ETH price of $3,500, that is roughly $1.35 added to every ERC-20 transfer purely from the signature overhead.

The gas cost impact compounds at higher security levels and for contracts with multiple signers. A multisig wallet using three-of-five Dilithium5 signatures adds 3 times 4,595 bytes, or 13,785 bytes, to every execution call. DeFi protocols that process millions of small transactions would face unit economics that make current Ethereum fees look trivial by comparison. The quantum vulnerability of Ethereum extends beyond cryptographic risk to include the economic constraints of a post-quantum migration.

Why Bolting On Post-Quantum Signatures Does Not Work

The throughput and cost calculations above describe what happens when an existing blockchain swaps ECDSA for Dilithium without any other architectural changes. That approach, sometimes called a drop-in replacement, is the path of least disruption for established chains. It is also the path that produces the worst performance outcomes.

A drop-in replacement preserves everything about the existing transaction format except the signature algorithm. Block size limits remain the same. Transaction propagation mechanisms remain the same. The consensus rules, mempool policies, and fee auction dynamics remain the same. All of that legacy architecture was designed around the assumption that signatures are 64 bytes. Replacing signatures with something 40 to 70 times larger immediately stresses every part of the stack that touches transaction size.

Increasing block size limits sounds like a solution, but it brings its own costs. Larger blocks take longer to propagate across the peer-to-peer network, increasing orphan rates and centralisation pressure toward well-connected, high-bandwidth nodes. The UTXO set or account state grows faster, increasing memory and disk requirements for full nodes. The security assumptions of the original design erode as infrastructure costs rise and the node operator set shrinks. The blockchain quantum migration problem is not just cryptographic: it is architectural.

How QuanChain Absorbs the Overhead Structurally

QuanChain deploys Dilithium-5, the highest NIST security level, across all 20 tiers of its TADEQS wallet architecture. At 4,595 bytes per signature, it is the most expensive option in the table above. QuanChain's throughput target is 200,000 transactions per second across three channels. The numbers only work because the architecture was designed around the signature size from the beginning, not in spite of it.

Channel Separation

The Three-Channel Architecture separates transaction types by their data requirements. Channel 1 handles high-volume payment transactions. Channel 2 handles smart contract execution. Channel 3 handles data storage and anchoring. Each channel has its own block structure, mempool, and fee market, optimised for its specific transaction profile. Payment transactions on Channel 1 carry only the information a payment needs. They are not padded out to accommodate the data fields required by smart contracts or arbitrary state transitions.

This separation matters for post-quantum overhead because different transaction types have different signature-to-payload ratios. A simple payment has a high overhead ratio: the signature is large relative to the value transferred. A complex smart contract execution has a lower ratio: the calldata dominates and the signature overhead becomes a smaller fraction of total transaction weight. Treating these identically in a single-channel architecture forces both to pay for the worst-case design of the other.

70% Data Compression

QuanChain's data efficiency analysis found that classical blockchain architectures are structurally bloated: they store redundant indexing data, repeat contextual information across related transactions, and use fixed-width fields where variable-length encoding would suffice. Addressing these inefficiencies across the full transaction format produces a 70% reduction in stored bytes per transaction relative to a naive implementation. The full breakdown of how this compression is achieved without sacrificing auditability is in the blockchain data efficiency analysis.

Applied to a Dilithium-5 transaction: the uncompressed overhead is 4,595 bytes for the signature plus 2,592 bytes for the public key. After 70% compression of the surrounding transaction structure, the net increase in stored bytes per transaction falls to a level that Channel 1's block parameters can absorb at 200,000 TPS. The compression does not touch the cryptographic material itself, which must remain verifiable, but it eliminates the structural waste that classical blockchains accept as a design choice.

SpendAndRotate: No Persistent Public Keys On-Chain

TADEQS adds a third layer of mitigation. The SpendAndRotate mechanism ensures that a child wallet's public key appears on-chain only at the moment it is used to sign a transaction, and never again. The parent wallet derives a new child key for each transaction. This eliminates the need to store public keys in a persistent UTXO set or account state: the network verifies the key at spend time, and the key is then retired. A UTXO set built on TADEQS does not accumulate 1,312 or 2,592-byte public key entries for every address that has ever received funds. The long-term storage pressure from public key bloat, which compounds significantly over years of operation on any PQ-upgraded chain, is absent by design.

Selecting a Post-Quantum Chain: The Right Questions to Ask

Post-quantum signature sizes are not a problem that engineering effort alone can overcome on a chain that was not designed for them. They are a consequence of the mathematics of lattice-based cryptography: the security guarantees require the polynomial structures, and the polynomial structures require the bytes. Any chain deploying post-quantum signatures will pay a throughput cost. The question is whether the architecture was designed to manage that cost or whether it was designed around a 64-byte assumption that no longer holds.

For developers and protocols evaluating which chain to build on for a post-quantum future, signature overhead should be a primary consideration alongside raw TPS numbers. A chain advertising 100,000 TPS under ECDSA may deliver 10,000 TPS or fewer after a post-quantum migration, depending on how tightly its block parameters are tuned to the old signature size. A chain that was designed for 200,000 TPS with Dilithium-5 from the first block has made different engineering choices, and those choices compound over the network's operating life.

For a broader view of which post-quantum blockchain designs are most capable, the post-quantum blockchain comparison for 2026 evaluates the major options across cryptographic approach, throughput, and migration burden. The full CRYSTALS-Dilithium explainer covers the mathematical construction behind the signature scheme and how it was evaluated during the NIST process.

Signature size is not a footnote in the post-quantum migration discussion. It is the central engineering constraint that determines whether a chain can survive the transition without collapsing under its own data requirements.

QuanChain's architecture documentation covers how each component interacts to achieve the target throughput under full post-quantum cryptographic load. The technology overview at /technology is the starting point for understanding how TADEQS, the Three-Channel Architecture, and the Quantum Oracle combine into a system that was not retrofitted for quantum resistance, but built for it from the first block.