CRYPTOGRAPHIC INFRASTRUCTURE

Post-Quantum
Security

Adversaries are harvesting encrypted blockchain data today to decrypt once quantum computers reach cryptographic relevance. Shamwari has been quantum-safe since genesis block zero — no legacy ECDSA history, no retroactive exposure, no migration required.

ML-DSA DILITHIUMML-KEM KYBERNIST FIPS 203/204AES-GCMBIP39 PQHARVEST-NOW THREAT
2
NIST post-quantum standards deployed
0
Legacy ECDSA history — PQC from genesis block zero
2030
Quantum threat window — Shamwari ready today
100%
Historical transactions protected retroactively
01
THREAT MODEL
The harvest-now, decrypt-later attack

This is not a 2030 problem. It is a 2024 problem that will manifest in 2030. Nation-state adversaries are actively capturing and archiving encrypted blockchain traffic today — every transaction, every identity proof, every certificate — with the explicit intent to decrypt it once a cryptographically relevant quantum computer exists.

ACTIVE THREAT — NOT THEORETICAL
Intelligence agencies and state-level actors are known to operate large-scale traffic interception and archival programmes. The objective: archive now, decrypt later. Financial records, identity proofs, and transaction histories recorded today on ECDSA chains will be decryptable by a sufficiently powerful quantum computer. The vulnerability window is the entire historical archive of the chain.
THE THREAT
Active Interception Today
Traffic is being captured now. Every ECDSA-signed transaction published to any blockchain is permanently archived by multiple state-level adversaries. The clock starts at publication, not at quantum availability.
THE DEADLINE
NIST Migration Deadline: 2030
NIST has finalised FIPS 203 and FIPS 204. The 2030 compliance deadline gives chains that migrate in 2028 two years of fully exposed transaction history. Chains that migrate in 2029 leave three years exposed.
THE SOLUTION
PQC from Genesis Block Zero
Every Shamwari transaction since block 1 is signed with Dilithium and encrypted with Kyber. There is no ECDSA history to expose. No migration window. No retroactive vulnerability regardless of when quantum computers reach relevance.

State-Level Interception

Intelligence agencies operate dedicated programmes to capture and archive encrypted internet traffic. Blockchain transactions — public by design and broadcast globally — are the highest-value targets. Every hash, signature, and public key ever broadcast to a peer-to-peer network is permanently archived.

Retroactive Exposure

Financial records, identity proofs, and transaction histories created today will be decryptable by future quantum computers. For a chain that launches PQC in 2028, every transaction from 2015 to 2028 — years of user activity, institutional flows, and identity data — is permanently compromised.

Fiduciary Obligation

For financial institutions holding sensitive user data on blockchain infrastructure, deploying quantum-safe cryptography is no longer optional. NIST, the European Union, and major central banks have all issued guidance requiring PQC migration. 2026 fiduciary standards require action, not planning.

02
CRYPTOGRAPHIC STACK
Four-layer post-quantum defence

Shamwari deploys a complete post-quantum cryptographic stack covering digital signatures, key encapsulation, symmetric encryption, and wallet key derivation. Every operation at every layer uses a NIST-standardised or NIST-compatible algorithm.

