Post-Quantum Signature Costs: What Bigger Signatures Mean for AI Agents

What Matters

Post-quantum migration can enlarge the signed messages that AI agents send, store and verify. DN’s payload model turns published signature sizes into an explicit workload budget. The result depends on message size, signature count and key delivery. It does not predict blockchain throughput, transaction fees or the arrival of a quantum computer capable of breaking today’s cryptography.

The Signal: A Signature Upgrade Also Changes the Message Budget

A team building an agent payment system can prepare for cryptographic migration without predicting a date for a quantum breakthrough. It can identify where signatures travel and ask what happens when the authentication material becomes larger.

For an agent operator, that question extends beyond the final payment. A workflow might sign an authorization, a supplier request, a receipt and an audit record. Those are separate objects. Counting only settled transactions can miss the messages the system must transport and retain.

DN Alpha Thesis: the practical migration advantage belongs to teams that can change cryptographic components while keeping authorization, capacity and recovery understandable. A “quantum-safe” label cannot supply that operating plan.

This article addresses the payload decision. DN’s Q-Day Ledger addresses Bitcoin exposure and migration assumptions. Keeping those questions separate makes both analyses easier to use.

The Verified Constants

BIP 340 specifies 64-byte Schnorr signatures and 32-byte public keys. This is the calculator’s explicit classical reference, not a claim that every current wallet or transaction uses this encoding. [1]

NIST’s ML-DSA and SLH-DSA standards provide the following raw sizes. The listed security categories differ; choosing the smallest row does not establish the correct security level for an application. [2] [3]

The two SLH-DSA rows illustrate a design trade-off: “s” targets smaller signatures and “f” targets faster signature generation. DN has not measured that speed difference. Their corresponding SHAKE variants have the same sizes, but are not separate rows in this payload comparison. [3]

Claim Versus What the Data Actually Supports

The distinction is useful in procurement. A supplier can substantiate an encoding claim with a specification. A throughput claim needs a workload, implementation and measured result. Requiring the right evidence prevents a precise-looking table from answering the wrong question.

A Worked Scenario: The Multiplier Changes With the Denominator

Illustrative inputs: one signature per action, 256 bytes of all other application data, a batch of 1,000 actions, and no public key transmitted inside each modeled action. The 256-byte payload and workload are assumptions, not observed averages.

Using the reference constants above, DN’s arithmetic gives:

• Classical reference: 256 + 64 = 320 bytes per modeled action, or 0.320 MB for the batch.
• ML-DSA-44 scenario: 256 + 2,420 = 2,676 bytes per modeled action, or 2.676 MB for the batch.
• Difference: 2.356 MB for the batch, with the complete modeled payload about 8.36 times as large.

The raw signature ratio is about 37.81 times. Applying that number to the whole action would ignore the unchanged 256 bytes. Increasing the common application payload makes the total-message ratio smaller; adding more signatures makes authentication a larger part of the total.

These quantities describe one logical copy of each message. They exclude replication, retransmission, transport headers, database indexes, backups and a chain’s serialization. They are a starting budget for an architect, not a cloud bill.

Model Your Message Budget

Choose a parameter set, enter your common non-cryptographic payload, and specify the number of signatures and actions in your batch. Enable public-key delivery only when the model should carry one public key per signature in each action. A separate hybrid-payload option adds the classical reference material alongside the selected scheme.

Input discipline: count the same business action in both columns. If a proposed architecture changes batching, authorization scope or the number of signed messages, calculate that architecture as a separate scenario and explain the change. Do not quietly change the denominator to make a migration look cheaper.

DN Post-Quantum Signature Byte Budget

Choose a parameter set, record your envelope assumptions, and calculate the extra bytes. The constants come from published specifications. Every envelope and capacity result is a scenario.

Signature parameter setML-DSA-44ML-DSA-65ML-DSA-87SLH-DSA-SHA2-128sSLH-DSA-SHA2-128f Byte-accounting modeReplace the classical signature bytesAdd classical and PQC signature bytes Public-key bytesExclude from each envelopeInclude one key per signature Non-authentication payload (bytes) Signatures per envelope Envelopes in your batch Illustrative byte allowance

