Post-quantum cryptography
Post-quantum signatures are SciChain's headline feature. Instead of relying solely on elliptic-curve cryptography — which a large quantum computer would break — SciChain authenticates transactions with the lattice- and hash-based signature schemes that NIST standardized in 2024. This page covers the algorithms, why they matter, and how SciChain wires them into the chain.
Why post-quantum matters
Every classical blockchain authenticates transactions with ECDSA over the secp256k1 curve. Its security rests on the hardness of the elliptic-curve discrete logarithm problem — a problem that is intractable for classical computers but not for quantum ones. Shor's algorithm, run on a sufficiently large fault-tolerant quantum computer, solves it efficiently. Once that machine exists, any exposed secp256k1 public key can be turned into its private key, and any address whose public key has appeared on-chain can be drained.
The threat is not purely future-tense. In a "harvest now, forge later" attack, an adversary records signed transactions and public keys today and simply waits. Blockchain data is public and permanent, so everything you sign now is already archived in someone's dataset, ready to be attacked the day the hardware arrives. Migrating before that day is the only way to keep historical and future value safe.
In 2024, NIST finalized the first federal post-quantum standards:
- FIPS 203 — ML-KEM (Kyber): key encapsulation for confidentiality.
- FIPS 204 — ML-DSA (CRYSTALS-Dilithium): lattice-based digital signatures.
- FIPS 205 — SLH-DSA (SPHINCS+): stateless hash-based digital signatures.
Blockchains authenticate rather than encrypt, so SciChain builds on the two signature standards — FIPS 204 as the default and FIPS 205 as a conservative backup family.
Signatures, not encryption On a public ledger the private data is the authority to spend, which is proven by a signature. That is why SciChain adopts ML-DSA and SLH-DSA (signatures) rather than ML-KEM (encryption).
ML-DSA (FIPS 204)
ML-DSA — the "Module-Lattice-Based Digital Signature Algorithm," standardized from CRYSTALS-Dilithium — is SciChain's default post-quantum signature scheme. Its security rests on the hardness of the Module Learning-With-Errors (Module-LWE) and Module-SIS problems over structured lattices. These problems have no known efficient quantum attack, which is exactly the property Shor's algorithm removes from elliptic curves.
SciChain uses ML-DSA-44 (formerly Dilithium2) as its default parameter set. Its sizes are fixed and worth planning for:
| ML-DSA-44 property | Value |
|---|---|
| NIST security category | Level 2 |
| Public key size | 1312 bytes |
| Signature size | 2420 bytes |
| Underlying hard problem | Module-LWE / Module-SIS (lattices) |
| Standard | NIST FIPS 204 |
Those sizes are large next to a 65-byte ECDSA signature, and that is the central engineering trade-off of going post-quantum: quantum-resistant authentication costs more bytes. SciChain accounts for this in its transaction encoding and gas model rather than hiding it.
For workloads that need stronger margins, ML-DSA is defined at higher levels too. ML-DSA-65 targets NIST Level 3 and ML-DSA-87 targets NIST Level 5, with correspondingly larger keys and signatures. SciChain exposes all three through its signature-type registry, so applications can dial security up without changing chains — the essence of algorithm agility.
SLH-DSA backup family (FIPS 205)
Betting everything on one mathematical assumption is risky, even a well-studied one. If a structural weakness were ever found in lattice cryptography, a chain that used only ML-DSA would have no fallback. SciChain hedges that risk with a signature family built on completely different math.
SLH-DSA — standardized from SPHINCS+ — is a stateless hash-based signature scheme. Its security reduces to the security of its underlying hash function and nothing else: no lattices, no number theory, no assumption that could fall to the same break. Hash functions are among the most conservatively understood primitives in cryptography, which makes SLH-DSA an unusually safe backstop. SciChain supports SLH-DSA-SHA2-128s as this backup family.
The cost of that conservatism is size and speed: SLH-DSA signatures are considerably larger and slower to produce than ML-DSA's. That is an acceptable trade for a fallback whose whole purpose is to survive a scenario where lattices no longer feel safe. Because it lives in a different math family, a hypothetical break in lattice cryptography would not touch it.
Defense in depth ML-DSA is the fast default; SLH-DSA is the "different foundations" insurance policy. Supporting both means a single cryptanalytic result is unlikely to compromise the whole chain.
Hybrid model
SciChain does not force a hard cutover. Classical ECDSA (secp256k1) transactions and post-quantum transactions coexist on the same chain, in the same blocks. Existing Ethereum tooling can keep signing the classical way while new, quantum-safe flows adopt ML-DSA — there is no forked history and no migration deadline baked into the protocol.
For the strongest guarantee during the transition, SciChain also defines a hybrid ECDSA + ML-DSA transaction type. A hybrid transaction carries both a secp256k1 signature and an ML-DSA signature, and it is only valid if both verify. That means the transaction is as safe as the stronger of the two schemes: an attacker would have to break classical and post-quantum cryptography to forge it. It is the natural default for high-value operations while confidence in any single new scheme is still building.
A practical migration path looks like this:
- Keep operating with classical ECDSA — everything works as it does on Ethereum.
- Move sensitive accounts to hybrid so they are protected by both schemes at once.
- Adopt pure ML-DSA once your tooling and confidence are ready.
The signature-type registry
SciChain routes verification through a registry of signature types, each identified by a one-byte type ID. Adding a future algorithm means registering a new entry, not rewriting the chain — this is what makes SciChain's algorithm agility concrete.
| Type ID | Algorithm | Standard | Notes |
|---|---|---|---|
0x01 | DILITHIUM2 / ML-DSA-44 | FIPS 204 | Default PQC signature. Public key 1312 B, signature 2420 B. |
0x02 | ML-DSA-65 | FIPS 204 | Higher security level (NIST Level 3). |
0x03 | ML-DSA-87 | FIPS 204 | Highest security level (NIST Level 5). |
0x04 | SLH-DSA-SHA2-128s / SPHINCS+ | FIPS 205 | Hash-based backup family. Different math from lattices. |
0x05 | Hybrid ECDSA + ML-DSA | — | Both a secp256k1 and an ML-DSA signature must verify. |
Classical secp256k1 ECDSA transactions are the standard Ethereum transaction type; they predate this registry and remain fully supported as the baseline for compatibility.
Address derivation
A post-quantum account derives its address from its ML-DSA public key using the same scheme as Ethereum: hash the public key with Keccak-256 and take the last 20 bytes.
// PQC address derivation (identical shape to Ethereum EOAs)
digest = keccak256(mldsa_public_key) // 32-byte hash
address = digest[12:32] // take the trailing 20 bytes
// e.g. 0x9f2b...c41a — a normal-looking 20-byte address
Because the output is an ordinary 20-byte address, a post-quantum account is indistinguishable in shape from a classical one. The two interoperate seamlessly: a PQC address can hold the native token, call and be called by contracts, and appear anywhere an Ethereum address would. The only difference lives in how a transaction from that address is authenticated — by an ML-DSA signature instead of an ECDSA one. What distinguishes them on-chain is the transaction's signature type, not the address format.
Keep going See how these signature types are packaged and sent in Transactions & addresses, then verify ML-DSA signatures from Solidity with the on-chain precompile in Smart contracts.