NIST FIPS 204
LAYER 1 · DIGITAL SIGNATURES
ML-DSA: Dilithium
Lattice-based digital signature scheme. Used for every transaction signature, every block generated by a forger, every certificate issued. Secure against Shor’s algorithm on any quantum computer of any size.
Transaction signingBlock signatures (2420B)Certificate issuanceIdentity attestationForger key
Security level: ML-DSA-2 (Level 2)
Signature size: 2420 bytes
Public key: 1312 bytes
Algorithm basis: Module lattices (MLWE)
NIST FIPS 203
LAYER 2 · KEY ENCAPSULATION
ML-KEM: Kyber
Module-lattice key encapsulation mechanism. Public key stored on-chain for every account. Used to encrypt account identity metadata, purchase payloads, insurance policy details, messages, and delivery proofs.
Account identityPurchase payloadsKYC dataMessagesDelivery proofsPolicy metadata
Security level: ML-KEM-512
Public key: 800 bytes
Ciphertext: 768 bytes
Algorithm basis: Module lattices (MLWE)
AEAD
LAYER 3 · SYMMETRIC ENCRYPTION
AES-256-GCM
Authenticated Encryption with Associated Data. Used after Kyber key establishment for high-throughput bulk data encryption. Provides both confidentiality and integrity verification where a tampered payload fails authentication and is rejected.
Bulk data encryptionPayload integrityPost-KEM sessionsHardware-accelerated
Key size: 256 bits
Mode: Galois/Counter Mode
Authentication: 128-bit GCM tag
Hardware: AES-NI accelerated
WALLET RECOVERY
LAYER 4 · KEY DERIVATION
BIP39 PQ Adaptation
The familiar BIP39 mnemonic standard adapted for post-quantum key derivation. A single 12–15–18–21–24 word seed phrase deterministically derives both the Dilithium signing key and the Kyber encryption key. No separate backup required for each key.
Single seed phraseBoth PQC keysNo cloud backupHardware wallet UXDeterministic
Mnemonic: 12 or 24 BIP39 words
KDF: PBKDF2-HMAC-SHA512
Output: 64-byte root entropy
Keys derived: Dilithium + Kyber pair
COMBINED KEY STRUCTURE PER ACCOUNT

Generator Public Key Size: 2112 bytes

Every Shamwari account's public identity is a combined 2112-byte structure: 800 bytes of Kyber-512 encryption public key concatenated with 1312 bytes of Dilithium-2 signing public key. This combined key is stored in the block header for forgers and in the account table for all participants.

  • Kyber public key (800B) : for encrypting data to this account
  • Dilithium public key (1312B) : for verifying this account's signatures
  • Both keys derived deterministically from the same seed phrase
  • Single key rotation updates both keys atomically via one transaction

Block Signatures : 2420 bytes each

Every forged block carries a 2420-byte ML-DSA-2 (Dilithium Level 2) signature over the full block header. This is the quantum-resistant proof that a specific forger with a specific stake committed to this specific block content at this specific height. Verification is deterministic on every node.

  • Covers: previous block hash, payload hash, generator key, timestamp
  • Deterministic: same input always produces same verifiable signature
  • Constant-time verification to ensure no timing side-channel leakage
  • Resistant to Shor’s algorithm at any key size

Why Lattice-Based Cryptography?

Both Dilithium and Kyber are built on the hardness of Module Learning With Errors (MLWE); a lattice problem for which no efficient quantum algorithm is known. Shor’s algorithm, which breaks ECDSA and RSA in polynomial time on a quantum computer, has no known application to lattice problems. NIST reviewed all known quantum attacks and standardised both algorithms in 2024.

  • Hardness assumption: Module Learning With Errors (MLWE)
  • No quantum algorithm reduces MLWE to polynomial time
  • NIST 7-year evaluation with global academic review (2017–2024)
  • Both algorithms resistant to all known classical and quantum attacks
03
ML-DSA DILITHIUM FIPS 204
Transaction signatures and block signing

ML-DSA (Module Lattice-Based Digital Signature Algorithm) is NIST FIPS 204, finalised in 2024. It is the primary signature algorithm for all Shamwari blockchain operations from individual transaction signing to block production by forger nodes.

WHERE DILITHIUM IS USED
Every Transaction Signature
Every transaction submitted to the Shamwari network carries a Dilithium signature over the serialised transaction body. This signature is verified at gate 1 of the 7-gate consensus pipeline before any other validation logic runs. A transaction with an invalid Dilithium signature is rejected immediately and never enters the mempool.
Block Production Signatures
The forger node that wins the proof-of-stake block production right signs the full block header with its Dilithium private key. The resulting 2420-byte signature is included in the block header. Every node in the network independently verifies this signature before accepting the block into their chain.
Digital Certificate Issuance
ShamwariCertificate implements java.security.cert.Certificate and uses Dilithium for all certificate signatures. JVM-based applications e.g web servers, payment terminals, enterprise middleware can verify Shamwari certificates natively using standard Java PKI interfaces, with post-quantum security underneath.
Identity Attestation
All TotemApproval state transitions, permission grants, insurance approvals, and regulatory authority actions require Dilithium-signed transactions from designated authority accounts. The signature is the proof of regulatory action verified by every node independently, permanently recorded on-chain.
TECHNICAL PARAMETERS

