Quantum Bucket update: IIP-65 "Bunker Mode" is now Draft 4, featuring a full reference implementation in iotex-core. 🛡️
A few weeks ago, we proposed a doomsday bunker for staked $IOTX: locking buckets with a second, hash-based key. After an independent cryptographic review, we rebuilt the authorization layer to make it bulletproof. Here is what's new:
🔒 Hardened Cryptography: The core choice of SLH-DSA (FIPS 205) remains rock-solid. We upgraded the envelope with chain-instance domains (preventing cross-network replays), recent-block anchors (capping signature life at ~7 days), and exact consent bindings via SHA-512.
🧱 Verify-First Architecture: Every guarded operation verifies all signatures before touching the staking state. No speculative writes, no rollback games.
🔑 Simple Recovery: Guard keys come from a dedicated vault seed. If your everyday ECDSA wallet is compromised, your vault mnemonic alone can rescue your buckets.
⚡ Lightning Fast: Verification takes just ~0.23 ms on an Apple M3 Pro—four orders of magnitude faster than our 2.5s block time.
Where it stands: The code (~13k lines) is running on nightly behind a feature gate. Next up: full-handler benchmarks, an external audit, and a governance vote. Nothing changes on mainnet until then.
Quantum computers or an AI-assisted math breakthrough might take years. Bunkers must be built before the storm. We're building ours now. ⛈️
📄 IIP-65 Spec: github.com/iotexproject/i…
💻 Implementation: github.com/iotexproject/i…
A few weeks ago, we proposed a doomsday bunker for staked $IOTX: locking buckets with a second, hash-based key. After an independent cryptographic review, we rebuilt the authorization layer to make it bulletproof. Here is what's new:
🔒 Hardened Cryptography: The core choice of SLH-DSA (FIPS 205) remains rock-solid. We upgraded the envelope with chain-instance domains (preventing cross-network replays), recent-block anchors (capping signature life at ~7 days), and exact consent bindings via SHA-512.
🧱 Verify-First Architecture: Every guarded operation verifies all signatures before touching the staking state. No speculative writes, no rollback games.
🔑 Simple Recovery: Guard keys come from a dedicated vault seed. If your everyday ECDSA wallet is compromised, your vault mnemonic alone can rescue your buckets.
⚡ Lightning Fast: Verification takes just ~0.23 ms on an Apple M3 Pro—four orders of magnitude faster than our 2.5s block time.
Where it stands: The code (~13k lines) is running on nightly behind a feature gate. Next up: full-handler benchmarks, an external audit, and a governance vote. Nothing changes on mainnet until then.
Quantum computers or an AI-assisted math breakthrough might take years. Bunkers must be built before the storm. We're building ours now. ⛈️
📄 IIP-65 Spec: github.com/iotexproject/i…
💻 Implementation: github.com/iotexproject/i…
github.com IIP-65: Bunker Mode — Quantum-Safe Staking Buckets (Draft 3) by raullenchai · Pull Request #87 ·... Draft 2 of the Quantum-Safe Staking Buckets IIP. It builds on #86 (this branch contains #86's commits plus one revision commit) and is meant to supersede it once reviewed. Read the rendered... What if your $IOTX had a doomsday bunker? 🛡️
We're introducing IIP-65: Bunker Mode—a draft proposal and working proof-of-concept for AI-safe, quantum-safe staking, inspired by @drakefjustin 's call for crypto to plan a "bunker mode."
The Problem
Today, a single ECDSA key controls your onchain asset. If a large enough quantum computer or AI-accelerated breakthrough cracks the math, an attacker could derive your private key from your public key and withdraw everything. Making the entire ecosystem AI & quantum-safe will take years and depends on many partners.
But a bunker doesn't have to wait.
The Solution: A Second Lock
1️⃣ Go in now: Bind a post-AI/quantum key to your bucket once, while your current key is still safe.
2️⃣ Wait it out: Your bucket keeps voting and earning rewards. But any critical action (unstaking, withdrawing, transferring) now requires the new key.
3️⃣ Come out later: Once post-quantum accounts exist, sign once with the new key and safely migrate your IOTX. If Q-day or an AI breakthrough comes while you're inside, the attacker hits a wall.
Why hash-based?
The new lock uses SLH-DSA (NIST FIPS 205). While lattice-based schemes rely on algebraic structures that future math might crack per @VitalikButerin, SLH-DSA rests purely on hash functions. It has no structure to break, making it the most conservative choice.
The trade-off is a "heavy door" (~16 KB signatures, signed offline)—perfectly fine for a vault you only open a few times a year.
Proof-of-Concept Highlights
⚡️ Fast: 0.23 ms to verify a signature on-chain.
🪶 Lightweight: 48-byte public key per bucket.
🔌 Frictionless: Fully opt-in & per-bucket. No EVM changes, no new address formats, no waiting on anyone else.
It's still a draft, and we want your feedback (and vote later) to make it real and bulletproof.
🎥 Explainer belowView quoted post on X
