IoTeX IIP-65: opt-in quantum-safe protection for staking buckets

IIP-65, posted by chenchen on the IoTeX community forum on 10 November 2026, would let a staker lock a native IoTeX staking bucket with a second, hash-based key, so that the bucket's principal, ownership and votes stay protected if the owner's ECDSA key is ever broken. The specification, a Draft by Raullen Chai and Chen Chen, is opt-in and would activate at a hardfork height. As of 12 November 2026 the thread has no replies and there is no vote.

What it changes

• A new BindBucketGuard action, signed by the owner's current ECDSA key, installs a guard key on one bucket. The guard key uses SLH-DSA-SHA2-192s (NIST FIPS 205, security category 3) and comes from a separate 24-word recovery phrase, not the account's mnemonic.
• On a guarded bucket, unstaking, withdrawing, transferring, changing delegate, restaking and rotating the key are done only through a GuardedBucketOp signed by the guard key. A normal staking action on a guarded bucket fails.
• The bucket keeps voting and earning rewards. Anyone can still add stake, and IIP-59 compounding still flows into it.
• Signing can be offline, and another account (a "sponsor") can submit the operation and pay its gas. An operation can be bound to one sponsor, and a signed operation expires within about 7 days.
• To leave, the owner can withdraw to any address, transfer the bucket with a new guard key, or transfer it with the guard cleared, which returns it to ordinary ECDSA control.
• A guard signature is 16,224 bytes. Gas is 10,000 + 100 × size + k × 150,000, where k is 1, or 2 when a new key is installed. The post puts one operation at about 1.79 IOTX, or about 3.57 IOTX with a new key, at the minimum gas price, and says the block gas limit caps a block at 13 guarded actions.
• The 150,000 gas per verification comes from the authors' benchmarks: the slowest case, 1.29 ms per verification on linux/amd64, is about 77,000 gas, and the price keeps a 2× margin over it.

Delegate self-stake buckets, endorsed buckets and contract (NFT) staking buckets cannot be guarded in this version; the post leaves them to later IIPs, in particular the candidate-key migration in IIP-64. Ordinary accounts and transfers, delegate operator and reward keys, liquid balances, the vote-weight formula, rewards, IIP-59 reward routing and unguarded buckets do not change.

The post states its own limits. Only buckets bound before a break are protected, since an attacker holding the ECDSA key could bind a bucket to their own guard key, and the IIP defines no emergency procedure for unbound buckets. A lost guard key locks the bucket permanently, and a stolen one allows an immediate transfer. Voter reward routing stays under the account's ECDSA key, so an attacker with that key could redirect future rewards but not touch a guarded bucket's principal or votes.

The case for it

chenchen starts from the timetable for ordinary accounts: "a post-quantum upgrade for ordinary accounts needs exchanges, wallets and hardware vendors to move together, which will take years." Bunker mode lets a holder protect a staking bucket now, without waiting for that migration. The signature scheme rests only on hash functions, with no elliptic curves or lattices that a new quantum or mathematical attack could break.

The post defends the lack of a recovery route as a security choice: "There is no recovery path that bypasses the guard key: any such path would be the first thing an attacker uses after a break." On the cost, it says most of it is the signature's size, and that a smaller category 1 signature exists: "We chose category 3 for a vault meant to hold for years."

Where it stands

IIP-65 is a Draft. The specification names Raullen Chai and Chen Chen as authors and its discussion is pull request 87 to the IIP repository, which is open and not merged into the repository's master branch as of 12 November 2026. The reference implementation, iotex-core pull request 5059, is also open; the post says it includes the ioctl stake2 guard wallet commands and has run every operation end to end on a test network.

The change is gated by a hardfork height chosen by the maintainers, and the post names none. It lists the work due before activation: an external security audit, NIST ACVP test vectors in continuous integration, fuzzing of the new action decoding, and wallet support beyond ioctl.

The post asks for feedback on five design questions: whether wallets and the foundation should push early binding and whether an emergency procedure for unbound buckets deserves its own proposal; whether a backup key or cooling-off period belongs in the first version; whether native, non-self-stake buckets are enough to start with; whether reward routing should be pinned to the guard key in this proposal; and whether about 1.8 IOTX per operation and category 3 are right. It asks especially for views from stakers with large or long-term positions and from wallet and exchange teams. The thread names no vote.