ML-DSA-2 (Dilithium Level 2)

Shamwari uses the Level 2 parameter set, which targets NIST security category 2 comparable to AES-128 against both classical and quantum adversaries. This balances signature size, key size, and signing/verification performance for high-throughput blockchain operation.

  • Public key: 1312 bytes (vs 32 bytes for ECDSA secp256k1)
  • Private key: 2528 bytes (stored client-side only)
  • Signature: 2420 bytes (vs 64 bytes for ECDSA)
  • Signing: ~0.15ms on modern hardware
  • Verification: ~0.1ms — constant-time, deterministic
  • Security: NIST Category 2 against quantum adversaries

Why Larger Signatures Are Acceptable

Dilithium signatures (2420B) are larger than ECDSA (64B). This is an acceptable trade-off for financial infrastructure. A 10MB block at ~12-second intervals accommodates thousands of transactions. The security guarantee is significant: no quantum attack, no migration risk, no retroactive exposure which justifies the storage overhead at any financial transaction volume.

  • Block size: 10MB hard limit accommodates high volumes
  • ~12-second block times ensure storage overhead is linear, bounded
  • Prunable signatures for old payloads removal with hash commitment retained
  • Zero migration cost with no legacy data exposure at any future date
04
ML-KEM KYBER FIPS 203
Key encapsulation and data encryption

ML-KEM (Module Lattice-Based Key Encapsulation Mechanism) is NIST FIPS 203, finalised in 2024. It is used across all Shamwari ecosystem to encrypt sensitive on-chain data ensuring that account identities, purchase payloads, and insurance metadata remain confidential even if the encrypted ciphertext is captured and archived today.

WHERE KYBER IS USED
Account Encrypted Data Identity (AccountInfo)
When an account sets its identity metadata i.e legal name, contact information, personal identification information details etc; this data is Kyber-encrypted to the account's public key before being stored on-chain. Only the account holder (who has the corresponding Kyber private key) can decrypt and read their own identity data. Third parties see only ciphertext.
Store Purchase Payloads
Every store purchase transaction encrypts its payload, customer delivery address, order details, and payment metadata, to the merchant's Kyber public key. Only the merchant with the corresponding private key can decrypt the delivery instructions. Customer privacy is protected at the transaction layer, not by the merchant's data handling policies.
KYC Permission Records
BetaChainPermission records include an EncryptedData payload where CHAIN_ADMIN accounts store Kyber-encrypted KYC documentation references. Likewise, the ciphertext is permanently stored on-chain; only the granting institution's key and the recipient key can decrypt the underlying compliance attestation data. The blockchain stores proof of compliance without storing the compliance data in plaintext.
Private Messages & Delivery Proofs
The messaging layer uses Kyber to encrypt messages between accounts. 3PL delivery providers submit Kyber-encrypted delivery proofs that only the buyer can decrypt. This creates a tamper-proof, privacy-preserving delivery confirmation system where the blockchain stores the commitment but not the readable proof content.
HYBRID ENCRYPTION PATTERN

KEM + AES-GCM Hybrid

Kyber is a Key Encapsulation Mechanism which encapsulates a symmetric key, not the data directly. The pattern is: (1) use Kyber KEM to establish a shared secret with the recipient's public key, (2) use that shared secret as an AES-256 key to encrypt the actual payload. This hybrid approach gives both the quantum resistance of Kyber and the performance of AES-256 for data.

  • Kyber encapsulates a 32-byte shared secret
  • AES-256 encrypts payload using the shared secret
  • Decryption requires Kyber private key and only recipient can decrypt

ML-KEM-512 Parameters

Shamwari uses ML-KEM-512 (the Level 1 parameter set), which targets NIST security category 1 comparable to AES-128 against both classical and quantum adversaries. This is the right choice for data encryption where the value of the data does not need 30+ years of quantum-resistant protection, while maintaining excellent performance for high-volume on-chain storage.

  • Public key: 800 bytes
  • Ciphertext (encapsulation): 768 bytes
  • Shared secret: 32 bytes (used as AES-256 key)
  • Security: NIST Category 1 against quantum adversaries
  • Performance: ~0.05ms encapsulation/decapsulation
