TADEQS architecture

Every existing blockchain has a single signing key per address. The public key for that key sits on-chain forever, which means the day a cryptographically relevant quantum computer comes online, every funded address becomes a target for Shor's algorithm. Retrofitting a post-quantum signature scheme onto a deployed chain forces a hard fork and a global re-signing campaign.

TADEQS solves the problem at the wallet layer instead of the protocol layer. Each user owns one permanent identity at the strongest security level the chain supports, and that identity generates short-lived child wallets on demand. Funds always sit on a child whose public key has never been broadcast.

The ladder is partitioned into five tiers. Each tier maps to a specific algorithm set and a recommended address hash length. Wallets choose their level when they register; the choice is permanent for that wallet but a user can hold any number of wallets at different levels.

Address strings encode the level directly. A Level 10 address has the prefix QC10_ followed by a base58-encoded hash. Tooling never has to guess at which algorithm signed a given transaction.

A user owns one Level 20 parent wallet — the durable cryptographic identity. The parent never signs ordinary transactions. It exists to register children and authorise recovery.

Parent (Level 20)

ML-DSA-87 + SLH-DSA-SHA2-256f composite signature. 1024-bit BLAKE3 hash. Signs once at genesis + on emergency recovery.

Child (Level 1-19)

Single-tier signature, freshly derived. Active for exactly one transaction, then retired. Public key only revealed at spend time.

The parent maintains a Merkle tree of derived children. Tree depth 20 supports more than one million children per parent. Each child includes a compact derivation proof (~640 B) when it spends, so validators can confirm parentage without contacting the parent wallet.

Every outgoing transaction on Channel 1 or 2 is wrapped in a SpendAndRotate envelope. Inside a single block the protocol:

1. Verifies the active child's Merkle proof against the parent commitment.
2. Spends the requested amount to the recipient.
3. Derives a new child at the next index in the parent's tree.
4. Registers the new child as the active wallet.
5. Updates the parent's address-resolution table (so inbound mail forwards).

The rotated child's public key is broadcast for the first time inside the spend block. By the time a quantum adversary observes the key, the wallet is already empty and the balance has moved to the next child.

Level 20 uses two algorithms in an AND-construction: a signature is only valid if both the lattice-based ML-DSA-87 and the hash-based SLH-DSA-SHA2-256f verify against it. A break of either family alone does not break the parent identity.

compositeSig = ML-DSA-87.sign(sk_lattice, msg)
            || SLH-DSA-SHA2-256f.sign(sk_hash, msg)

verify(msg, compositeSig, pk_lattice, pk_hash) :=
    ML-DSA-87.verify(pk_lattice, msg, sig_lattice)
  ∧ SLH-DSA-SHA2-256f.verify(pk_hash,    msg, sig_hash)

The signature is large (34.4 KB) and the key is heavy (2.6 KB), but the parent signs at most twice per wallet lifetime — once to register, optionally once during recovery — so the cost is paid almost never.

A composite parent signature can re-anchor the Merkle tree to a fresh child at any time. Use cases include:

• Suspected leak of an active child's private key.
• Cracking-cost ratio crossing the emergency threshold (10x).
• Voluntary key-ceremony rotation, e.g. annual hygiene.

A recovery transaction goes through Channel 2 — the smart-contract channel — because the payload is large and the finality budget is more forgiving.

QuanChain prices the cost of attacking each level in dollars, using the dual-path lower bound min(Grover preimage 2^(n/2), BHT birthday 2^(n/3)). The cost is recomputed daily against current hardware pricing and published on-chain.

Wallets

Implementation guide: key derivation, signing flow, Merkle proof generation.

Smart contracts

How Channel 2 hosts contract logic, including composite-signed entry points.

API reference

JSON-RPC namespaces: qc_wallet, qc_spend, qc_recovery.

Whitepaper

Formal cryptographic spec and threat model. Linked from the docs hub.

Reference implementation: /technology/tadeqs covers the higher-level rationale alongside the same architecture diagrams.