TADEQS System
Transcendent Adapting Dynamic Efficients Quantum Secure - A parent identity + ephemeral child rotation architecture where no public key ever protects value on-chain. 20 security levels with variable-length address hashing, SpendAndRotate atomic transactions, and dual-path quantum threat assessment.
The Quantum Problem — Solved Structurally
Every blockchain shares a fatal assumption: that a public key can safely guard value on-chain.Shor's algorithm on a quantum computer can derive a private key from its public key in polynomial time. The standard fix — post-quantum signatures — are enormous (up to 30KB each), crippling throughput. TADEQS solves both problems: all value is locked behind address hashes, never public keys. Ephemeral child keys rotate on every transaction via SpendAndRotate, so the public key is exposed only after funds have moved. The quantum threat reduces to Grover's quadratic speedup against hashes — not Shor's exponential break against keys.
Why a one-shot post-quantum upgrade doesn't solve this
Other chains will eventually add post-quantum signatures. They'll keep facing the same structural problem: an upgrade window leaves a tail of wallets that didn't migrate in time — historically around 20% of supply per upgrade. Those balances become targets the moment quantum capability lands. Hacked tokens hit the market as forced sell pressure. The market prices in the next upgrade window before it arrives. The cycle repeats every upgrade.
Bitcoin has Satoshi-era addresses with no known active controller — keys that cannot be migrated. The Ethereum Foundation has targeted ~2029 for the start of its post-quantum migration. BNB has published a proposal acknowledging a ~40% throughput reduction during migration. These are facts of architecture, not criticism.
TADEQS is QuanChain's answer: a chain that adapts continuously rather than at discrete cliff edges. No migration window. No vulnerable tail. No recurring sell-off cycle pinning the chain out of natural price discovery.
20 Security Levels
Micropayments, everyday transactions. Address hash: 128-192 bits (SHA3-256 truncated)
Significant holdings, active wallets. Address hash: 256-320 bits (SHA3-256/384)
High-value accounts, institutional custody. Address hash: 384-512 bits (SHA3-384/512)
Reserved for future NIST standardization rounds and novel cryptographic constructions
Permanent parent wallet identity. 1024-bit BLAKE3-extended address hash. Used once at registration + emergency recovery.
Parent/Child Wallet Architecture
Parent Identity + Ephemeral Children
Permanent Level 20 parent wallet (ML-DSA-87 + SLH-DSA-SHA2-256f composite, FIPS 204/205) generates ephemeral child wallets that rotate on every transaction. No live public key ever exposed.
SpendAndRotate
Every transaction atomically spends from the current child, derives a new child, registers a forwarding rule, and updates the parent resolution table. Key rotation is invisible to the user.
Variable-Length Address Hashing
Address hash scales with value: 128-bit (Level 1) to 1024-bit (Level 20). Format: QC{level}_{base58_hash}. Grover resistance from 64 to 512 bits.
Merkle Derivation Proofs
Child wallets prove legitimacy via compact Merkle proofs (~640 bytes) without parent involvement. Tree depth 20 supports 1M+ children per parent.
Dual-Path Cracking Cost Model
Security quantified in dollars via min(Grover preimage 2^(n/2), BHT birthday 2^(n/3)). Three-tier triggers: Suggested (3x), Automatic (1.5x), Emergency (10x).
Recovery & Forwarding
Parent composite signature enables emergency recovery. O(1) forwarding registry resolves any historical address to the current active child.
Invisible Migration via SpendAndRotate
Dual-Path Cost Analysis
Oracle calculates effective cracking cost via min(Grover preimage, BHT birthday collision, Shor key recovery) for each security level.
Three-Tier Triggers
Suggested (balance > cost/3), Automatic (balance > cost/1.5), Emergency (balance > cost/10). Each tier escalates response.
Invisible Upgrade
Next SpendAndRotate derives the new child at a higher level. No hard forks, no special transactions, no user action. Migration is just a normal transaction.