05
BIP39 PQ ADAPTATION
One seed phrase. Both post-quantum keys.

Shamwari adapts the familiar BIP39 mnemonic standard for post-quantum key derivation. The same 12/15/18/21/24 word seed phrase that users already know from Bitcoin and Ethereum wallets now derives two NIST-standard post-quantum keys; the Dilithium signing key and Kyber encryption key with no additional complexity for the user.

KEY DERIVATION ARCHITECTURE
SEED TO KEYS — DETERMINISTIC DERIVATION FLOW
SEED PHRASE
12/15/18/21/24 BIP39
mnemonic words
PBKDF2 ROOT
64-byte entropy
HMAC-SHA512
DILITHIUM KEYPAIR
1312B pub
2528B priv
KYBER KEYPAIR
800B pub
1632B priv
Single Backup, Two Keys
Users back up one seed phrase and recover both their signing key and encryption key from it. No second backup. No key file. No cloud storage required. The same seed recovery UX that crypto users already understand works identically for post-quantum keys.
Deterministic - Same Seed, Same Keys
Given the same seed phrase, the same Dilithium and Kyber keypairs are always derived. There is no randomness in the derivation after the initial seed generation. A user can recover their keys from any device, any wallet implementation, at any time, from just their seed phrase.
Hardware Wallet Compatible
The BIP39 PQ Adaptation is designed to be implementable on hardware security modules and hardware wallets. Private keys never leave the device. The signing and decryption operations execute on the hardware wallet; only the public keys and signatures are transmitted to the network.
KEY STORAGE & SECURITY MODEL

What Goes On-Chain

Only public keys are stored on-chain. The combined 2112-byte generator public key (Kyber 800B + Dilithium 1312B) is written to the account record when first activated. Public keys are public by design — their security comes from the hardness of the lattice problem, not from secrecy.

  • Kyber public key (800B): stored in account table
  • Dilithium public key (1312B): stored in account table
  • Account ID: derived from Dilithium public key hash
  • Account Address: A Reed-Solomon representation of the accountId
  • No private key material ever touches the blockchain

What Never Leaves the Device

Private keys are held exclusively by the account holder in the wallet application or hardware device. They are used to sign transactions (Dilithium) and decrypt received data (Kyber). The Shamwari protocol never requests, stores, or transmits private keys.

  • Dilithium private key (2528B): signs transactions locally
  • Kyber private key (1632B): decrypts received payloads locally
  • Seed phrase: never transmitted, stored offline
  • Signing is always local: nodes receive signed tx, not the key
06
JVM-NATIVE PKI
The first quantum-safe JVM certificate

ShamwariCertificate extends java.security.cert.Certificate directly; the standard Java certificate interface. Any JVM application that currently accepts X.509 certificates accepts Shamwari certificates without modification, while gaining post-quantum security underneath.

java.security.cert.Certificate Interface
ShamwariCertificate is not an X.509 wrapper — it implements the raw Java Certificate interface that all JVM applications rely on. Web servers using JSSE, payment terminals using JCE, and enterprise middleware using Bouncy Castle all call the same interface methods. Shamwari certificates work natively with all of them.
Dilithium-Signed Certificates
Every ShamwariCertificate is signed by the issuing authority account’s Dilithium key. The certificate contains the subject’s Dilithium public key, issuer account ID, validity block height range, and optional metadata. Verification uses the issuer’s on-chain Dilithium public key and is independently resolvable by any node.
Instant On-Chain Revocation
A CERT_REVOCATION transaction is effective at the next block — approximately 12 seconds. There is no Certificate Revocation List (CRL) to distribute, no OCSP server to poll, and no propagation delay. Certificate status is blockchain state, queryable in real time by any verifier.
Global or Chain-Scoped Validity
Setting isGlobal = true makes a certificate valid across all BetaChains simultaneously from a single issuance transaction. Scoped certificates are valid only on their issuing chain. This enables KYC credentials valid network-wide alongside jurisdiction-specific professional licences.

