Blockchains Supporting Kyber and Dilithium

A KEM does not sign a transaction. A signature does not automatically create confidential network transport. ML-KEM and ML-DSA therefore solve different problems. A chain may adopt one first without supporting the other, and that distinction should remain visible in documentation, wallet UX, protocol specifications, and external descriptions.

For ML-DSA, a team has to consider the account model, address derivation, transaction serialization, signature verification budget, mempool behavior, archival nodes, hardware wallets, multisignature policies, and safe recovery. For ML-KEM, it must decide where encrypted channels or stored secrets belong, how keys are authenticated, how session material rotates, and whether a hybrid mode is needed during transition.

NIST’s migration guidance says its first PQC standards can and should be put into use now, while quantum computers that threaten current systems may still be years or decades away. It also states that quantum-vulnerable algorithms will be deprecated and ultimately removed from NIST standards by2035. NIST’s project page is clear that this is a long transition, not an overnight switch.

“We encourage system administrators to start integrating them into their systems immediately, because full integration will take time.”

ML-DSA has the most obvious blockchain-facing role because blockchains already depend on signatures. A future integration could authorize an account transaction, a validator vote, a bridge attestation, an oracle update, an administrator action, or a software release. Each use has a different verification frequency and failure mode. A signature that works in a release pipeline may be too large or too slow for a high-volume transaction path.

ML-KEM usually belongs on a different layer. It can help two parties establish a secret for encrypted transport or stored material. That could matter for a wallet connecting to a service, node-to-node private communication, encrypted off-chain data, an identity credential exchange, or a validator operations channel. It does not hide public ledger data by itself, and it does not prove that a wallet owner authorized a transfer.

Address design is a common source of confusion. If an account address commits to a public verification key, a post-quantum signature scheme may require a new address family, a tagged transaction field, or an account abstraction layer that routes to the right verifier. Wallets then need to display the security mode clearly, avoid accidental downgrade, and protect users from reusing a classical address when the application expects a post-quantum account.

Smart-contract networks also need an explicit choice about verification. A native client feature, a virtual machine opcode, a precompile, and a contract library have very different cost and trust properties. Native integration can be efficient but requires a protocol release. A contract implementation may be easier to test but can exceed practical gas or execution budgets. Algorand’s documented Falcon verification path illustrates why the location of the verifier should be part of every claim.

The right architecture can therefore be staged. Begin with inventory and software-signing systems, establish test vectors and reproducible benchmarks, support opt-in accounts or channels where appropriate, then decide whether a consensus upgrade is justified. Publishing what remains classical is a strength. It lets integrators assess residual risk without mistaking a targeted experiment for blanket post-quantum security.