Baseline: BIP 340 Schnorr, 64 signature bytes and optionally 32 public-key bytes per signature. The allowance has no time unit. “Add” is simple size accounting, not a specified hybrid security protocol.

Calculate byte budgetLoad illustrative exampleReset

Enter your assumptions or load the illustrative example.

Download scenario JSONDownload JSON schema

Machine-readable record and limits

Schema identifier: dn.pqc-byte-budget.v1. Version 1.0.0 exports your inputs, exact byte constants, calculated results, source links and explicit assumptions. recordCreatedAt is the export calculation time, not a performance observation. Byte counts are integers; multipliers are numbers; evidenceStatus identifies documented constants combined with a scenario. No TPS, fees, Q-Day estimate or “quantum safety” rating is exported.

The calculator makes no external requests. It runs in your browser. Downloaded files contain only these scenario values and the listed metadata.

The Public Key Can Change the Answer

The sender and verifier need an agreed way to identify the signing key. That does not mean a full key must accompany every message. A system might already have a trusted key record, or it might require the key in each self-contained record.

In the worked scenario, enabling one public key per signature produces 352 bytes for the reference and 3,988 bytes for ML-DSA-44. That is a different budget from the signature-only comparison, because the model now counts more cryptographic material on both sides.

Choose the boundary that matches the design. Excluding a key from each action does not erase the cost of distributing, registering, rotating or revoking it. Those activities belong in a separate inventory, with their own frequency and failure behavior.

A useful operating question is: what happens when the verifier has never seen this key before? The answer should specify the lookup path, the authority behind the key and the policy for a failed lookup. The payload calculator deliberately leaves those design choices visible rather than assigning them an invented universal cost.

Hybrid Payloads Need a Security Design

The tool’s hybrid option is an accounting scenario: retain the reference signature and add the selected post-quantum signature. If key delivery is enabled, it also counts both public keys. It assumes no additional wrapper bytes.

This lets a team estimate the incremental material it intends to carry. It does not define a secure hybrid protocol. A real design must specify which signatures must verify, what message each signature covers, how algorithm identifiers are bound and how a verifier rejects an unauthorized fallback.

Ask for that specification before treating “hybrid” as a benefit. An application that accepts either signature under an unintended fallback rule has a different security policy from one that requires both. Neither policy should be inferred from a product label.

Also separate signing from encrypted communication. NIST FIPS 203 defines ML-KEM for establishing a shared secret; it is not a transaction signature scheme. A system’s use of post-quantum key establishment does not, by itself, tell you what authenticates a wallet action. [6]

Why the Calculator Does Not Quote Bitcoin Fees or TPS

A raw byte is not automatically a Bitcoin virtual byte. BIP 141 defines transaction weight using base and total serialized size, and derives virtual size from weight. Converting the model’s unsigned application payload into a chain-specific fee therefore requires an actual transaction format. [4]

Even the reference needs context. BIP 341 permits a Taproot signature to carry an additional sighash byte. DN uses the 64-byte primitive as its stated baseline, not a complete Taproot spend. The calculator does not make any selected NIST algorithm spendable under a network’s existing rules. [5]

With an illustrative one-million-byte budget, the worked example fits 3,125 reference actions or 373 ML-DSA-44 actions. The model divides the budget by bytes per action and rounds down. That calculation has no block time, validator speed, congestion model or acceptance test, so it cannot produce a defensible chain TPS figure.

A chain-specific cost study would need the adopted verification mechanism, serialization, resource charging, execution cost and observed workload. Until those inputs exist, a fee estimate would hide more assumptions than it reveals.

Which Decision Should Each Team Make?

For each case, request one concrete signed example and an explanation of every byte included in the vendor’s comparison. Ask whether the benchmark includes key lookup, malformed input, verification failure and the record written afterward. Then ask which part is experimental and which part is supported in the product you would actually buy.

That evidence can support a bounded purchase decision. It is more useful than a broad “quantum-ready” score that blends cryptographic design, operational maturity and adoption into one unexplained number.

How to Turn a Payload Model Into a Performance Study

Open Quantum Safe’s liboqs provides implementations and benchmarking routines. Their availability gives teams a route to experiments, not permission to treat another machine’s result as their own production capacity. [7]