KYC Credentials

Issue verified identity credentials that any chain participant verifies on-chain. KYC data Kyber-encrypted — verifiable without exposing underlying identity information to third parties. Institution-issued, blockchain-anchored, quantum-resistant.

Institutional Licences

Central Banks issue operating licences as on-chain certificates with block-height expiry. Licence status is verifiable by any counterparty in real time. No third-party registry, no manual verification phone call, no risk of stale data.

TLS for Node Infrastructure

Node operators use Shamwari certificates for TLS mutual authentication. Accepted natively by JVM-based infrastructure without custom certificate authorities. Quantum-safe TLS for all inter-node communication in the Shamwari network.

07
QUANTUM THREAT TIMELINE
From harvest-now to cryptographic relevance

The quantum threat to blockchain cryptography is not binary. It is a rolling window of increasing risk, where the value of currently-captured data increases as quantum computing capabilities advance. Shamwari has zero exposure at any point on this timeline.

TIMELINE
Now
Harvest-now attacks activeState-level adversaries archiving encrypted blockchain traffic. Value of archive increases over time as quantum capability grows.
2024
NIST standards publishedFIPS 203 (Kyber) and FIPS 204 (Dilithium) finalised. Enterprise migration guidance issued. Shamwari already compliant from genesis.
2026
Fiduciary requirement emergesCentral banks and regulators begin requiring PQC migration plans from financial institutions. Non-compliant chains begin losing institutional depositors.
2028
Most blockchains begin migrationChains migrating now leave years of ECDSA transaction history permanently exposed to future decryption. Migration does not retroactively protect historical data.
2030
NIST compliance deadlineCryptographically relevant quantum computers approaching viability. Harvest-now archives from 2020–2030 become increasingly decryptable. Shamwari: zero exposure window at any date.
SHAMWARI vs COMPETITORS
Property
Classical Chains
Shamwari
Transaction signing
ECDSA (vulnerable)
Dilithium FIPS 204
Key encapsulation
ECDH (vulnerable)
Kyber FIPS 203
Block signing
ECDSA — 64 bytes
Dilithium — 2420 bytes
Historical exposure
Entire chain history
Zero — PQC from genesis
Migration required
Complex, disruptive
None needed
NIST compliance
Not yet / in progress
FIPS 203 + 204 deployed
Data encryption
None native
Kyber + AES-GCM
PKI integration
Custom required
JVM-native Certificate
Wallet recovery
Single key (ECDSA)
BIP39 PQ — both keys
08
KEY METRICS
Post-quantum by the numbers

Quantified security parameters for the Shamwari cryptographic stack. All values reference the deployed parameter sets as implemented in the protocol codebase.

2420
Bytes per Dilithium block signature
2112
Bytes per combined account public key
FIPS
203
Kyber standard — deployed
FIPS
204
Dilithium standard — deployed
WHAT SHAMWARI PROTECTS AGAINST
  • Shor’s algorithm: ML-DSA and ML-KEM are not vulnerable, lattice problems are not reducible to period-finding
  • Grover’s algorithm: AES-256-GCM provides 128-bit post-quantum symmetric security
  • Harvest-now attacks: No ECDSA history exists as all archived traffic is Kyber-encrypted from day one
  • Key extraction from signatures: Lattice problems have no known polynomial-time quantum solution
  • Classical attacks: All algorithms also provide strong classical security guarantees
WHAT ECDSA CHAINS CANNOT PROTECT AGAINST
  • Shor’s algorithm: Breaks ECDSA private key derivation from public key in polynomial time on a sufficiently powerful quantum computer
  • Retroactive key compromise: Any ECDSA public key ever broadcast is permanently archived and decryptable in future
  • Historical transaction exposure: Every transaction ever published is subject to retroactive private key recovery once quantum threshold is reached
  • Identity exposure: All ECDH-encrypted data (messages, identity) will be decryptable once the corresponding key is broken
BUILD ON QUANTUM-SAFE INFRASTRUCTURE

Post-quantum from genesis. No migration. No exposure window.

Deploy applications on the only blockchain that has been quantum-safe from its first block.