The Attack Surface on Traditional Blockchains
On Bitcoin and Ethereum, sending a transaction reveals your public key. Before you send, only your public key hash is on-chain. The moment you spend from an address, the transaction input includes your full public key in plain text. From that point forward, your public key is permanently recorded on the blockchain, visible to anyone who queries that transaction.
This is not a bug in Bitcoin or Ethereum. It is how ECDSA signature verification works: a verifier needs the public key to check the signature. But it creates a permanent attack surface. Every address that has ever sent a transaction has its public key on-chain, harvestable by any party that wants to attempt to derive the private key.
A sufficiently powerful quantum computer can run Shor's algorithm against a known public key and recover the private key in feasible time. The question is not whether this is theoretically possible (it is), but when it becomes economically practical. Every exposed public key is a future liability. Blockchains with large UTXO sets or large numbers of active accounts contain billions of exposed public keys that cannot be removed from the historical record.
Bitcoin has an estimated 4-6 million BTC in addresses whose public keys are already exposed on-chain. Those coins are permanently at risk once quantum hardware crosses the feasibility threshold. The nature of a quantum-resistant blockchain requires designing around this exposure from the start, not patching it later.
What SpendAndRotate Does Differently
SpendAndRotate is QuanChain's atomic key rotation mechanism. It is part of TADEQS (Threat-Adaptive Dynamic Encryption and Quantum Security). Every spend transaction on QuanChain is simultaneously a key rotation. The two operations are a single indivisible transaction, not a sequence of two steps.
When you spend from an account, the protocol does three things in one atomic operation. It verifies the transaction signature against your current public key commitment. It generates a new child key derived from your key hierarchy. It retires the old key and records the new key commitment in the account state. The old key is never used again. The new key has never been used before and its public key has never appeared on-chain.
The result is that no public key is ever exposed on-chain for longer than a single transaction lifecycle. After finality, the key that signed the transaction is permanently retired. The key that will sign the next transaction has not yet been revealed.
The Parent/Child Key Hierarchy in TADEQS
QuanChain uses a hierarchical key derivation scheme under TADEQS. Every account has a master seed phrase (12 or 24 words, BIP-39 compatible). From this seed, the wallet derives a parent key using a quantum-resistant key derivation function (KDF). The parent key is never used for signing and is never transmitted or stored outside the user's device.
From the parent key, the wallet derives a sequence of child keys: Key0, Key1, Key2, and so on. Each child key is used exactly once (for one transaction), then retired. The derivation uses a one-way function: knowing Keyn does not let you compute Keyn-1 or the parent key. Knowing the parent key lets you compute all child keys, which is why the parent key is never exposed.
On-chain, the account state stores only a cryptographic commitment to the current child key. This commitment is a hash of the public key, not the public key itself. It binds the account to the key without revealing the key. When a transaction occurs, the signature reveals the current public key only at finality, and the rotation immediately replaces the commitment with a commitment to the next child key. The window in which the public key is "exposed" is the gap between transaction broadcast and block finality.
What "Atomic" Means Here
Atomic means the spend and the key rotation succeed together or fail together. There is no state in which the spend completes but the key rotation does not, or vice versa. The protocol enforces this at the transaction validation layer.
A SpendAndRotate transaction contains four mandatory fields: the spend instruction (amount and recipient), the current-key signature, the new-key commitment, and a proof that the new-key commitment is a valid child of the current key hierarchy. A transaction missing any of these fields is invalid. A transaction where the new-key commitment does not derive correctly from the current key is invalid. Validators will not include it in a block.
This design means a user cannot accidentally spend without rotating. The wallet software handles the derivation automatically, but the protocol enforces the invariant. Even a compromised wallet that omitted the rotation step would produce an invalid transaction that the network rejects.
Protection Against a Quantum Computer Acting Within the Mempool Window
Once a transaction is broadcast to the mempool, it is visible to the network before it is confirmed. A quantum adversary could theoretically see the public key in a pending transaction, run Shor's algorithm to recover the private key, and submit a conflicting transaction before the original confirms. This is the "mempool attack" scenario.
On Bitcoin, with a 10-minute average block time, a fast-enough quantum computer could execute this attack. On Ethereum, with 12-second slots, the window is shorter but not zero.
QuanChain addresses this in two ways. First, Channel 1 targets 200,000 TPS with sub-second finality for payment transactions. The mempool window is measured in milliseconds, not minutes. A quantum computer would need to complete Shor's algorithm and broadcast a competing transaction faster than the network confirms the original, a much harder bar to clear than a 10-minute window.
Second, SpendAndRotate means that even if an attacker recovers the private key from a mempool transaction, the key is already retired at finality. The attacker recovers a key that can no longer authorize any transaction. They would need to execute the attack before finality (the sub-second window) and win a transaction race in that same window. The combination of fast finality and immediate key retirement makes this attack class computationally and economically impractical.
Comparison With Bitcoin's Address Reuse Problem
Bitcoin wallets have long warned against address reuse, and for good reason. Each time you reuse an address, you re-expose the same public key. But address reuse is common because it is convenient, and because the protocol does not enforce single-use keys.
SpendAndRotate makes key reuse structurally impossible, not just inadvisable. The protocol rejects any transaction that uses the same key commitment twice. Users cannot choose to reuse a key even if their wallet software suggested it. The security property is enforced at the consensus layer, not at the UI layer.
This is a different design philosophy. Bitcoin relies on users to follow best practices. QuanChain enforces the practice automatically. The tradeoff is that QuanChain wallets must track their current child key index, which adds a small coordination requirement for multi-device setups, addressed below.
Device Loss and Recovery
If a user loses their device after a SpendAndRotate rotation, they cannot immediately reconstruct which child key index they are at. The parent key is derivable from the seed phrase, and all child keys are derivable from the parent key. But without knowing the current index, the wallet does not know which child key to use next.
Recovery works as follows. The user enters their seed phrase on a new device. The wallet software scans the chain for the account address, retrieves the current key commitment stored in the account state, and computes child keys sequentially (Key0, Key1, Key2, ...) until it finds the one whose commitment matches the on-chain value. At typical transaction frequencies, this scan completes in under 10 seconds. The wallet then sets its current index to the next key in sequence and the user can transact normally.
This recovery path does not expose the parent key or any prior child keys. The scan only checks public key commitments (hashes), not the keys themselves. The seed phrase is the only sensitive input required. For a hands-on example of setting up a QuanChain wallet that uses SpendAndRotate, see the first dapp development guide.