DN’s proposed measurement protocol records the exact library release or commit, compiler options, CPU, operating system, algorithm parameters, message sizes and concurrency. Measure signing and verification separately. Include failed verification and realistic queue pressure, then retain the raw observations so another team can repeat the calculation.

Next, run the complete application path. A fast primitive can still sit behind slow serialization, remote key access or a congested queue. Conversely, a larger message can remain acceptable when the workload has ample transport capacity. The relevant result is successful application work under an explicit operating limit.

For the migration decision, keep three records: the standards constant, the isolated implementation measurement and the end-to-end result. They answer different questions and should never be combined into a single unlabeled “benchmark.”

Methodology and Machine-Readable Records

Let B be common non-cryptographic bytes, N signatures per action, S selected signature bytes and K selected public-key bytes. Let I equal one when public keys are included and zero otherwise.

Reference bytes = B + N × (64 + I × 32)
Selected bytes = B + N × (S + I × K)

Hybrid payload mode adds N × (64 + I × 32) to the selected result. Batch bytes equal bytes per action multiplied by the entered action count. Additional bytes are the difference from the reference. MB and GB use decimal units: one million and one billion bytes, respectively. A budget result is the integer floor of available bytes divided by bytes per action.

The downloadable decision record identifies the model version, source constants, scenario inputs, unit definitions and outputs. Its evidence label remains a scenario even when a reader supplies their own observations, because the calculator does not independently verify those inputs. Record creation time is not represented as the time of a real-world measurement.

Limitations and What Would Change the Result

This model excludes cryptographic CPU cost, transport framing, compression, replication, storage-engine overhead, gas, chain acceptance, key-management work and security assurance. It does not recommend a parameter set. An application-specific encoding, aggregation design, deployment change or revised standard requires a fresh version of the affected assumptions.

NIST’s transition report addresses migration across cryptographic systems. It is a useful context for planning, but it does not turn this article’s scenarios into a blockchain implementation timetable. [8]

Frequently Asked Questions

Are post-quantum signatures always more expensive?

The listed schemes carry more raw signature bytes than the stated reference. Total cost also depends on implementation, message design, resource pricing and workload. This article calculates payload, not an all-in price.

Does a larger signature mean slower verification?

No fixed relationship follows from byte length alone. Verification requires a separate measurement on the intended implementation and hardware.

Can I use the result as a Bitcoin transaction fee?

No. The model uses a generic application envelope. It does not construct or price a valid Bitcoin transaction, apply virtual-byte accounting or establish support for a new signature scheme.

Why include public keys as an option?

Some message designs carry keys and others rely on separate records. The option makes this accounting assumption visible. Key distribution still needs its own operational plan.

Does hybrid mode prove a system is secure?

No. It counts two sets of cryptographic material. The combined protocol, verification policy and implementation still require review.

Is this a live benchmark of agent transactions?

No. It is a reproducible calculation using published constants and reader-controlled scenarios. DN has not measured live agent traffic for this article.

Related Decisions, Disclosure and Corrections

Continue with DN’s agent wallet key-security analysis for signing authority and recovery, or the Q-Day Ledger for Bitcoin exposure. This article makes no wallet, exchange or token recommendation, and the calculation is independent of commercial relationships.

Corrections: send a source, reproducible arithmetic issue or changed specification to press@decentralised.news. Include the parameter set and model version. Change log: 11 November 2026, version 1.0: initial standards-derived payload dataset and scenario methodology.

Primary Sources

1. BIP 340: Schnorr Signatures for secp256k1. Raw signature and public-key encoding.
2. NIST FIPS 204, Table 2 and parameter-set discussion. ML-DSA constants.
3. NIST FIPS 205, Table 2. Selected SLH-DSA constants.
4. BIP 141: Segregated Witness. Weight and virtual-size accounting.
5. BIP 341: Taproot spending rules. Signature encoding context.
6. NIST FIPS 203. ML-KEM’s key-establishment purpose.
7. Open Quantum Safe: liboqs. Implementation and benchmark tooling.
8. NIST IR 8547: Transition to Post-Quantum Cryptography Standards. Migration context.