Post-quantum & scheme agility

A complete post-quantum solution

Authenticators are pluggable and standardized through the canonical authenticator set, so adopting a quantum-safe signature scheme is an additive, no-fork change: an account registers a post-quantum (PQ) actor and keeps the same address, and the quantum-vulnerable algorithms are later retired through the same canonical-set process. Because the protocol stores only a hash of each key (the actorId), migrating to a large PQ credential adds no per-account state and reveals nothing until the key is first used.

The threat is concrete. K1_AUTHENTICATOR (secp256k1), p256 (P-256), and passkey (WebAuthn) all rely on the hardness of the elliptic-curve discrete-log problem, which a cryptographically-relevant quantum computer breaks. Once such a machine is practical (“Q-day”), any actor authenticated by one of these algorithms can be forged from its public key alone. 8130 defines how accounts migrate to PQ authenticators before that point, and how the quantum-vulnerable authenticators are retired after it.

The common case: one signed transaction

For most accounts, migration is a single transaction. An account holding at least one quantum-vulnerable admin key, including the default EOA registration, signs and submits one transaction that registers a reusable PQ actor and revokes the vulnerable one. It is authorized by the existing key while that key is still secure, needs no new address, and, as a multichain (chain_id 0) change, applies across every 8130 chain from one signature.

Pre-quantum rotation

While its existing authenticator is still secure (before the cutoff), an account establishes continuity by registering a PQ actor (an actor bound to a canonical PQ authenticator) using the ordinary authorization machinery:

• Existing accounts authorize the PQ actor as admin (scope == 0x00) via a multichain (chain_id 0) signed config change (applySignedActorChanges) or via importAccount. Because the multichain channel replays on every chain, one signed rotation propagates the PQ actor to every 8130 chain.
• The rotation SHOULD also revoke the quantum-vulnerable self-actor (set DEFAULT_EOA_REVOKED) or scope it down once the PQ actor is in place; the protocol enforces removal at the cutoff regardless.

The config-change signature is itself produced by a quantum-vulnerable key, so its authority derives entirely from having been committed before Q-day: a signature first presented after Q-day is indistinguishable from a forgery. Migration therefore depends on an immutable, provably-before-cutoff record of the rotation.

Rotation anchor & cutoff

The companion ERC designates one or more anchor chains and, on each, a cutoff expressed as a finalized block height and its state root.

• An anchor chain MUST have irreversible finalized history: no party (security council, upgrade key, or reorg within economic finality) can rewrite state at or before the cutoff. Ethereum L1 qualifies; an L2 qualifies only with a full validity / fault-proof system and no privileged state override (“Stage 2”). Lower-stage L2s MUST NOT be anchors: a privileged operator could insert a backdated rotation and defeat the before-cutoff guarantee.
• A rotation is anchored when the authorizing config change or import is included in a finalized anchor block at or before the cutoff.
• The cutoff MUST be set conservatively ahead of projected Q-day, with margin for the anchor's finality, so no rotation can be anchored after the vulnerable key becomes forgeable.

Cross-chain honoring

After the cutoff, a chain honors a PQ actor that was anchored on an anchor chain through a proof of inclusion against the anchor's cutoff state root:

• The anchor's cutoff state root is a canonical constant on each 8130 chain, fixed by the companion ERC (or imported by the chain's protocol from the anchor).
• A pq-rotation canonical authenticator accepts a Merkle proof that the account's PQ actor was present in the anchor Account Configuration state at the cutoff, plus a PQ signature over the transaction hash by that actor.
• An account that rotated once, on the anchor, can then act on every 8130 chain after the cutoff without a per-chain pre-Q-day transaction.

Portability by account type

No retroactive rescue

A quantum-vulnerable actor cannot be recovered after Q-day: its only secret is the private key, which the adversary recovers from public data, so any proof of that key is equally producible by the attacker. The sole exception is an actor whose on-chain commitment is to a preimage under a one-way function that the credential never reveals: for example a secp256k1 actor deterministically derived from a seed committed as Hash(seed). A hash / KDF preimage is only quantum-weakened, not broken, so knowledge of the seed can still be proven after Q-day (e.g. via a hash-based signature or a STARK of the preimage). Actors with no such hidden preimage (an already-exposed EOA key, any P-256 / passkey credential, or a smart account whose authority is entirely quantum-vulnerable) have no post-Q-day recovery path and MUST migrate before the cutoff.

Dormant actors as quantum-recovery anchors

The protocol commits only a hash of each key: the actorId is keccak256(x, y) for p256 / passkey and keccak256(pubkey)[12:] for k1, and the public key is disclosed only in calldata the first time the actor signs. An actor that has been authorized but never used has therefore never exposed its public key: on-chain it exists only as keccak256(pubkey), protected by hash preimage resistance rather than EC hardness, which a quantum computer only square-roots (Grover, ~2¹²⁸ work for a 256-bit preimage). Such a dormant actor is itself a valid hidden-preimage anchor, with the public key playing the role of the seed. An account MAY pre-register a dormant EC actor today purely as a quantum-recovery anchor.

Spending a dormant anchor

By contrast, an EC actor whose public key has already been disclosed (any used k1 / EOA key, or a p256 / passkey credential that has ever signed) is fully quantum-exposed and has no recovery path. Only the never-revealed case qualifies as a hidden-preimage anchor.

Authenticator deprecation

At the cutoff the companion ERC removes the quantum-vulnerable authenticators (K1_AUTHENTICATOR, p256, and passkey) from the canonical set. After deprecation:

• Nodes MUST remove these authenticators from the allowlist and MUST reject transactions authenticated by them over the 8130 path. The implicit secp256k1 EOA path (native ecrecover) is likewise disabled for authentication.
• An account with an anchored PQ actor (or a hash-preimage-recoverable actor) continues under that actor. An account with neither can no longer authenticate over the 8130 path and is effectively frozen.
• Deprecation is one-way. The companion ERC MAY stage it, e.g. a warning period during which quantum-vulnerable authenticators still authenticate but wallets surface migration prompts, followed by removal.

Migration is opt-in and requires action before the cutoff: dormant or lost-key accounts are not recoverable. Wallets SHOULD prompt users to register a PQ actor well ahead of the cutoff.

Why the model fits PQ (scheme agility)

Authentication is always authenticate(hash, data) → actorId. A new scheme is a new contract behind that interface: no new opcodes or transaction fields to deploy and register. Key material stays in calldata, and per-actor protocol state remains one actor_config SLOAD even when PQ credentials are large. The same property is why standalone EIP-7702 should deprecate in favor of the 8130 delegation account change (ECDSA-only 7702 is not quantum-safe). See Multichain & portability · Delegation vs 7702.

Canonical mempool use is coordinated through the companion-ERC allowlist (see Authenticators & locks), and a native precompile for an aggregatable PQ signature type is in progress to keep verification cheap at scale.