# Overview

Armchain replaces the traditional cryptography used by most blockchains (ECDSA/secp256k1) with **ML-DSA44** (FIPS 204), a quantum-resistant signature algorithm standardized by NIST. This protection applies at every layer: user transactions, validator signatures, and wallet key derivation.

This page explains why post-quantum cryptography matters, how Armchain implements it, and what it means for developers.

## Why Post-Quantum?

### The Quantum Threat

Today's blockchain networks rely on **ECDSA (secp256k1)** for transaction signing. The security of this algorithm depends on mathematical problems that quantum computers can solve efficiently using **Shor's algorithm**.

| Threat                         | Impact                                                                        | Timeline               |
| ------------------------------ | ----------------------------------------------------------------------------- | ---------------------- |
| **Harvest Now, Decrypt Later** | Adversaries store encrypted data today, decrypt when quantum computers arrive | **Already happening**  |
| **Key Recovery**               | Derive private keys from public keys on-chain                                 | 5–10 years (estimated) |
| **Signature Forgery**          | Forge valid transaction signatures                                            | 5–10 years (estimated) |

Once a sufficiently powerful quantum computer exists, **every ECDSA-signed transaction becomes forgeable**. Funds in addresses with exposed public keys (any address that has sent a transaction) are immediately vulnerable.

### Armchain's Approach

Armchain addresses this **proactively** by replacing ECDSA with **ML-DSA44** (Module-Lattice Digital Signature Algorithm):

* **Transaction signing**: All user transactions use ML-DSA44 (Type 3 transactions)
* **Validator signatures**: All consensus messages use ML-DSA44
* **Wallet key generation**: HD wallets derive ML-DSA44 keys
* **Address derivation**: Addresses are derived from ML-DSA44 public keys
* **SDK support**: `@armchain-ethersv6/ethers` implements ML-DSA44 natively

## NIST Standardization

ML-DSA (formerly known as CRYSTALS-Dilithium) was standardized by NIST in **FIPS 204** (August 2024) as part of the Post-Quantum Cryptography Standardization Project.

| Standard     | Algorithm          | Status                             |
| ------------ | ------------------ | ---------------------------------- |
| **FIPS 204** | ML-DSA (Dilithium) | **Finalized** - Digital signatures |
| FIPS 203     | ML-KEM (Kyber)     | Finalized - Key encapsulation      |
| FIPS 205     | SLH-DSA (SPHINCS+) | Finalized - Hash-based signatures  |

Armchain chose **ML-DSA44** (security level 2, \~128-bit classical security) as the optimal balance of security, key/signature size, and performance.

## Architecture

### Where PQC Applies

```
┌───────────────────────────────────────────────────┐
│                    User Layer                      │
│  Wallet → ML-DSA44 key generation & storage       │
│  dApp   → Sign transactions with ML-DSA44         │
├───────────────────────────────────────────────────┤
│                    SDK Layer                       │
│  @armchain-ethersv6/ethers                        │
│    → MLDSASigningKey / MLDSAWallet                │
│    → Type 3 transaction encoding                  │
│    → HD derivation (coin type 65536)              │
├───────────────────────────────────────────────────┤
│                   Network Layer                    │
│  armchain-client (armnode)                        │
│    → Validate ML-DSA44 signatures on ingest       │
│    → Validator consensus with ML-DSA44            │
│    → Event signing in DAG                         │
├───────────────────────────────────────────────────┤
│                  Consensus Layer                   │
│  Lachesis aBFT                                    │
│    → All parent hash signatures: ML-DSA44         │
│    → Block attestation: ML-DSA44                  │
└───────────────────────────────────────────────────┘
```

### What Stays the Same

Armchain maintains full EVM compatibility. The following are **unchanged**:

* **Smart contracts**: Solidity/Vyper, same opcodes, same ABI encoding
* **Addresses**: 20-byte Ethereum-style addresses (derived from ML-DSA44 public key hash)
* **JSON-RPC**: All standard `eth_*` methods work identically
* **Contract interactions**: ABI encoding, function selectors, events, logs
* **Gas model**: EIP-1559 fee market, same gas costs for opcodes

## Key Sizes Comparison

| Property                 | ECDSA (secp256k1)            | ML-DSA44                                             |
| ------------------------ | ---------------------------- | ---------------------------------------------------- |
| Private Key              | 32 bytes                     | **2,560 bytes**                                      |
| Public Key               | 33 bytes (compressed)        | **1,312 bytes**                                      |
| Raw Signature            | 64 bytes (r, s) + 1 byte (v) | **2,420 bytes**                                      |
| Signature Blob (in txns) | 65 bytes                     | **3,732 bytes** (signature 2,420 + public key 1,312) |
| Security Level           | \~128-bit (classical only)   | **\~128-bit (classical + quantum)**                  |
| NIST Category            | -                            | **Category 2**                                       |

> **Note**: Larger keys and signatures result in larger transactions (\~3,930 bytes for a simple transfer vs \~110 bytes with ECDSA). The signature blob (3,732 bytes) contains the raw ML-DSA44 signature (2,420 bytes) concatenated with the public key (1,312 bytes), since ML-DSA44 does not support public key recovery. This is an inherent trade-off of lattice-based cryptography.

## Section Contents

| Document                                       | Description                                |
| ---------------------------------------------- | ------------------------------------------ |
| [ML-DSA44 Deep Dive](/pqc/mldsa44.md)          | Algorithm details, parameters, performance |
| [Transaction Types](/pqc/transaction-types.md) | Type 3 PQC transaction format and encoding |

## Further Reading

* [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): NIST standard
* [CRYSTALS-Dilithium](https://pq-crystals.org/dilithium/): Algorithm specification
* [@noble/post-quantum](https://github.com/paulmillr/noble-post-quantum): Library used by Armchain
* [Ethers SDK](/developers/overview-1.md): Using PQC with the SDK


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.armchain.org/pqc/overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.