Featured

New research sharpens quantum attack estimates.

Read the ecdsa.fail publicationRead the ecdsa.fail publication
StarkWareQuantum Hub

From cryptographic agility to post-quantum security

How networks move towards quantum resistance

To move towards quantum resistance, networks need a way to replace the cryptography their accounts and systems rely on. Cryptographic agility enables that change while preserving security and keeping services running.

How do networks support cryptographic agility?

Our 8 questions, informed by NIST’s cryptographic agility guidance, compare how 10 networks can change cryptography and keep operating. Each evidenced capability earns one point.

Share

Counts show evidenced capabilities within the assessed scope.

  • Capability evidenced
  • Rule not met or execution blocked
  • Not established by reviewed evidence

Both ✕ and ? receive no point. Press a tick, a cross or a score to read its basis and evidence.

Question 1 of 8
NetworkAccount changeCan an existing standard account switch to a new signing scheme without a network upgrade?The account must accept independently implemented signature-checking code while keeping its identity and assets. Rotating keys or choosing an algorithm already enabled by the network alone does not count.NISTFlexible formatsCan cryptographic interfaces accommodate different key and signature sizes without redesign?The check covers standard account formats for one working replacement, with documented key and signature sizes and resource limits.NISTModular updatesCan a cryptographic component be replaced without redesigning unrelated parts of the network?The component must be part of the deployed protocol, outside account signing, with its external dependencies identified.NISTGradual rolloutCan old and new cryptography run side by side while users migrate?Old and new account-signing methods must work side by side, with a route standard-account users can adopt today.NISTTested transitionHas the current cryptographic transition mechanism been tested for security and continued operation?Evidence must cover the deployed transition itself, including continued operation and security behaviour.NISTDowngrade lockDoes the transition mechanism prevent an attacker from forcing a weaker algorithm?The check covers every authorization route on the migrated account or output. Other accounts may still use the old algorithm.NISTSunset mechanismCan new use of an old algorithm be disabled after migration?An enforceable rule must stop new use of the old algorithm across every authorization route on the migrated account or output.NISTExisting dataIs there a migration mechanism for existing data that depends on the old cryptography?The check covers one named set of existing account or protocol data, preserving its integrity and authorization through migration. It does not require migrating the chain’s full history.NISTCapabilities evidencedWithin assessed scope

Cryptographic agility to quantum migration

Post-quantum migration uses cryptographic agility to move existing systems to quantum-resistant cryptography. These four stages show the broader work involved.

  1. Identify dependencies

    Find the cryptography used by accounts, protocol components and external systems.

  2. Introduce and test

    Introduce replacement algorithms, then test security, compatibility and continued operation.

  3. Move users and data

    Give users a supported upgrade path and migrate data that relies on the old cryptography.

  4. Retire old paths

    Disable vulnerable authorization paths on the migrated surface and prevent a forced return to weaker cryptography.

What shapes a network’s post-quantum migration?

The migration map considers what still needs replacing and who must coordinate that change. It groups networks by two dimensions:

  • Exposure combines the evidenced status of post-quantum user signing with credit for qualifying non-signing protections already shipped.
  • Friction measures how much migration asks of holders on the path securing their funds, including individual action, coordinated changes and mandatory cutoffs.

Post-quantum migration map

Share
← Higher exposureQuantum exposureLower exposure →
↑ LowerMigration friction↓ Higher

Higher exposure · lower friction

Exposed components, with a more adaptable replacement path within the assessed scope.

Lower exposure · lower friction

Fewer exposed surfaces within the assessed scope, with mechanisms for change.

Higher exposure · higher friction

Exposed components and a transition involving broader coordination.

Lower exposure · higher friction

Lower exposure in scope, with more coordination needed for further change.

Network evidence

View networks by group

Current map groupings, within each network’s assessed scope.

Higher exposure, lower friction:
None
Lower exposure, lower friction:
Starknet, NEAR Protocol, QRL
Higher exposure, higher friction:
Bitcoin, Optimism, Solana, Ethereum, Zcash
Lower exposure, higher friction:
Algorand

How placements work

The rubric assesses post-quantum signing, protection from non-signing components and the action required to migrate user funds. This does not include external dependencies or protocol level data.

Quantum exposure. Exposure combines signing status (0.10 to 0.70) with structural credit for non-signing protections (0.00, 0.10 or 0.20). Higher values mean lower exposure in those components. The assessment excludes consensus signing, bridges and external dependencies.

Migration friction. Friction depends on what fund holders must do. Tier 4 means a mandatory interruption (0.20), tier 3 a scheduled interruption (0.40), tier 2 individual account action (0.60), and tier 1 no user action (0.80). A network with no published migration mechanism receives no friction tier or vertical position.

Exposure covers two surfaces only: the furthest post-quantum status evidenced for user signing, and whether a non-signing layer the chain controls already rests on assumptions a quantum computer does not break. It does not cover consensus signing, bridges, or external dependencies. A network at the low-exposure end is not quantum resistant overall.

Signing status

Six levels, evenly spaced 0.12 apart, measuring the furthest evidenced post-quantum capability on the chain's user-signing path.

Research announced: 0.10
Post-quantum risk is named publicly, but no scheme or mechanism is specified. This is the floor of the scale, so it is also where a chain with no published position sits.
Published roadmap direction: 0.22
A scheme or mechanism is named and a plan exists, but nothing post-quantum is running on the chain's own mainnet.
Demonstrated: 0.34
A working post-quantum instance exists on mainnet, but it is a one-off or reference implementation rather than something an ordinary user can adopt today.
Generally available: 0.46
Any user can adopt a post-quantum path today without special arrangement, but it sits at application layer using existing primitives rather than a protocol-level scheme.
Live at protocol level, opt-in: 0.58
A post-quantum signing scheme is accepted by protocol rules on mainnet, but classical schemes remain the default and most users are still on them.
Live at protocol level, default: 0.70
A post-quantum signing scheme is the default path for new accounts or outputs, not an option alongside a classical default.

Structural credit

Three bands, evenly spaced 0.10 apart, recognising that a chain whose settlement or state integrity already rests on hash-based or post-quantum assumptions is less exposed than one whose does not, independently of what its accounts sign with.

Credit is never awarded for the chain's own user-signing scheme. The status scale already measures that, and awarding both would count the same fact twice. This is why QRL receives no structural credit despite being quantum-native: XMSS is its signing scheme, and it is scored at the top of the status scale instead.

+0.20
A non-signing layer the chain controls, securing state-transition or settlement integrity, rests on hash-based or post-quantum assumptions in production today.
+0.10
A shipped, default-on mitigation at a non-signing layer materially reduces future exposure without providing post-quantum security today.
+0.00
Neither.

Migration friction

Four tiers, evenly spaced 0.20 apart, measuring how much the migration asks of the people who hold funds on the chain. Least friction means nobody has to do anything.

Nobody acts: 0.80
User funds become post-quantum without any action by their owners. Node operators absorb the change, or nothing needs to happen at all.
Individual account acts: 0.60
An account owner completes the change alone, with no coordination and no disruption to anyone who declines.
Scheduled interruption: 0.40
A coordinated protocol change, after which users must act at some point, with no hard cutoff stated.
Mandatory interruption: 0.20
An account that does not act faces a stated consequence: freeze, deprecation, or inability to sign.
No stated mechanism: unassigned
The chain has published no migration mechanism, so there is nothing to tier. Not the same as low friction.
Decision procedure

Ask in order. The first yes wins. This makes the most-friction rule procedural rather than a matter of judgement, and is the check to run when two reviewers disagree.

Status

  • S1. Has the project published anything naming post-quantum risk for this chain? If no, stop: research.
  • S2. Is a post-quantum signing capability running on this chain's own mainnet today? If no, stop: direction.
  • S3. Can any ordinary user adopt it today without special arrangement? If no, stop: demonstrated.
  • S4. Is it application-layer, built on existing primitives rather than a protocol-recognised scheme? If yes, stop: generally available.
  • S5. Is the post-quantum scheme the default for new accounts or outputs? If no, stop: live opt-in. If yes: live default.

Structural credit

  • C0. Before anything else, discard the chain's own user-signing scheme from consideration. The status scale already scores it.
  • C1. Does the chain control a non-signing layer securing state or settlement integrity that rests on hash-based or post-quantum assumptions in production? If yes: 0.20.
  • C2. Otherwise, is there a shipped, default-on mitigation at a non-signing layer that reduces future exposure without providing post-quantum security today? If yes: 0.10.
  • C3. Otherwise: 0.00.

Migration friction

  • T0. Has the chain published a migration mechanism at all? If no, stop: unassigned.
  • T1. Identify the user-fund-bearing path, meaning the surface whose cryptography secures account balances. Tier on that path, not on any other surface the chain has changed. This question has no stop condition; it fixes the subject of the questions below.
  • T2. Does an account on that path, failing to act, face a stated consequence, meaning freeze, deprecation, or inability to sign? If yes, stop: tier 4.
  • T3. Does completing the migration on that path require users to act at some point, delivered through a coordinated protocol change? If yes, stop: tier 3.
  • T4. Can an individual account complete it alone with no coordination? If yes, stop: tier 2.
  • T5. Do user funds become post-quantum with no action by their owners? If yes: tier 1.

T1 is the scope rule and it binds. A chain that has changed several surfaces is tiered on the one securing user balances, not on whichever surface produces the better result. Applying this rule moved Starknet from tier 1 to tier 2 in this version.

Optimism carries a +0.08 y offset so its mark does not sit exactly on Bitcoin's. Starknet, NEAR and QRL share y = 0.60; Starknet and NEAR are 0.04 apart on x and will overlap at typical render sizes. Resolve that with label anchoring rather than by moving the points, since the points are computed.

This map is separate from the capability count and does not certify quantum resistance. It does not measure adoption or external dependencies.

Produced by StarkWare, a core developer of Starknet, which is included in this comparison. Updated 2026-09-28.

Explore the component evidence

See the changes recorded for Starknet and the architecture that supports them.

Explore Starknet’s migration registerSee how Starknet’s architecture supports change

Frequently asked questions

What do exposure and friction mean on the migration map?

Exposure combines post-quantum user-signing status with structural credit for qualifying non-signing protections. Friction measures what migration asks of holders on the path securing their funds. The migration map combines them:

  • Lower exposure · lower friction.
  • Higher exposure · lower friction.
  • Lower exposure · higher friction.
  • Higher exposure · higher friction.
Why does Starknet have more quantum exposure than NEAR and QRL on the migration map?

Because NEAR and QRL users can already sign transactions with post-quantum schemes on mainnet, and standard Starknet users cannot yet. QRL uses XMSS, a hash-based post-quantum signature scheme, as its default and only signing scheme. NEAR accepts ML-DSA-65, the post-quantum scheme NIST standardized in FIPS 204, as a live opt-in on mainnet, and its classical signature schemes remain available and have not been deprecated.

An OpenZeppelin account using Falcon-512 has been demonstrated on Starknet mainnet, but a standard Starknet user cannot adopt it yet, and standard Starknet accounts still sign with elliptic curves. Starknet gets structural credit that NEAR and QRL do not. StarkWare's STARK proofs verify Starknet's state transitions, and they rely on hash functions instead of elliptic curves.

Do Starknet, NEAR and QRL differ on migration friction?

No. All three networks sit in friction tier 2, because a holder on each one can move to post-quantum signing without waiting for a network-wide migration. A Starknet account owner can deploy or upgrade to a post-quantum account. A NEAR account owner can rotate to a new key in one transaction. A QRL holder claims funds individually to the planned ML-DSA-87 destination on Zond. The three networks sit at different points on the map because of their exposure scores

Does a checkmark in the agility table mean the network has already used that capability?

Not necessarily. It means the evidence meets that question’s pass rule. Some checks concern available mechanisms; others require a demonstrated transition. Open the cell to see exactly what was established.

Why can Bitcoin score well in the agility table and still face a difficult migration according to the migration map?

Because mechanisms for changing cryptography do not remove the need to migrate exposed coins. Holders must act, and coins whose keys are lost cannot be moved by their holders. Outputs with visible public keys, including early pay-to-public-key outputs, reused addresses and Taproot outputs, illustrate why a working upgrade mechanism alone does not complete migration. See the draft migration proposal.

Why does QRL show lower exposure and friction on the migration map without a perfect score in the agility table?

Because QRL’s XMSS hash-based signatures avoid an elliptic-curve signing legacy, while the table tests a wider set of change mechanisms. Its planned move to another post-quantum scheme also shows why cryptographic agility continues to matter.

Why does Zcash still show higher exposure on the migration map?

Because its current signatures, proofs and note encryption still have quantum-vulnerable dependencies. Ironwood adds quantum-recoverable notes and a supported route to migrate existing funds. It prepares notes for a future recovery protocol. The agility table credits evidenced migration mechanisms, while the migration map reflects the replacements still required.

Why does NEAR support post-quantum signing but miss Account change in the agility table?

Because adopting a protocol-supported signing scheme is different from installing independently implemented verification code. NEAR’s native ML-DSA-65 keys let existing accounts adopt a protocol-supported signing scheme. The migration map recognises lower friction for the live account path; validator and block-production signatures remain classical.

Which Starknet protocol changes have shipped, and what remains?

The migration register records v0.14.3’s mainnet replacement of Pedersen with a BLAKE2s-256 construction for OS program and configuration hashes. Trie and contract-address changes remain roadmap direction. Tooling for existing contracts with Pedersen-based storage maps remains research, without a published specification or released toolkit.

How does Ethereum affect Starknet’s migration?

It creates migration work that Starknet cannot complete on its own. Starknet normally publishes state diffs as Ethereum blobs, which depend on Ethereum’s KZG scheme. Starknet does not control that scheme’s migration; calldata is an available fallback. See the Ethereum-facing dependency record.

How can I check Starknet’s assessment?

Open a table cell or map circle to inspect its basis and public sources. StarkWare produced the agility table and migration map and is a core developer of Starknet, one of the networks assessed. The agility table’s pass rules were fixed before scoring. Use the migration register to check Starknet’s deployment boundaries.

How can I request a change to the comparison?

Email james.w@starkware.co with the network, the agility table criterion or migration map placement, your suggested change, and links to supporting evidence.

Can Ethereum accounts switch to post-quantum signatures?

It depends on the account. Ordinary Ethereum accounts still use secp256k1 signatures. ERC-4337 smart-contract accounts can implement custom verification, including a suitably implemented post-quantum verifier. That requires a compatible account, wallet and migration path. EIP-7702 delegation alone does not remove the original account’s signing authority.

Which blockchains support post-quantum signatures today?

Examples among the networks assessed here include:

  • QRL uses XMSS signatures.
  • NEAR supports optional ML-DSA-65 account keys.
  • Algorand supports native Falcon-1024 accounts.
  • Starknet has unaudited Falcon-512 account implementations.

These are different levels of availability. Account-signature support does not establish that every account has migrated or that the entire network is post-quantum.

How counts work

The checklist has 8 equally weighted questions. Totals range from 0 to 8 and count the assessed capabilities supported by evidence.

1 point
Meets the question's rule. The path and its prerequisites are available.
0 points
Unsupported or insufficiently evidenced.

Rule for every tick

  • Every tick must have an executable path under current network rules.
  • Any prerequisites must also be available.
  • A later answer cannot borrow capability from an account, algorithm or upgrade that the assessed users cannot currently access.
  • The named mechanism must be a standard native account mechanism or a deployed protocol mechanism.
  • An optional, specially constructed or experimental account does not substitute for a standard-account capability.
  • Evidence must establish the relevant implementation and its practical limits, not merely theoretical programmability.

Network upgrades

  • A cited path that requires a future network upgrade cannot earn a point.
  • A capability enabled by a past upgrade can still earn a point if it remains usable today.

What the count does not establish

  • The total counts the assessed capabilities supported by the evidence. It is not a security rating or a migration-time estimate.
  • Extra algorithm options can add complexity and attack surface.
  • NIST addresses inventories of cryptographic use in CSWP 39-upd1, section 5, printed p. 23. We exclude inventory from the count because public evidence did not establish a repeatable inventory across components for any assessed network.

NIST basis and version

We based the checklist on NIST’s definition of cryptographic agility: the ability to replace and adapt cryptographic algorithms while preserving security and ongoing operations. NIST does not rate these networks. We added the requirement that each cited path work without a new network upgrade.

In the checklist each column is one yes/no question grounded in NIST CSWP 39-upd1.

Version 4.0 fixes the eight scored questions, their rules, scopes and equal weighting. Evidence and answers can change. Changing a rule requires a new rubric version. Each result includes its NIST basis, pass rule, scope, rationale, boundary, sources and review date.

Evidence summary

Each count shows capabilities evidenced within the assessed scope, out of 8. It does not measure quantum safety or completed migration. Expand a network to read an example and a limitation, with sources for each.

Starknet: 8 of 8 evidenced.

Evidenced example

Authorization replaceability: Account change. The deployed Ready/Argent individual account can replace its native verification code in place through an authenticated class upgrade. The documented v0.3.1-to-v0.4.0/v0.5.0 path adds independently implemented signer verification while retaining the account address, storage and assets under existing Starknet rules.

Important boundary

Every assessed check is met for Starknet within the stated scope.

Latest cell review: 2026-09-09.

Bitcoin: 7 of 8 evidenced.

Evidenced example

Authorization replaceability: Flexible formats. Standard native witness interfaces support the assessed change from compressed ECDSA keys and signatures to 32-byte x-only keys and 64- or 65-byte Schnorr signatures. Taproot is active and standard wallet signing is available.

Important boundary

Authorization replaceability: Account change. Ordinary Bitcoin outputs use consensus-defined ECDSA or Schnorr validation. A valid spend can adopt already-enabled Taproot, but it neither retains the existing UTXO nor installs independently implemented verification code.

Limit: The existing UTXO is the account-equivalent object. BIP-342 upgrade hooks require new consensus rules to add native verification semantics. This finding does not rule out every bespoke script construction.

Latest cell review: 2026-09-09.

Algorand: 7 of 8 evidenced.

Evidenced example

Authorization replaceability: Flexible formats. The activated native pqsig envelope accepts a Falcon-1024 public key and signature, which are much larger than Ed25519's. Released account tools support this format with scheme-specific fees.

Important boundary

Authorization replaceability: Account change. Standard rekeying can retain an account and select the activated native Falcon-1024 authorizer. The f1 verifier is enabled by consensus, so the reviewed native path does not introduce independently implemented signature-verification code.

Limit: The ordinary account can change its authorized address and scheme after native activation. LogicSig demonstrations do not substitute for evidence of a current standard-account independent verifier satisfying the frozen criterion.

Latest cell review: 2026-09-09.

NEAR Protocol: 7 of 8 evidenced.

Evidenced example

Authorization replaceability: Flexible formats. The deployed native format supports ML-DSA-65’s 1,952-byte public key and 3,309-byte signature alongside classical keys. Mainnet’s transaction limit is 1,572,864 bytes, and the release specifies an additional 100 Ggas per ML-DSA-65 verification.

Important boundary

Authorization replaceability: Account change. Ordinary native account transactions use protocol-defined Ed25519, secp256k1 or ML-DSA-65 verification. AddKey can select a supported scheme, but cannot install independently implemented verification code for that native signing path.

Limit: ML-DSA-65 is live and usable without another upgrade; it still does not meet this question’s independent-verifier rule. Contract-controlled accounts, delegated execution, Chain Signatures and intents do not substitute for the assessed native access-key path.

Latest cell review: 2026-09-23.

QRL: 6 of 8 evidenced.

Evidenced example

Authorization replaceability: Flexible formats. Ordinary QRL wallets support XMSS height changes such as 10 to 12, whose signatures differ in length but use the same native parser and transaction envelope. The verifier derives and checks signature height against the key descriptor.

Important boundary

Cryptographic separation: Modular updates. The completed CryptoNight-to-RandomX fork demonstrates a historical PoW boundary, but the cited code selects fixed algorithms by block height. The selector provides no operator action to replace active RandomX cryptography under current network rules.

Limit: Historical pre-fork block validation remains available and the 2020 activation is complete. They do not make another active-PoW replacement executable. This review did not establish an alternative supported cryptographic-provider replacement.

Latest cell review: 2026-09-23.

Zcash: 6 of 8 evidenced.

Evidenced example

Authorization replaceability: Flexible formats. The current native transaction interfaces carry transparent ECDSA keys and variable DER signatures alongside shielded RedPallas randomized keys and 64-byte spend signatures. A standard shielding transaction adopts the representative alternative without another format redesign.

Important boundary

Cryptographic separation: Modular updates. The reviewed shielded-proof replacement boundary is fixed by consensus era. NU6.3 replaced the Orchard circuit through a completed activation; the deployed verifier does not provide an operator-selectable replacement for its active proof cryptography today.

Limit: The historical upgrade and native-pool coexistence are established. They do not by themselves provide a currently executable replacement of the active protocol verifier. This review did not establish a separate qualifying transport or provider replacement.

Latest cell review: 2026-09-23.

Ethereum: 3 of 8 evidenced.

Evidenced example

Safe retirement: Existing data. BLSToExecutionChange migrates an existing validator's stored BLS withdrawal-key commitment into an authenticated execution-address credential in the same validator record. Current protocol rules and supported tooling permit an eligible old-key holder to perform the conversion without another network upgrade.

Important boundary

Authorization replaceability: Flexible formats. Ethereum's native EOA interface has no demonstrated working replacement key/signature envelope. Variable transaction data and the earlier Safe WebAuthn payload do not establish flexible native authorization formats.

Limit: A replacement must work on the assessed native authorization path. Variable-length calldata, ERC-4337 signature bytes and optional Safe/passkey support are available on different authorization surfaces and do not establish this capability.

Latest cell review: 2026-09-09.

Solana: 2 of 8 evidenced.

Evidenced example

Cryptographic separation: Modular updates. The released Frankendancer validator replaces Agave's TPU-QUIC cryptographic implementation with fd_quic/fd_tls while retaining Agave runtime and consensus interfaces. The documented operator route and production topology establish a current component replacement without redesigning unrelated network rules.

Important boundary

Safe retirement: Existing data. A native converter for legacy durable-nonce state is available, but the review did not establish an eligible old-state input. Historical mainnet automation is complete, a bounded finalized query found no standard-size initialized legacy nonce accounts, and current native initialization creates Current state. No other currently executable migration of stored state dependent on old cryptography was established.

Limit: UpgradeNonceAccount remains available and has tests showing that it preserves authority. That does not establish a usable migration target today. The query covered one endpoint and slot, and only standard-size accounts. Other stored-state surfaces remain outside that check. The conversion changes the hash-domain construction while retaining SHA-256, so it is not a signing-primitive or post-quantum replacement.

Latest cell review: 2026-09-23.

Optimism: 2 of 8 evidenced.

Evidenced example

Cryptographic separation: Modular updates. Released op-node/v1.19.0 exposes --p2p.security, which selects Noise or TLS transport constructors. Operators can configure a mutually supported secure channel at the libp2p boundary while retaining the rollup's existing derivation and execution rules.

Important boundary

Safe retirement: Existing data. Current withdrawal re-proving retains the same Keccak-derived commitments and inclusion machinery. The reviewed Super Root, shared-dispute-game, verifier-transition and alternative-DA candidates do not establish a currently usable migration of existing OP Mainnet state off its old cryptographic dependency.

Limit: Changing a dispute-game reference or wrapping an output root is not itself replacement of the stored commitment's cryptography. The inspected verifier-transition tests use a mocked verifier and feature gates; the interop migrator is a constrained one-off operation. These limits do not establish that every possible stored-state migration is unavailable.

Latest cell review: 2026-09-23.

Robinhood Chain: 1 of 8 evidenced.

Evidenced example

Cryptographic separation: Modular updates. Robinhood Chain's documented mainnet sequencer feed uses Nitro's separate TLS transport boundary. The prescribed release supports TLS 1.2/1.3 and multiple ciphers. Read-only checks received the same feed sequence over AES-GCM and ChaCha20-Poly1305 without changing the feed message format or chain execution rules.

Important boundary

Staged transition: Tested transition. The mainnet feed has confirmed TLS and cipher interoperability, and Nitro has feed recovery and invalid-signature tests. The reviewed tests do not exercise the deployed feed's cryptographic transport transition with relevant failure and continuity behavior. Coordinator mixed-mode tests remain unlinked to a confirmed Robinhood Chain coordinator deployment.

Limit: Receiving feed data through two valid secure channels establishes availability, not a transition-security test suite or production cutover. Nitro's inspected feed tests use local plaintext WebSockets; generic TLS tests do not alone cover the deployed feed transition. No conclusion about brokerage or wallet infrastructure is used.

Latest cell review: 2026-09-23.

How examples are selected

For each network, we choose the evidenced capability shared by the fewest assessed networks. For the boundary, we choose the criterion that earns the network no point and is met by the most other assessed networks. Open a checklist result for its current execution path, prerequisites and sources.

Checklist evidence

Each checklist result has its own evidence view. The full NIST basis and network evidence are also included here.

Can an existing standard account switch to a new signing scheme without a network upgrade?

NIST basis: Sections 1 and 4 discuss changing cryptography in a system while it remains in operation and separating applications from cryptographic implementations. CSWP 39-upd1, section 1, printed p. 2 · CSWP 39-upd1, section 4, printed p. 16

What counts as yes: A yes needs a documented, deployed account-level mechanism for introducing independently implemented signature-verification code without a network upgrade, while retaining the existing standard account’s address or identity and assets. The evidence must identify the account implementation and its applicable limits. Key rotation or selection among protocol-enabled algorithms alone does not count.

Scope: The ordinary native account-authorization model used by mainstream wallets, including native smart-contract accounts. Optional smart-wallet, vault, or delegated execution does not substitute for changing the standard account’s native signing validation. Assess the named standard implementation, not every custom deployment or every future algorithm.

  • Starknet — Capability evidenced: The deployed Ready/Argent individual account can replace its native verification code in place through an authenticated class upgrade. The documented v0.3.1-to-v0.4.0/v0.5.0 path adds independently implemented signer verification while retaining the account address, storage and assets under existing Starknet rules. Boundary: The assessment covers the named mainstream native account mechanism, not every custom account. The authorized target must be declared, implement the required account and callback interfaces, preserve storage correctly and fit validation limits. Unsupported legacy upgrade sequences can brick an account. Cairo's programmability alone does not establish that a future algorithm will fit.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Ready/Argent native individual-account class upgrade

    Path: Authorize upgrade to a declared compatible account class through the existing account's self-call; use the published supported version sequence and migration callback.

    Prerequisites

    • The named individual account implementation is deployed on Mainnet. — Available: Ready/Argent lists account v0.5.0 class 0x073414441639dcd11d1846f287650a00c60c416b9d3ba45d31c651672125b2c2 on Mainnet, with its source, ABI and deployment artifacts.
    • The present owner and any configured guardian authorize the account administration transaction. — Available: The standard account authenticates calls that administer the account. It provides methods to update owners and guardians, and a user-controlled upgrade method.
    • A compatible replacement implementation and its constrained verification logic are available. — Available: Published v0.4.0/v0.5.0 classes, typed signer implementations and upgrade tests provide a concrete replacement target; the Starknet account interface permits its validation logic within published limits.
    Confidence: High for the deployed standard-account upgrade mechanism and named supported verifier; no live upgrade was submitted by this review. Public source. Checked 2026-09-09. Reassess when the Ready account class, supported upgrade sequence, target-interface policy, signer verifier or Starknet validation restrictions change. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · docs.starknet.io
  • Ethereum — Current execution path blocked: Ethereum's ordinary EOA cannot replace its protocol-defined native secp256k1 signing verifier through an account-level update while retaining the same identity and assets. Boundary: ERC-4337 is live and user-deployed smart-wallet verification needs no new network upgrade. EIP-7702 delegation can retain an EOA address while adding execution policies; the original native EOA signing authority remains outside that policy.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Replacement of ordinary EOA native transaction-signature validation

    Path: No current EOA-level operation introduces an independent native verifier; the cited delegated-code route changes execution policy.

    Prerequisites

    Confidence: High for the documented native EOA rule. The review does not cover every custom wallet. Public source. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not change the result. Source 1 · ethereum.org · Source 2 · raw.githubusercontent.com · Source 3 · eips.ethereum.org · Source 4 · ethereum.org
  • Bitcoin — Reviewed example does not meet rule: Ordinary Bitcoin outputs use consensus-defined ECDSA or Schnorr validation. A valid spend can adopt already-enabled Taproot, but it neither retains the existing UTXO nor installs independently implemented verification code. Boundary: The existing UTXO is the account-equivalent object. BIP-342 upgrade hooks require new consensus rules to add native verification semantics. This finding does not rule out every bespoke script construction.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Ordinary legacy-to-Taproot spend using already-enabled native verification

    Path: Sign the existing output under its committed rule and create a standard Taproot successor. This executable path fails Q1's retained-object and independent-verifier requirements.

    No point: the evidence for this available path does not meet the criterion's rule.

    Prerequisites

    • Taproot and legacy authorization are accepted by current mainnet rules. — Available: Core's maintained implementation list records mainnet activation and the subsequent always-active Taproot validation. Core 22 provides standard wallet support.
    • A released wallet can create and sign the selected ordinary key-only Taproot output. — Available: Core supports Taproot descriptors and signing. The tr(KEY) descriptor creates a Taproot output without a script tree. The owner must control an unspent source output and pay the fee.
    Confidence: The public documentation establishes deployed native output and wallet rules. Those rules do not meet the frozen new-verifier criterion. Public source. Checked 2026-09-09. A deployed standard native mechanism that retains an existing Bitcoin authorization object while installing a named independently implemented verifier. Source 1 · github.com · Source 2 · github.com · Source 3 · bitcoincore.org
  • Solana — Current execution path blocked: Ordinary Solana transaction signers use protocol-validated Ed25519. The existing standard account has no in-place mechanism for introducing independently implemented native signature verification. Boundary: LazorKit and other program-owned smart-wallet paths are optional authorization surfaces, not replacement of standard account signing. This does not deny the utility of programs or supported key management.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Native Ed25519 transaction authorization

    Path: A different independently implemented native transaction verifier would first require protocol support; installing a wallet program does not perform that change.

    Prerequisites

    • A second native transaction-authorizing signature scheme is accepted by existing rules. — Blocked: Ordinary transaction signatures are fixed 64-byte Ed25519 values over the message. Verification by a precompile does not replace native signer authentication.
    Confidence: High for the native-account boundary. Public source. Checked 2026-09-09. An activated standard-account mechanism for replacing native signature verification while preserving the account identity and assets. Source 1 · solana.com · Source 2 · solana.com · Source 3 · solana.com
  • Algorand — Reviewed example does not meet rule: Standard rekeying can retain an account and select the activated native Falcon-1024 authorizer. The f1 verifier is enabled by consensus, so the reviewed native path does not introduce independently implemented signature-verification code. Boundary: The ordinary account can change its authorized address and scheme after native activation. LogicSig demonstrations do not substitute for evidence of a current standard-account independent verifier satisfying the frozen criterion.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Standard AuthAddr rekey to protocol-enabled Falcon-1024

    Path: Generate a native f1 address and authenticate RekeyTo for the existing account. The route is available but fails Q1 because the verifier is supplied by consensus.

    No point: the evidence for this available path does not meet the criterion's rule.

    Prerequisites

    • Native Falcon-1024 authorization is activated on mainnet. — Available: Algorand's official deployment page dates native Falcon-1024 mainnet support to August 2026, after v5.0.0 approval. The release enables the v42 f1 scheme.
    • A native Falcon signer and sufficient transaction fees are available. — Available: The released algokey pq tool generates or imports keys and signs transactions. The documented minimum fee for a basic Falcon transaction is 3,000 microAlgo. The end-to-end workflow creates an unsigned transaction, signs it with algokey and submits it through goal rawsend.
    • The current authorized key can submit a rekey preserving the selected live account. — Available: RekeyTo updates AuthAddr. Later validation uses the new authorizer while the account keeps its address and holdings. The owner must act before losing the old key and keep the account record live.
    Confidence: The public sources establish an executable native rekey path. Selecting an enabled scheme does not meet Q1's explicit rule. Public source. Checked 2026-09-09. A deployed standard-account mechanism introducing a named independently implemented verifier without a new native scheme activation. Source 1 · dev.algorand.co · Source 2 · dev.algorand.co · Source 3 · github.com · Source 4 · github.com
  • QRL — Reviewed example does not meet rule: Classic QRL's ordinary account verifier is native XMSS. Supported hash/height descriptors select enabled parameters; they do not let an existing address install independently implemented signature-verification code. Boundary: Standard hash/height variants are available, but changing them creates a successor address. Reserved descriptor values and Zond roadmap/testnet work do not establish the assessed existing-account capability.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native XMSS verification and supported successor-parameter selection

    Path: Use the standard XMSS validator and wallet-supported hash/height choices. This route does not meet Q1's requirements for an independent verifier and a retained address.

    No point: the evidence for this available path does not meet the criterion's rule.

    Prerequisites

    • The selected XMSS hash and height are supported by ordinary QRL tooling and native verification. — Available: Wallet documentation lists SHA2-256, SHAKE128, SHAKE256 and heights 8 through 18. The native descriptor selects the supported hash and height for the qrllib verifier, without a custom account.
    Confidence: Public-source constraint: the deployed native address and verifier rules establish parameter selection, not independent verifier installation. Public source. Checked 2026-09-09. A deployed classic-mainnet standard-address path introducing an independent verifier while retaining existing identity and holdings. Source 1 · docs.theqrl.org · Source 2 · github.com · Source 3 · github.com · Source 4 · theqrl.org
  • Optimism — Current execution path blocked: OP Mainnet's ordinary EOA cannot replace its protocol-defined native secp256k1 signing verifier through an account-level update while retaining the same identity and assets. Boundary: ERC-4337 is live and user-deployed smart-wallet verification needs no new network upgrade. EIP-7702 delegation can retain an EOA address while adding execution policies; the original native EOA signing authority remains outside that policy.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Replacement of ordinary EOA native transaction-signature validation

    Path: No current EOA-level operation introduces an independent native verifier; the cited delegated-code route changes execution policy.

    Prerequisites

    Confidence: Qualified: OP's documented EVM equivalence supports the native-EOA inference; no independent op-reth execution was performed. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.optimism.io · Source 2 · eips.ethereum.org · Source 3 · ethereum.org
  • Robinhood Chain — Current execution path blocked: Robinhood Chain's ordinary EOA cannot replace its protocol-defined native secp256k1 signing verifier through an account-level update while retaining the same identity and assets. Boundary: Current Robinhood documentation explicitly supports ERC-4337 and EIP-7702 on chain 4663. Those live programmable/delegated account routes do not require a new network upgrade, but do not replace ordinary EOA native signature validation.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Replacement of ordinary EOA native transaction-signature validation

    Path: No current EOA-level operation introduces an independent native verifier; the cited delegated-code route changes execution policy.

    Prerequisites

    Confidence: Qualified: current Robinhood mainnet documentation establishes the supported EVM account model and delegation, not an independent client-to-deployment audit. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.robinhood.com · Source 2 · docs.robinhood.com · Source 3 · docs.robinhood.com · Source 4 · eips.ethereum.org
  • Zcash — Current execution path blocked: Standard Zcash transparent outputs and shielded notes use consensus-defined verification. Moving funds to a supported shielded pool does not let the existing output or note install independently implemented signature-verification code. Boundary: Unified addresses and reuse of Orchard key material across Orchard and Ironwood do not introduce a user-programmable verifier. Optional threshold signing does not change the native verification algorithm.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Consensus-defined transparent and shielded authorization

    Path: Introducing a different native signature verifier requires a protocol change; ordinary sends only choose already-enabled authorization.

    Prerequisites

    • The existing native object must accept independently implemented verification code without a new consensus rule. — Blocked: The released verifier dispatches to the prescribed transparent, Sapling and Orchard/Ironwood validators; native bundles do not carry arbitrary verifier code.
    Confidence: Documented: primary specifications, released implementation and stated deployment establish the named rule; no fresh transaction was executed. Public source. Checked 2026-09-23. A deployed native mechanism that lets an existing ordinary Zcash output or note retain its identity and assets while installing independent verifier code. Source 1 · zips.z.cash · Source 2 · github.com · Source 3 · zips.z.cash
  • NEAR Protocol — Current execution path blocked: Ordinary native account transactions use protocol-defined Ed25519, secp256k1 or ML-DSA-65 verification. AddKey can select a supported scheme, but cannot install independently implemented verification code for that native signing path. Boundary: ML-DSA-65 is live and usable without another upgrade; it still does not meet this question’s independent-verifier rule. Contract-controlled accounts, delegated execution, Chain Signatures and intents do not substitute for the assessed native access-key path.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Protocol-defined native signature verification

    Path: AddKey selects an enabled native key type. Introducing another independent verifier into ordinary transaction validation requires a protocol implementation change and activation.

    Prerequisites

    • Independently implemented verification code must be installable through the standard account authorization path. — Blocked: The native key-type enum and signature verifier dispatch are fixed protocol implementation variants; account actions register keys and permissions rather than verifier code.
    Confidence: High for the ordinary native access-key verification boundary. Public source. Checked 2026-09-23. Reassess after changes to native verification dispatch, protocol-supported key types or the standard account model. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · docs.near.org

Can cryptographic interfaces accommodate different key and signature sizes without redesign?

NIST basis: Section 6.2 cautions against interfaces, buffers, memory, and storage assumptions tied to one algorithm or parameter size. CSWP 39-upd1, section 6.2, printed p. 28

What counts as yes: A yes needs documented interface support for the representative key and signature sizes without redesign, plus stated resource limits. Generic code flexibility is insufficient.

Scope: Standard native account-authorization wire and interface formats, assessed using one named, working representative replacement size; not every possible future algorithm.

  • Starknet — Capability evidenced: Ready/Argent's standard signature array supports both the Stark and Secp256r1 signer formats. A Stark signer uses one felt for its public key and two for its signature. A Secp256r1 signer uses a u256 public key, u256 r and s values, and parity. Both formats use the same native transaction signature list. Boundary: The supported Secp256r1 signer is the assessed example. Experimental Falcon and arbitrary future signature sizes are outside this finding. Current documentation limits signatures to 4,000 felts and validation to 1,000,000 Cairo steps/100,000,000 gas.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Variable-length native signature list with typed Ready signer serialization

    Path: Use the deployed standard account's Secp256r1 signer envelope through its existing signature array and Starknet transaction signature list.

    Prerequisites

    • The named individual account implementation is deployed on Mainnet. — Available: Ready/Argent lists account v0.5.0 class 0x073414441639dcd11d1846f287650a00c60c416b9d3ba45d31c651672125b2c2 on Mainnet, with its source, ABI and deployment artifacts.
    • The replacement key and verifier are supported by the standard account and existing validation rules. — Available: The published native account supports Secp256r1 alongside Stark signatures, with a signature enum, verifier, signing client and test code. This evidence concerns that standard account, not a custom Falcon account.
    • The representative envelope fits documented interface and resource constraints. — Available: The declared account provides this signer path and integration transfers for it; its small fixed Secp256r1 envelope is within the 4,000-felt signature limit. Validation remains subject to the protocol's step/gas caps.
    Confidence: High for the documented formats and implemented standard signer path; upstream integration source was reviewed, not executed. Public source. Checked 2026-09-09. Changes to native signature-list limits, validation resources, Ready signer serialization or supported signer implementations. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · docs.starknet.io · Source 5 · docs.starknet.io · Source 6 · docs.starknet.io
  • Ethereum — Current execution path blocked: Ethereum's native EOA interface has no demonstrated working replacement key/signature envelope. Variable transaction data and the earlier Safe WebAuthn payload do not establish flexible native authorization formats. Boundary: A replacement must work on the assessed native authorization path. Variable-length calldata, ERC-4337 signature bytes and optional Safe/passkey support are available on different authorization surfaces and do not establish this capability.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Native EOA key/signature format replacement

    Path: Existing transaction signature values are processed by the fixed native EOA verifier; no in-scope replacement-size transaction is established.

    Prerequisites

    Confidence: High for the documented native EOA rule. The review does not cover every custom wallet. Public source. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not change the result. Source 1 · ethereum.org · Source 2 · raw.githubusercontent.com · Source 3 · eips.ethereum.org · Source 4 · ethereum.org · Source 5 · eips.ethereum.org
  • Bitcoin — Capability evidenced: Standard native witness interfaces support the assessed change from compressed ECDSA keys and signatures to 32-byte x-only keys and 64- or 65-byte Schnorr signatures. Taproot is active and standard wallet signing is available. Boundary: This covers the named ECDSA-to-Schnorr formats under existing witness and transaction-weight limits. It does not establish arbitrary future signature sizes or permissionless verifier installation.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Activated native SegWit/Taproot witness encodings

    Path: Use standard Core wallet P2WPKH and key-only P2TR outputs; serialize and validate their specified key/signature forms under current rules.

    Prerequisites

    • Taproot and legacy authorization are accepted by current mainnet rules. — Available: Core's maintained implementation list records mainnet activation and the subsequent always-active Taproot validation. Core 22 provides standard wallet support.
    • A released wallet can create and sign the selected ordinary key-only Taproot output. — Available: Core supports Taproot descriptors and signing. The tr(KEY) descriptor creates a Taproot output without a script tree. The owner must control an unspent source output and pay the fee.
    • Representative sizes fit stated resource bounds. — Available: BIP-341 specifies 32-byte output keys and 64/65-byte Schnorr signatures; BIP-141 defines witness serialization and the 4,000,000-weight block limit, with tapscript limits in BIP-342.
    Confidence: The deployed specifications and released wallet support document this format change. No new node execution was performed. Public source. Checked 2026-09-09. Native witness encoding, Schnorr signature limits, transaction policy or standard wallet support changes. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · bitcoincore.org
  • Solana — Current execution path blocked: Ordinary native transactions fix each signer signature at 64 bytes for Ed25519. Separate signature-verification precompiles and arbitrary program data do not establish a working replacement-sized native authorization envelope. Boundary: Current documented transaction size is 1,232 bytes. The announced larger transaction limit is not treated as activated evidence, nor would a larger message alone change the fixed native signature type.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Fixed native transaction signature format

    Path: The selected native transaction signature field cannot carry an alternative-sized authorizer under current documented rules.

    Prerequisites

    • A second native transaction-authorizing signature scheme is accepted by existing rules. — Blocked: Ordinary transaction signatures are fixed 64-byte Ed25519 values over the message. Verification by a precompile does not replace native signer authentication.
    • A working representative replacement fits the current native signature wire format. — Blocked: The documented native field is a 64-byte Ed25519 signature; precompile inputs occupy a different program-verification surface.
    Confidence: High for the documented native wire format and scope exclusion. Public source. Checked 2026-09-09. Activation of a native replacement signature/key format and a demonstrated standard-account path within current resource limits. Source 1 · solana.com · Source 2 · solana.com
  • Algorand — Capability evidenced: The activated native pqsig envelope accepts a Falcon-1024 public key and signature, which are much larger than Ed25519's. Released account tools support this format with scheme-specific fees. Boundary: The representative is native f1 after v42 activation, not the earlier constrained LogicSig demonstration. Falcon-512 and arbitrary new schemes are not enabled by this finding; size and fee limits still apply.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native pqsig transaction envelope for Falcon-1024

    Path: Use released algokey pq signing and the f1 envelope under active v42 rules.

    Prerequisites

    • Native Falcon-1024 authorization is activated on mainnet. — Available: Algorand's official deployment page dates native Falcon-1024 mainnet support to August 2026, after v5.0.0 approval. The release enables the v42 f1 scheme.
    • A native Falcon signer and sufficient transaction fees are available. — Available: The released algokey pq tool generates or imports keys and signs transactions. The documented minimum fee for a basic Falcon transaction is 3,000 microAlgo. The end-to-end workflow creates an unsigned transaction, signs it with algokey and submits it through goal rawsend.
    • The concrete key/signature envelope is accepted and bounded. — Available: The account guide documents roughly 1.8 KB keys and 1.2 KB signatures; verification tests check encode/decode and reject malformed keys or oversized signatures.
    Confidence: Qualified: the official mainnet deployment statement, released tooling and validation tests establish a native path; the audit did not sign a mainnet transaction. Qualified inference. Checked 2026-09-09. Mainnet PQ registry, pqsig size bounds, fee contribution or released signer support changes. Source 1 · dev.algorand.co · Source 2 · algorand.co · Source 3 · github.com · Source 4 · github.com
  • QRL — Capability evidenced: Ordinary QRL wallets support XMSS height changes such as 10 to 12, whose signatures differ in length but use the same native parser and transaction envelope. The verifier derives and checks signature height against the key descriptor. Boundary: The representative is a supported XMSS parameter replacement with a fixed 67-byte extended public key. The parser's height-254 ceiling does not establish practical wallet or deployment support; arbitrary signature families and variable public-key lengths are not established.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Standard XMSS variable-height signature encoding

    Path: Create standard height-10 and height-12 native XMSS accounts with released wallet tooling; their differing signature lengths use the same parser and transfer format.

    Prerequisites

    • The selected XMSS hash and height are supported by ordinary QRL tooling and native verification. — Available: Wallet documentation lists SHA2-256, SHAKE128, SHAKE256 and heights 8 through 18. The native descriptor selects the supported hash and height for the qrllib verifier, without a custom account.
    • The named sizes fit native parsing and transaction limits. — Available: qrllib computes a fixed signature base plus 32 bytes per tree level and verifies descriptor agreement. TransferTransaction limits a serialized transfer to 8,497 bytes. Ordinary height-10/12 signatures fit this bound with a simple transfer.
    Confidence: Qualified: current wallet documentation, native parsing rules and transfer bounds support this limited parameter-size path. No newly generated address or transaction was tested. Qualified inference. Checked 2026-09-09. Changes to wallet-supported heights, native signature parsing or transaction-size limits; evidence of a required redesign for the named height-10-to-12 path. Source 1 · docs.theqrl.org · Source 2 · github.com · Source 3 · github.com
  • Optimism — Current execution path blocked: OP Mainnet's native EOA interface has no demonstrated working replacement key/signature envelope. Variable transaction data and Safe WebAuthn payloads do not establish flexible native authorization formats. Boundary: The replacement must work on the assessed native authorization path. Variable-length calldata, ERC-4337 signature bytes and optional Safe/passkey support belong to different authorization surfaces.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Native EOA key/signature format replacement

    Path: Existing transaction signature values are processed by the fixed native EOA verifier; no in-scope replacement-size transaction is established.

    Prerequisites

    Confidence: Qualified: OP's documented EVM equivalence supports the native-EOA inference; no independent op-reth execution was performed. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.optimism.io · Source 2 · eips.ethereum.org · Source 3 · ethereum.org · Source 4 · eips.ethereum.org
  • Robinhood Chain — Current execution path blocked: Robinhood Chain's native EOA interface has no demonstrated working replacement key/signature envelope. Variable transaction data and Safe WebAuthn payloads do not establish flexible native authorization formats. Boundary: The replacement must work on the assessed native authorization path. Variable-length calldata, ERC-4337 signature bytes and optional Safe/passkey support belong to different authorization surfaces.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Native EOA key/signature format replacement

    Path: Existing transaction signature values are processed by the fixed native EOA verifier; no in-scope replacement-size transaction is established.

    Prerequisites

    Confidence: Qualified: current Robinhood mainnet documentation establishes the supported EVM account model and delegation, not an independent client-to-deployment audit. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.robinhood.com · Source 2 · docs.robinhood.com · Source 3 · docs.robinhood.com · Source 4 · eips.ethereum.org · Source 5 · eips.ethereum.org
  • Zcash — Capability evidenced: The current native transaction interfaces carry transparent ECDSA keys and variable DER signatures alongside shielded RedPallas randomized keys and 64-byte spend signatures. A standard shielding transaction adopts the representative alternative without another format redesign. Boundary: The representative is transparent-to-Ironwood authorization under already-activated rules, not arbitrary future signature sizes. Ironwood and Orchard themselves both use RedPallas; their pool migration alone is not a differently sized signature example. Transactions remain bounded by the 2,000,000-byte block limit.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Activated native transparent and shielded authorization encodings

    Path: Use released wallet shielding to move an ordinary transparent output into an Ironwood note; subsequent spends use the documented 32-byte randomized key and 64-byte RedPallas authorization.

    Prerequisites

    • The selected native pools and v6 format are active on mainnet. — Available: The mainnet announcement confirms NU6.3 at height 3,428,143 on 28 July 2026; Zebra 6.0.0 implements that activation and the Ironwood rules.
    • A standard wallet supports spending transparent funds into the native shielded pool. — Available: Zodl documents transparent exchange deposits and a Shield action to the wallet shielded address. NU6.3 directs newly shielded value into Ironwood; current wallet releases support it.
    • The named key and signature sizes fit the current native wire encoding and resource limit. — Available: Transparent authorization supports compressed 33-byte keys and DER signatures up to 73 bytes including the sighash byte. The shielded action carries a 32-byte randomized key and 64-byte authorization signature. The released parser handles native components and limits transaction input to MAX_BLOCK_BYTES (2,000,000).
    Confidence: Qualified: source-backed interpretation of the named surface; no independent node, wallet or cryptographic testing was executed. Qualified inference. Checked 2026-09-23. Changes to standard shielding, the native key/signature encodings, transaction-size limits or wallet availability. Source 1 · zips.z.cash · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · support.zodl.com · Source 7 · zodl.com
  • NEAR Protocol — Capability evidenced: The deployed native format supports ML-DSA-65’s 1,952-byte public key and 3,309-byte signature alongside classical keys. Mainnet’s transaction limit is 1,572,864 bytes, and the release specifies an additional 100 Ggas per ML-DSA-65 verification. Boundary: The evidence covers one working native replacement size, not arbitrary future schemes. The full key travels on the wire while a 32-byte domain-separated SHA3-256 handle indexes the stored key; wallet and contract code that assumed small classical keys may need updates.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Tagged native ML-DSA-65 key/signature formats

    Path: Use an enabled ML-DSA-65 access key to submit a transaction within the current serialized-size, fee and storage limits.

    Prerequisites

    Confidence: High for the deployed representative sizes and stated resource bounds. Public source. Checked 2026-09-23. Reassess after changes to key/signature encodings, transaction-size limits, verification gas or supported client tooling. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com

Can a cryptographic component be replaced without redesigning unrelated parts of the network?

NIST basis: Sections 3 and 4.2 discuss modular insertion, separation of cryptographic implementations, and replaceable or patchable crypto modules. CSWP 39-upd1, section 3, printed p. 7 · CSWP 39-upd1, section 4.2, printed p. 18

What counts as yes: A yes needs a demonstrated replacement boundary that reaches the named component without redesigning unrelated components; a proxy, upgrade syscall, or lack of an external dependency alone is insufficient.

Scope: A deployed protocol cryptographic component outside user authorization, with its critical external dependencies named; not arbitrary application code or every cryptographic layer.

  • Starknet — Capability evidenced: The live compiled-class-hash migration changes the class-trie value from Poseidon to Blake-based hashing when a qualifying existing class executes. Account authorization and contract execution continue to use the same class-hash interfaces. Boundary: The replaceable component is compiled-class-hash computation and its mapping only. Compatible sequencer/OS, state-diff handling, proof verification and Ethereum settlement remain dependencies; storage keys, addresses and all other commitments are outside this claim.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Mainnet compiled-class-hash lazy migration

    Path: Execute an eligible already-declared Cairo 1 class successfully; activated protocol rules migrate its compiled-class-hash mapping without a new network upgrade.

    Prerequisites

    • The compiled-class-hash migration rules are already activated. — Available: Official version notes identify Starknet v0.14.1 as live on Mainnet. Its migration applies to classes used by successful transactions that do not revert.
    • The old class can still execute and the migrated mapping is included in the verified state update. — Available: The documented trigger is successful execution; executor tests preserve execution and assert migrated mappings in the finalized state diff, while Cairo 0 and ineligible configurations are excluded.
    Confidence: High for the documented scope of the current Mainnet migration. This does not establish that all historical state has migrated. Public source. Checked 2026-09-09. Changes to activated hash migration rules, eligible classes, state-diff verification or proof/settlement dependencies. Source 1 · docs.starknet.io · Source 2 · community.starknet.io · Source 3 · github.com
  • Ethereum — Capability evidenced: Released Geth v1.17.5 exposes --crypto.kzg gokzg|ckzg and calls UseCKZG during startup. An operator can select a different KZG implementation through the existing component interface without changing network rules or redesigning unrelated components. Boundary: This is implementation replacement of the same KZG algorithm, with the same trusted setup, BLS12-381 assumptions, commitment/proof encodings, blob rules and consensus clients. It is not replacement of KZG itself or a post-quantum transition. CKZG requires a supported CGO build/platform.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Geth KZG provider replacement: Go implementation to C implementation

    Path: On a supported released Geth build with CKZG included, restart with --crypto.kzg ckzg (or gokzg). Startup validates the selector and initializes the chosen backend.

    Prerequisites

    Confidence: High for the released CLI path to the provider. The review inspected the source and official release and build paths, but did not build or restart a node. Public source. Checked 2026-09-09. Removal or breakage of the released operator selector, build/platform support, shared KZG API or setup; an algorithm-replacement claim requires separate evidence. Source 1 · github.com · Source 2 · raw.githubusercontent.com · Source 3 · raw.githubusercontent.com · Source 4 · raw.githubusercontent.com · Source 5 · raw.githubusercontent.com
  • Bitcoin — Capability evidenced: Released Bitcoin Core can use BIP-324 encrypted v2 P2P transport at the transport boundary while retaining transaction authorization and consensus rules. v2 has been enabled by default since Core 27.0. Boundary: The component is P2P transport, with compatible peers and the BIP-324 implementation as dependencies. v1 fallback remains; this is neither an all-peer deployment claim nor downgrade protection for transport.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: BIP-324 v2 transport replacing the v1 transport on supported connections

    Path: Run a released Core node with v2 enabled and connect to a v2-capable peer; current consensus and transaction validation remain unchanged.

    Prerequisites

    • Both endpoints implement the released v2 transport. — Available: Core 27.0 enables BIP-324 by default; the release documents v1 retry for incompatible/failed connections.
    • The replacement remains behind the P2P message boundary. — Available: BIP-324 specifies the encrypted transport/framing independently of transaction authorization; it names its ECDH, cipher and peer-handshake dependencies.
    Confidence: The specification and default-on release document an available protocol option. No peer-fleet census or new transport test was performed. Public source. Checked 2026-09-09. BIP-324 support/defaults, compatible-peer availability or the transport-to-message boundary changes. Source 1 · github.com · Source 2 · bitcoincore.org · Source 3 · github.com
  • Solana — Capability evidenced: The released Frankendancer validator replaces Agave's TPU-QUIC cryptographic implementation with fd_quic/fd_tls while retaining Agave runtime and consensus interfaces. The documented operator route and production topology establish a current component replacement without redesigning unrelated network rules. Boundary: The assessment covers a transport implementation, not native signing or arbitrary new cryptography. No operator cipher-selector flag was identified in Agave. Its endpoint retains three TLS 1.3 suites but fixes key exchange to X25519. Frankendancer supports the common AES-128 suite with X25519 and Ed25519. Setup or restart is required. Uninterrupted operation and post-quantum protection are not claimed.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Released TPU-QUIC implementation replacement: Agave Quinn/rustls to Frankendancer fd_quic/fd_tls

    Path: Build and run the supported Frankendancer mainnet release with the existing validator identity/vote configuration and compatible ledger in place of Agave networking. Compatible TPU clients negotiate the common TLS parameters; the Agave runtime and consensus interfaces remain in use without a new network-rule activation.

    Prerequisites

    Confidence: Medium. Released production integration, an operator workflow and historical mainnet adoption support this limited implementation change. The review did not execute a validator migration. Qualified inference. Checked 2026-09-22. A change to the supported Frankendancer release, Agave integration, shared ledger formats or TPU TLS compatibility; or evidence that the documented component-replacement path no longer operates under current rules. Source 1 · github.com · Source 2 · docs.firedancer.io · Source 3 · solana.com · Source 4 · github.com · Source 5 · github.com · Source 6 · docs.firedancer.io · Source 7 · github.com · Source 8 · github.com · Source 9 · github.com · Source 10 · github.com · Source 11 · github.com · Source 12 · github.com · Source 13 · github.com · Source 14 · github.com · Source 15 · docs.firedancer.io
  • Algorand — Capability evidenced: The official mainnet P2P launch and current Hybrid operator guide support the availability of libp2p, despite a conflicting status in the README. The released MakeHost function selects Noise at the GossipNode transport boundary, while native authorization and consensus validation remain separate. Boundary: The component is transport security, with libp2p Noise, TCP/Yamux, peer identities and compatible repeaters as dependencies. The release README still says experimental; the explicit mainnet launch and current recommended Hybrid guidance support availability, not a claim that every peer migrated.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Released Noise/libp2p transport through native Hybrid networking

    Path: Enable the documented Hybrid mode on a released node and connect to the live mainnet P2P mesh; the existing message/validation boundary remains in use.

    Prerequisites

    • The transport option is offered for mainnet operation. — Available: The December 2025 Foundation launch says mainnet live; current node documentation recommends Hybrid. These are stronger deployment evidence than the unrevised experimental README, whose inconsistency is retained.
    • Released transport code reaches cryptographic protection without changing account verification. — Available: MakeHost explicitly selects Noise over TCP/Yamux; the integration document places legacy/P2P implementations behind GossipNode and retains non-transaction message serialization.
    Confidence: Qualified. Deployment records and current operator guidance support this native protocol option, but the README's conflicting status remains unresolved and requires review. Qualified inference. Checked 2026-09-09. Maintainer clarification that Hybrid remains experimental or unsupported, or changes to Noise selection, compatible repeaters or the GossipNode boundary. Source 1 · algorand.co · Source 2 · dev.algorand.co · Source 3 · github.com · Source 4 · github.com
  • QRL — Current execution path blocked: The completed CryptoNight-to-RandomX fork demonstrates a historical PoW boundary, but the cited code selects fixed algorithms by block height. The selector provides no operator action to replace active RandomX cryptography under current network rules. Boundary: Historical pre-fork block validation remains available and the 2020 activation is complete. They do not make another active-PoW replacement executable. This review did not establish an alternative supported cryptographic-provider replacement.

    Path availability

    Status: Blocked. Scope: Protocol component. New network upgrade required: Yes.

    Mechanism: Replacing active RandomX through the cited consensus PoW selector

    Path: Changing the active PoW algorithm in the height-selected native verifier would require validators and miners to adopt new consensus rules. The existing selector chooses between already-activated rules by block height.

    Prerequisites

    • The replacement algorithm must be valid for new blocks under current consensus rules. — Blocked: PoWValidator and Qryptonight select the fixed post-fork RandomX implementation. Current mining documentation names RandomX; the historical Bromine fork is the evidence of how that rule was changed, not a current user-selectable replacement.
    • A supported operator-selectable cryptographic replacement must reach the component without a new protocol activation. — Not established: The reviewed deployed selector exposes a block-height rule, not a documented interchangeable active cryptographic provider. No qualifying replacement was established. That does not show that one is impossible.
    Confidence: Public-source constraint: the active hash/PoW selector is consensus-fixed; evidence for another current standard protocol replacement path was not established. Public source. Checked 2026-09-09. A released standard QRL protocol cryptographic-provider replacement that operates under current rules, or an activated new replacement mechanism. Source 1 · theqrl.org · Source 2 · docs.theqrl.org · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com
  • Optimism — Capability evidenced: Released op-node/v1.19.0 exposes --p2p.security, which selects Noise or TLS transport constructors. Operators can configure a mutually supported secure channel at the libp2p boundary while retaining the rollup's existing derivation and execution rules. Boundary: This covers the standard node's P2P transport component only. A connection requires peer support for the selected transport; Noise is the default. Discovery and peer identity remain secp256k1. Ethereum data availability, Ethereum settlement and the execution client remain critical dependencies. No fleet-wide transition is claimed.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: OP node libp2p Noise/TLS transport replacement

    Path: Configure supported op-node peers with --p2p.security noise,tls for overlap, then select tls on the connection endpoints. The loader installs the chosen security transports into the same libp2p host; no rollup-rule change is involved.

    Prerequisites

    Confidence: Qualified: released CLI, loader and host construction establish an executable operator path; this audit did not run two OP nodes or survey peers' active transport settings. Public source. Checked 2026-09-09. A supported op-node release removing the selection or either transport, changed peer requirements, or evidence that the declared component boundary cannot operate under current OP rules. Source 1 · github.com · Source 2 · raw.githubusercontent.com · Source 3 · raw.githubusercontent.com · Source 4 · raw.githubusercontent.com · Source 5 · specs.optimism.io
  • Robinhood Chain — Capability evidenced: Robinhood Chain's documented mainnet sequencer feed uses Nitro's separate TLS transport boundary. The prescribed release supports TLS 1.2/1.3 and multiple ciphers. Read-only checks received the same feed sequence over AES-GCM and ChaCha20-Poly1305 without changing the feed message format or chain execution rules. Boundary: This covers the sequencer-feed transport to its public TLS endpoint only. Certificate authorities, endpoint TLS policy and compatible clients remain dependencies. Feed-signature verification, native account signatures, state commitments, Ethereum settlement and Ethereum data availability are separate and unchanged. It does not establish a rollout across the network or replacement of those other components.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: TLS cryptography replacement at Robinhood Chain's deployed sequencer-feed transport boundary

    Path: Connect a compatible client to the documented mainnet WSS feed. Nitro's broadcast client creates a TLS connection with a TLS 1.2 minimum and the Go library's supported negotiation path. The live endpoint delivered feed sequence 70393356 under TLS 1.2 with AES-128-GCM and TLS 1.3 with ChaCha20-Poly1305. This changes the secure channel without changing the signed feed message structure, chain state rules or L1 derivation.

    Prerequisites

    • A deployed Robinhood Chain protocol surface and released client implementation — Available: The mainnet full-node guide prescribes Nitro v3.11.2-3599aca and explicitly links the WSS sequencer feed. The pinned broadcast-client connect function supplies the feed headers and a TLS configuration independently of message handling.
    • Available alternative secure-channel cryptography on the actual endpoint — Available: The client build uses Go 1.25 and its TLS support. On 2026-09-23 the official mainnet feed accepted certificate-validated TLS 1.2/AES-128-GCM and TLS 1.3/ChaCha20-Poly1305 connections; both upgraded to WebSocket and returned complete feed JSON with the same first sequence. Endpoint and client compatibility are required; no new consensus rule is involved.
    • A defined component boundary preserving unrelated mechanisms and naming external dependencies — Available: TLS protects the connection to the public feed endpoint. The separate feed decoder retains sequence, message, block hash and signatureV2 fields and calls its own signature-verification path. Endpoint TLS policy and certificate trust remain transport dependencies; native accounts, state commitments and Ethereum execution/beacon inputs remain outside the credited boundary.
    Confidence: Qualified: official chain instructions and pinned client source establish the integration; certificate-validated live connections on 2026-09-23 received complete feed JSON under two TLS/cipher combinations. The probe used a separate client, did not validate feed signatures or reproduce the Nitro image, and is not a transition-security test suite. Qualified inference. Checked 2026-09-23. A change to the prescribed Nitro TLS path, the official feed endpoint's supported TLS/cipher policy, certificate or peer requirements, or evidence that the transport cannot operate independently of unrelated chain components. Source 1 · docs.robinhood.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · pkg.go.dev · Source 6 · github.com · Source 7 · github.com
  • Zcash — Current execution path blocked: The reviewed shielded-proof replacement boundary is fixed by consensus era. NU6.3 replaced the Orchard circuit through a completed activation; the deployed verifier does not provide an operator-selectable replacement for its active proof cryptography today. Boundary: The historical upgrade and native-pool coexistence are established. They do not by themselves provide a currently executable replacement of the active protocol verifier. This review did not establish a separate qualifying transport or provider replacement.

    Path availability

    Status: Blocked. Scope: Protocol component. New network upgrade required: Yes.

    Mechanism: Consensus-era selection of shielded-proof verifying keys

    Path: Changing the active native proof system or its consensus verifying key needs a network activation; replaying historical keys or selecting a supported pool is not that replacement.

    Prerequisites

    • A replacement of the active protocol cryptographic verifier must already be valid under current rules. — Blocked: The released code selects the historical, NU6.2 or NU6.3 Orchard verifying key by network upgrade; v6 always uses the NU6.3 verifier. ZIP200 defines coordinated consensus changes.
    Confidence: Documented: primary specifications, released implementation and stated deployment establish the named rule; no fresh transaction was executed. Public source. Checked 2026-09-23. A released, demonstrated protocol cryptographic-provider or transport replacement operable under current consensus rules without redesigning unrelated components. Source 1 · github.com · Source 2 · zips.z.cash · Source 3 · zips.z.cash · Source 4 · github.com
  • NEAR Protocol — Capability evidenced: Within the P2P peer-authentication component, released nearcore 2.13.4 loads an algorithm-tagged node identity separately from the validator signer. A secp256k1 node key uses the existing typed wire formats and the edge, routed-message and snapshot-host signature-verification paths. It replaces Ed25519 peer authentication without changing account authorization or consensus rules. Boundary: This is an operator-configured peer-identity replacement, not arbitrary cryptography or a quantum-safe transport claim. Preparing the alternative key file uses released near-crypto APIs; neard init still defaults to Ed25519. The peer ID changes, so pinned peer references must be updated. Peers must support the typed scheme; validator signing, Ristretto randomness, account rules and SHA-256 commitments remain separate dependencies. No live fleet adoption or newly executed mixed-scheme test is claimed.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: nearcore node-key selection for P2P peer-authentication signatures

    Path: Use the released near-crypto key-generation, public-key derivation and KeyFile serialization APIs offline to prepare a matching secp256k1 node_key.json with account_id node. Keep the validator key unchanged. Start released nearcore with that configured node key, update peer-ID references, and connect to compatible released peers. The existing handshake, routing and snapshot-host paths use the selected node key and typed verification without a protocol upgrade.

    Prerequisites

    Confidence: Qualified: the released configuration, serialization and production validation paths establish that the named component can use the selected key. Offline key-file preparation and a mixed-scheme node connection were traced in source, not executed in this audit. Qualified inference. Checked 2026-09-23. A supported release restricting node-key schemes or changing typed peer authentication; a demonstrated incompatibility in the configured secp256k1 peer path; or operator documentation and mixed-scheme test evidence that improves confidence. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com · Source 7 · github.com · Source 8 · github.com · Source 9 · github.com · Source 10 · github.com · Source 11 · github.com · Source 12 · github.com · Source 13 · github.com

Can old and new cryptography run side by side while users migrate?

NIST basis: Sections 3.2 and 3.2.1 discuss introducing a new algorithm before retiring an old one while preserving interoperability. CSWP 39-upd1, section 3.2, printed p. 9 · CSWP 39-upd1, section 3.2.1, printed p. 11

What counts as yes: A yes needs supported old-and-new authorization in the same assessed system and a route for users to adopt it; a roadmap, testnet, or unrelated application demonstration is insufficient.

Scope: Standard native user-account authorization, with supported old-and-new authorization and a current user adoption route; a coordinated activation may precede coexistence.

  • Starknet — Capability evidenced: The deployed standard Ready/Argent account supports both Stark-curve and Secp256r1 authorizers. Users can add or replace typed owners on the same individual account while other accounts continue using Stark signatures. Boundary: The route is a supported native account configuration, not an experimental PQ account. Both named schemes are classical; guardian and application signing support must match the chosen account policy.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Ready/Argent typed owner coexistence and replacement

    Path: Use change_owners on the standard account to add a Secp256r1 owner and subsequently remove the old owner, with the required current signatures and owner-alive proof.

    Prerequisites

    • The named individual account implementation is deployed on Mainnet. — Available: Ready/Argent lists account v0.5.0 class 0x073414441639dcd11d1846f287650a00c60c416b9d3ba45d31c651672125b2c2 on Mainnet, with its source, ABI and deployment artifacts.
    • The present owner and any configured guardian authorize the account administration transaction. — Available: The standard account authenticates calls that administer the account. It provides methods to update owners and guardians, and a user-controlled upgrade method.
    • The replacement key and verifier are supported by the standard account and existing validation rules. — Available: The published native account supports Secp256r1 alongside Stark signatures, with a signature enum, verifier, signing client and test code. This evidence concerns that standard account, not a custom Falcon account.
    • Users can authorize adoption while retaining an operational successor. — Available: The owner manager supports adding and removing owners. Removing the signing owner when there are no guardians requires owner-alive verification.
    Confidence: High for supported standard-account coexistence and the authenticated adoption API; this is not a claim that all wallet interfaces expose every signer. Public source. Checked 2026-09-09. Changes to Mainnet account deployment, supported signer types, owner-change authorization or client support for the selected signer. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com
  • Ethereum — Current execution path blocked: The reviewed Ethereum ordinary native-account model does not provide a route to adopt a new signing scheme alongside the old one. The P256 Safe coexistence example concerns optional accounts. Boundary: Optional ERC-4337/Safe and delegated execution can coexist with EOAs without a new fork. Their real availability does not satisfy the approved standard/native-account gate. Protocol transport alternatives and validator withdrawal controls do not substitute for ordinary user authorization.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Coexistence of old and replacement native user signing schemes

    Path: The native EOA path remains secp256k1; the documented optional-wallet adoption path is outside this assessed scope.

    Prerequisites

    Confidence: High for the documented native EOA rule. The review does not cover every custom wallet. Public source. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not change the result. Source 1 · ethereum.org · Source 2 · raw.githubusercontent.com · Source 3 · eips.ethereum.org · Source 4 · ethereum.org
  • Bitcoin — Capability evidenced: Activated legacy ECDSA and Taproot Schnorr outputs coexist on mainnet. An ordinary wallet can spend an old output to a standard Taproot address while other legacy outputs remain spendable. Boundary: Coexistence is across native UTXOs; the historical Taproot activation is complete. This does not require one UTXO to accept both algorithms or establish a same-identity independent verifier upgrade.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native ECDSA/Schnorr UTXO coexistence after Taproot activation

    Path: Retain legacy outputs and fund/spend ordinary key-only Taproot outputs using released Core wallet support.

    Prerequisites

    • Taproot and legacy authorization are accepted by current mainnet rules. — Available: Core's maintained implementation list records mainnet activation and the subsequent always-active Taproot validation. Core 22 provides standard wallet support.
    • A released wallet can create and sign the selected ordinary key-only Taproot output. — Available: Core supports Taproot descriptors and signing. The tr(KEY) descriptor creates a Taproot output without a script tree. The owner must control an unspent source output and pay the fee.
    Confidence: Maintained activation records, protocol rules and released wallet support document the current adoption path. Public source. Checked 2026-09-09. Mainnet legacy/Taproot acceptance or standard wallet adoption support changes. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · bitcoincore.org
  • Solana — Current execution path blocked: Ordinary native transaction authorization remains Ed25519. Supported verification precompiles do not give standard native accounts an old/new signing adoption route, and optional smart wallets do not pass the execution gate. Boundary: This is not a claim that Solana applications cannot verify other schemes. It is a finding about the standard native user-authorizing surface, with no current native alternative established.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Native signer adoption of an alternative scheme

    Path: A user cannot select a different native transaction-signature scheme through the currently documented standard account mechanism.

    Prerequisites

    • A second native transaction-authorizing signature scheme is accepted by existing rules. — Blocked: Ordinary transaction signatures are fixed 64-byte Ed25519 values over the message. Verification by a precompile does not replace native signer authentication.
    Confidence: High for the native account distinction. Public source. Checked 2026-09-09. Current native coexistence of different authorization cryptography with a standard-user adoption route. Source 1 · solana.com · Source 2 · solana.com · Source 3 · solana.com
  • Algorand — Capability evidenced: Standard native Ed25519 and Falcon-1024 authorization coexist after the completed mainnet v42 activation. An existing account can adopt Falcon through authenticated rekeying while retaining its address and holdings. Boundary: This is the native f1 path, not a specially constructed LogicSig. Supported signing tools and higher fees are required; native multisig and consensus participation are separate and remain unchanged.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native Ed25519/Falcon coexistence with account rekeying

    Path: Generate a canonical native Falcon address, rekey the existing account with its old authority, then sign its transactions with released algokey pq tooling.

    Prerequisites

    • Native Falcon-1024 authorization is activated on mainnet. — Available: Algorand's official deployment page dates native Falcon-1024 mainnet support to August 2026, after v5.0.0 approval. The release enables the v42 f1 scheme.
    • A native Falcon signer and sufficient transaction fees are available. — Available: The released algokey pq tool generates or imports keys and signs transactions. The documented minimum fee for a basic Falcon transaction is 3,000 microAlgo. The end-to-end workflow creates an unsigned transaction, signs it with algokey and submits it through goal rawsend.
    • The current authorized key can submit a rekey preserving the selected live account. — Available: RekeyTo updates AuthAddr. Later validation uses the new authorizer while the account keeps its address and holdings. The owner must act before losing the old key and keep the account record live.
    Confidence: Qualified: current official deployment, release, native account and tooling documentation establish availability; wallet-wide compatibility was not tested. Qualified inference. Checked 2026-09-09. Native mainnet acceptance, standard signer support, rekey semantics or Falcon fees change. Source 1 · dev.algorand.co · Source 2 · algorand.co · Source 3 · dev.algorand.co · Source 4 · github.com · Source 5 · github.com
  • QRL — Capability evidenced: Standard native XMSS accounts with SHA2-256 and SHAKE256 hash configurations can coexist. An owner-authorized ordinary transfer supplies the route to a supported successor configuration. Boundary: This is native hash/parameter agility within XMSS, not coexistence of unrelated signature families or an in-place address change. No assumption that one supported hash is currently broken is needed.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Coexisting native XMSS hash configurations

    Path: Create a standard SHAKE256 XMSS successor and transfer from a controlled SHA2-256 XMSS address before its OTS capacity is exhausted.

    Prerequisites

    • The selected XMSS hash and height are supported by ordinary QRL tooling and native verification. — Available: Wallet documentation lists SHA2-256, SHAKE128, SHAKE256 and heights 8 through 18. The native descriptor selects the supported hash and height for the qrllib verifier, without a custom account.
    • The owner has an unused source OTS index, enough balance for the transfer and fee, and a controlled successor address. — Available: Ordinary signed transfers bind recipient and amount, check balance, nonce and OTS reuse, then debit/credit ledger state. Migration must happen before source OTS capacity or key access is lost.
    Confidence: Qualified: current standard-wallet documentation and native validation of descriptors and transfers establish the available path. No new mainnet transfer was performed in this audit. Qualified inference. Checked 2026-09-09. Removal of supported native XMSS hash options or evidence that the standard successor cannot receive/spend on classic mainnet. Source 1 · docs.theqrl.org · Source 2 · docs.theqrl.org · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com
  • Optimism — Current execution path blocked: The reviewed OP Mainnet ordinary native-account model does not supply an old-and-new signing-scheme adoption route. The cited coexistence example uses optional P256 Safe accounts. Boundary: Optional ERC-4337/Safe accounts and delegated execution can coexist with EOAs without a new fork. These available routes fall outside the assessed standard/native-account scope. Protocol transport alternatives and validator withdrawal controls do not substitute for ordinary user authorization.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Coexistence of old and replacement native user signing schemes

    Path: The native EOA path remains secp256k1; the documented optional-wallet adoption path is outside this assessed scope.

    Prerequisites

    Confidence: Qualified: OP's documented EVM equivalence supports the native-EOA inference; no independent op-reth execution was performed. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.optimism.io · Source 2 · eips.ethereum.org · Source 3 · ethereum.org
  • Robinhood Chain — Current execution path blocked: The reviewed Robinhood Chain ordinary native-account model does not supply an old-and-new signing-scheme adoption route. The cited coexistence example uses optional P256 Safe accounts. Boundary: Optional ERC-4337/Safe accounts and delegated execution can coexist with EOAs without a new fork. These available routes fall outside the assessed standard/native-account scope. Protocol transport alternatives and validator withdrawal controls do not substitute for ordinary user authorization.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Coexistence of old and replacement native user signing schemes

    Path: The native EOA path remains secp256k1; the documented optional-wallet adoption path is outside this assessed scope.

    Prerequisites

    Confidence: Qualified: current Robinhood mainnet documentation establishes the supported EVM account model and delegation, not an independent client-to-deployment audit. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.robinhood.com · Source 2 · docs.robinhood.com · Source 3 · docs.robinhood.com · Source 4 · eips.ethereum.org
  • Zcash — Capability evidenced: Transparent ECDSA and shielded authorization coexist under current mainnet rules. Standard wallets can spend a transparent output into an Ironwood note while other transparent funds remain usable. Boundary: This is coexistence across native authorization objects, not a claim that one note accepts both signing schemes. The earlier consensus activation is complete; the currently available adoption path is an ordinary shielding transaction.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native transparent-to-shielded adoption

    Path: Use the standard wallet Shield action to create an Ironwood successor while the network continues to accept transparent and shielded transactions.

    Prerequisites

    • The selected native pools and v6 format are active on mainnet. — Available: The mainnet announcement confirms NU6.3 at height 3,428,143 on 28 July 2026; Zebra 6.0.0 implements that activation and the Ironwood rules.
    • A standard wallet supports spending transparent funds into the native shielded pool. — Available: Zodl documents transparent exchange deposits and a Shield action to the wallet shielded address. NU6.3 directs newly shielded value into Ironwood; current wallet releases support it.
    Confidence: Documented: primary specifications, released implementation and stated deployment establish the named rule; no fresh transaction was executed. Public source. Checked 2026-09-23. Changes to native pool acceptance or standard wallet shielding support. Source 1 · zips.z.cash · Source 2 · github.com · Source 3 · support.zodl.com · Source 4 · zodl.com · Source 5 · z.cash
  • NEAR Protocol — Capability evidenced: An existing ordinary account can add an ML-DSA-65 full-access or function-call key while retaining its Ed25519/secp256k1 keys. Native AddKey and current CLI support provide a user adoption path under the already activated mainnet rules. Boundary: Coexistence is per native account. Keeping any classical authorization key does not complete that account’s PQ migration; wallet and application compatibility must be checked. Consensus signing is unchanged.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native multi-key coexistence through AddKey

    Path: Authorize AddKey with an existing full-access key, register ML-DSA-65 on the same account, and use the successor while classical keys remain until deliberately removed.

    Prerequisites

    • ML-DSA-65 native transaction and access-key support is active on mainnet. — Available: The 2.13.0 mainnet release stabilized the feature at protocol version 85; the official mainnet RPC reported protocol 86 and nearcore 2.13.4 on 2026-09-23.
    • The owner controls an existing full-access key, has the successor key and can fund fees and storage. — Available: Released NEAR CLI v0.30.1 generates ML-DSA-65 keys and supports ordinary AddKey and transaction signing. The native runtime charges fees and storage. The owner must preserve the generated key material.
    • Old and successor keys are accepted for the same account during migration. — Available: The released end-to-end test adds an ML-DSA-65 key using Ed25519, executes a PQ-signed transfer, and later uses the original key to remove the PQ key.
    Confidence: High for native coexistence and the released adoption route. Public source. Checked 2026-09-23. Reassess after changes to native algorithm coexistence, AddKey permissions or the supported user adoption path. Source 1 · docs.near.org · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com

Has the current cryptographic transition mechanism been tested for security and continued operation?

NIST basis: Sections 6.3, 6.5, and 7 address secure switching, continuing tests, and evaluating transition mechanisms. CSWP 39-upd1, section 6.3, printed p. 28 · CSWP 39-upd1, section 6.5, printed p. 31 · CSWP 39-upd1, section 7, printed p. 33

What counts as yes: A yes needs reviewable transition testing or a production transition that exercises the mechanism, including relevant interoperability or failure behavior. An unrelated audit or upgrade is insufficient.

Scope: The specific deployed standard native account or protocol transition mechanism and its representative user or protocol surface, including continuity and security behavior; not generic algorithm tests.

  • Starknet — Capability evidenced: The published sequencer tests cover successful invocation, finalized state-diff checks and ineligible or disabled cases for the current compiled-class-hash migration. Declaration tests reject the old hash version where the new rule applies. Boundary: This is testing of the live protocol hash-transition surface. Upstream source was read, not run here; it does not establish security review of every wallet signer or every network cryptographic migration.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Tested activated compiled-class-hash migration

    Path: Run an ordinary successful invocation of an eligible old class under current rules; the cited tests cover the resulting migration and rejection boundaries.

    Prerequisites

    • The compiled-class-hash migration rules are already activated. — Available: Official version notes identify Starknet v0.14.1 as live on Mainnet. Its migration applies to classes used by successful transactions that do not revert.
    • Reviewable tests exercise transition continuity and relevant failure behavior. — Available: test_compiled_class_hash_migration asserts successful execution and state-diff migration across hash versions/flags/Cairo versions; declaration cases reject Poseidon where V2 is required.
    Confidence: High for relevant transition-test coverage and published Mainnet activation; tests were not executed by this review. Public source. Checked 2026-09-09. Changes to hash-version acceptance, migration flags, eligible Cairo classes or the corresponding transition tests. Source 1 · docs.starknet.io · Source 2 · github.com · Source 3 · github.com
  • Ethereum — Capability evidenced: Tests of the deployed BLSToExecutionChange mechanism cover successful state conversion and withdrawal eligibility. They also check rejection of an incorrect old key or signature, already-converted credentials, and incorrect chain or fork signing domains. Current guides document how to submit the change. Boundary: This point concerns the current protocol's BLS withdrawal-credential-to-execution-address transition. It does not replace ordinary EOA signatures or validator consensus signing, and is not evidence of a network-wide post-quantum transition. Tests were inspected, not executed by this audit.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Tested native protocol conversion of BLS withdrawal credentials

    Path: An eligible 0x00 validator's withdrawal-key holder signs and submits BLSToExecutionChange through supported consensus-node tooling; the deployed processing function is the exact surface exercised by the cited tests.

    Prerequisites

    • Activated protocol support for an existing 0x00 withdrawal-credential conversion — Available: Ethereum's current withdrawal and credential guides document support for this conversion after Shapella. No new activation is required.
    • Control of the existing BLS withdrawal key, an intended execution address and a consensus-node submission path — Available: The standard ethdo workflow generates and broadcasts a signed change. It is available only to an owner who retains the old key and has an unconverted 0x00 credential.
    • Authenticated conversion preserving the existing validator record and its balance — Available: process_bls_to_execution_change checks index, old credential commitment, signature and chain domain, then replaces the withdrawal_credentials field in the existing validator record.
    • Reviewable security and continuity tests of the same deployed transition — Available: The Capella-and-later tests exercise success, withdrawal eligibility, wrong old public key, invalid signature, already-0x01 rejection and signing-domain errors; this is not an unrelated algorithm test.
    Confidence: High for mechanism-specific source tests and documented mainnet availability; no validator credential was changed and no production transaction was replayed in this audit. Public source. Checked 2026-09-09. Changes to credential-conversion processing, eligibility, supported tooling or test coverage. Testing of a different cryptographic transition requires its own evidence. Source 1 · raw.githubusercontent.com · Source 2 · raw.githubusercontent.com · Source 3 · ethereum.org · Source 4 · ethereum.org · Source 5 · github.com
  • Bitcoin — Capability evidenced: Core's Taproot functional suite tests the deployed validation mechanism, including signature failures, behavior before and after activation, and transactions combining legacy and Taproot spends. Separate release and activation records confirm deployment. Boundary: The review read the tests and deployment records without running Core. The result covers the native Taproot transition and its relevant interoperability and failure behavior. It does not establish exhaustive migration or security certification.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Core Taproot native-output transition test surface

    Path: Inspect the released feature_taproot.py suite's active/inactive and mixed legacy/Taproot spending cases against the separately documented mainnet implementation.

    Prerequisites

    • Taproot and legacy authorization are accepted by current mainnet rules. — Available: Core's maintained implementation list records mainnet activation and the subsequent always-active Taproot validation. Core 22 provides standard wallet support.
    • Tests exercise the actual transition rather than only a primitive. — Available: The suite builds active/inactive spenders, rejects mutated sighashes/signatures and includes legacy spends in mixed transactions.
    Confidence: Qualified: reviewable upstream tests are linked to a deployed standard protocol transition, but were not independently executed here. Qualified inference. Checked 2026-09-09. Changes to deployed Taproot validation or evidence that the cited tests no longer exercise its acceptance/rejection and mixed-input behavior. Source 1 · github.com · Source 2 · github.com · Source 3 · bitcoincore.org
  • Solana — Capability evidenced: Tests of the released Frankendancer TPU-QUIC replacement cover handshake compatibility between providers. Separate tests of the same production fd_quic/fd_tls component cover stream payloads, cipher-selection failures and ciphertext integrity. Together they support this limited protocol transition under the current execution gate. Boundary: The mixed-provider harness bypasses certificate and TLS-signature verification and closes after handshake. Payload and integrity coverage comes from separate same-component tests, not authenticated cross-provider traffic. Dedicated negative CertificateVerify/Finished tests were not established. This does not demonstrate uninterrupted validator operation, native-account migration or post-quantum transport.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Released TPU-QUIC implementation replacement: Agave Quinn/rustls to Frankendancer fd_quic/fd_tls

    Path: Build and run the supported Frankendancer mainnet release with the existing validator identity/vote configuration and compatible ledger in place of Agave networking. Compatible TPU clients negotiate the common TLS parameters; the Agave runtime and consensus interfaces remain in use without a new network-rule activation.

    Prerequisites

    • The tested implementation is the currently available protocol replacement. — Available: The mainnet-ready Frankendancer release and operator guide establish the replacement route, supported Linux/build environment, identity/vote configuration and compatible ledger. Its production QUIC tile instantiates fd_quic/fd_tls; the topology retains Agave runtime and consensus interfaces.
    • Reviewable interoperability tests exercise the replacement endpoint and its supported protocol negotiation. — Available: The contributed quinn-ring-fd harness connects a rustls-ring client to fd_quic using solana-tpu ALPN and checks retry/connection counters. It tests handshake compatibility only: its verifier accepts certificates and TLS signatures, and the connection closes before payload delivery. OpenSSL interoperability tests separately exercise the supported AES-128 suite and retry/client-certificate variants.
    • The same deployed component has relevant data-continuity and security-failure tests. — Available: fd_quic stream tests validate lengths and content of at least 10,000 received payload fragments, then service closure/acknowledgements. fd_tls tests reject AES-256-only offers and unoffered server selections; QUIC packet tests reject corrupted ciphertext and invalid bounds. Test registration links the production fd_quic/fd_tls modules. These separate tests do not establish authenticated mixed-provider payload delivery.
    Confidence: Medium: the released source links the tests to the deployed component, with explicit harness limits. Upstream tests were inspected, not run; an exact-release CI result and live cutover were not verified. Qualified inference. Checked 2026-09-22. Changes to production QUIC/TLS integration or its interoperability, stream and failure tests. Also review new tests on the exact release that resolve the current coverage gaps for authenticated payload delivery and transitions between providers. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · docs.firedancer.io · Source 7 · docs.firedancer.io · Source 8 · github.com · Source 9 · github.com · Source 10 · github.com · Source 11 · github.com · Source 12 · github.com · Source 13 · github.com · Source 14 · github.com · Source 15 · github.com · Source 16 · github.com · Source 17 · github.com · Source 18 · github.com
  • Algorand — Capability evidenced: Released native Falcon tests exercise Ed25519 funding, Falcon spending, insufficient-fee rejection and balance continuity; verifier tests add authorizer mismatch, encoding and malformed-proof checks. Separate mainnet deployment evidence links these tests to an activated mechanism. Boundary: The audit read but did not run the tests. Some verifier fixtures use ConsensusFuture; released v42 enables the same f1 validation branch. The E2E script does not itself execute a full rekey/close-out lifecycle.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native Falcon account transition and verification tests

    Path: Assess the release's funding/spending E2E script and verifier rejection tests against activated v42 f1 support.

    Prerequisites

    • Native Falcon-1024 authorization is activated on mainnet. — Available: Algorand's official deployment page dates native Falcon-1024 mainnet support to August 2026, after v5.0.0 approval. The release enables the v42 f1 scheme.
    • A native Falcon signer and sufficient transaction fees are available. — Available: The released algokey pq tool generates or imports keys and signs transactions. The documented minimum fee for a basic Falcon transaction is 3,000 microAlgo. The end-to-end workflow creates an unsigned transaction, signs it with algokey and submits it through goal rawsend.
    • Reviewable tests exercise the deployed account mechanism and relevant failure behavior. — Available: pq-falcon.sh funds with the old account, accepts a Falcon spend, rejects an underpriced spend and asserts final balance. txn_test.go checks matching/mismatching AuthAddr and malformed proofs; v42 activates that branch.
    Confidence: Qualified. The review inspected transition and interoperability tests and separate deployment evidence. It did not execute the tests or perform a complete security audit. Qualified inference. Checked 2026-09-09. Changes to active f1 verification, fee logic, standard signer workflow or tests establishing continuity/failure behavior. Source 1 · algorand.co · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com
  • QRL — Capability evidenced: Public cross-hash wallet scenarios fund native SHAKE256 and SHA2-256 XMSS addresses and spend from those successors. These scenarios use the direct-transfer signing and node-validation path retained in the current released implementation, whose tests also cover invalid signatures, reused OTS indexes and balance/state continuity. Boundary: The conclusion combines legacy cross-configuration functional scenarios with current same-mechanism validation tests. The old webstack workflow is disabled, and no successful run against the exact release was verified. Upstream tests were inspected, not run. The mapping covers ordinary direct transfers without a message, not every current wallet feature or a future signing algorithm.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Standard native balance transfer between supported XMSS hash configurations

    Path: Use an unused source OTS index to sign a direct native transfer into a controlled successor with a supported XMSS hash configuration, then spend from that successor. Legacy cross-hash scenarios use the same empty-message transfer payload and native validation path retained in released wallet and node source.

    Prerequisites

    Confidence: Medium: source-based applicability is established for the named transfer path; current execution of the legacy end-to-end suite remains unverified. Qualified inference. Checked 2026-09-23. Changes to native transfer serialization, XMSS descriptor handling, wallet signing or node validation; current cross-configuration test results or failure tests that strengthen or contradict the source mapping. Source 1 · docs.theqrl.org · Source 2 · docs.theqrl.org · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com · Source 7 · github.com · Source 8 · github.com · Source 9 · github.com · Source 10 · github.com · Source 11 · github.com · Source 12 · github.com · Source 13 · github.com · Source 14 · github.com · Source 15 · github.com · Source 16 · github.com · Source 17 · github.com · Source 18 · github.com · Source 19 · github.com · Source 20 · github.com · Source 21 · github.com · Source 22 · github.com · Source 23 · github.com
  • Optimism — Capability evidenced: The released OP node uses a pinned libp2p version for its selectable Noise/TLS transports. Tests for that version assert negotiated transport selection, mixed-peer compatibility and rejection without common support. Linked TLS tests cover authenticated identities, invalid credentials and payload transfer. Boundary: This supports a tested P2P transport transition, not native account-signature replacement or a demonstrated OP Mainnet rolling migration. Compatible peer configurations and reconnection remain necessary. The negotiation matrix uses Ed25519 identities; TLS tests separately include secp256k1. No post-quantum protection is established.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: OP node P2P transport replacement between Noise and TLS

    Path: In released op-node v1.19.7, operators configure p2p.security to retain common transport support during transition and then restrict the list for new connections. The loader installs the selected libp2p constructors; reconnecting or restarting applies the configuration without a new rollup consensus upgrade.

    Prerequisites

    • A released OP node with an integrated transport replacement boundary — Available: op-node v1.19.7 exposes the ordered noise/tls configuration, installs the selected constructors and pins go-libp2p v0.47.0. The replacement concerns secure peer transport; native authorization and Ethereum settlement remain separate.
    • Operator configuration access and peers with overlapping transport support — Available: Current configuration permits an overlap phase followed by a restricted transport list. The linked negotiation tests establish compatibility with overlapping support and rejection without overlap. This is an available cooperating-peer route, not a claim that every public peer enables the target transport.
    • Security, interoperability and continued-operation tests linked to the selected implementation — Available: The exact dependency asserts the negotiated Noise/TLS protocol and incompatible-peer failure. Its TLS suite checks identities and public keys, payload delivery, cancellation, peer-ID mismatch and invalid certificate/signature rejection. These are tests of the linked component. An OP Mainnet rolling cutover was not reproduced.
    Confidence: Medium: the released node, its exact dependency integration and the test source were reviewed. Upstream tests and a live OP Mainnet transport transition were not executed in this review. Qualified inference. Checked 2026-09-22. Changes to the OP transport selector, linked libp2p release or security tests; a documented OP-specific rolling transition or evidence that a required transport is no longer supported. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com · Source 7 · github.com
  • Robinhood Chain — Not established by reviewed evidence: The mainnet feed has confirmed TLS and cipher interoperability, and Nitro has feed recovery and invalid-signature tests. The reviewed tests do not exercise the deployed feed's cryptographic transport transition with relevant failure and continuity behavior. Coordinator mixed-mode tests remain unlinked to a confirmed Robinhood Chain coordinator deployment. Boundary: Receiving feed data through two valid secure channels establishes availability, not a transition-security test suite or production cutover. Nitro's inspected feed tests use local plaintext WebSockets; generic TLS tests do not alone cover the deployed feed transition. No conclusion about brokerage or wallet infrastructure is used.

    Path availability

    Status: Not established. Scope: Protocol component. New network upgrade required: Not established.

    Mechanism: Tested cryptographic transition of Robinhood Chain's deployed feed transport or coordinator authentication

    Path: The public mainnet feed is a confirmed TLS component with live alternate-cipher delivery. Released Nitro tests cover feed reception, identity/version errors, invalid signatures and reconnection using plaintext local WebSockets; they do not establish security and continuity during a TLS replacement transition. Separate coordinator mode tests remain relevant but their chain deployment is unverified.

    Prerequisites

    • A confirmed deployed protocol component with an available cryptographic replacement boundary — Available: Official mainnet instructions identify the feed and prescribed client. TLS 1.2/AES-GCM and TLS 1.3/ChaCha20 live probes each returned the same complete feed sequence over a validated certificate.
    • Reviewable security and continuity coverage of that specific cryptographic transition — Not established: The inspected broadcast-client tests instantiate ws://127.0.0.1, covering feed delivery, wrong-chain/version handling, invalid-signature skipping and reconnection. They are not TLS transition tests. The read-only alternate-cipher probe did not exercise a controlled cutover or relevant failure behavior.
    • Confirmed chain deployment if relying on the alternative coordinator tests — Not established: SignVerify mixed-mode tests and coordinator synchronization/rejection tests remain relevant. The coordinator defaults to disabled, and the reviewed Robinhood Chain guide does not establish its internal deployment or configuration.
    Confidence: Qualified evidence gap: current chain instructions, prescribed Nitro source and feed test source were reviewed. Read-only TLS and feed probes were performed. Upstream tests, a full Nitro node, a controlled transport cutover and security-failure transition tests were not executed. No public assessment. Checked 2026-09-23. Reviewable tests or a documented production transition tying Robinhood Chain's deployed feed TLS boundary to relevant failure and continued-operation behavior; alternatively chain deployment evidence for the already-tested coordinator mechanism. Source 1 · docs.robinhood.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com · Source 7 · github.com · Source 8 · github.com · Source 9 · github.com · Source 10 · github.com · Source 11 · github.com · Source 12 · github.com · Source 13 · github.com · Source 14 · github.com · Source 15 · github.com
  • Zcash — Capability evidenced: The live Orchard-to-Ironwood migration has released wallet support and reviewable transition-rule tests. The tests cover old-pool inflow rejection, old-format enforcement, valid remaining spends and duplicate Ironwood nullifier rejection. Boundary: The evidence concerns the deployed pool and note-format transition. Test source and production release evidence were reviewed; upstream tests were not run here. Formal verification separately covers balance integrity, not every privacy property or future quantum recovery.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Tested NU6.3 pool transition and wallet migration

    Path: Migrate existing Orchard funds with released Zodl tooling under active NU6.3 rules. The pinned Zebra tests cover transition rules and failure cases for that same surface.

    Prerequisites

    • The selected native pools and v6 format are active on mainnet. — Available: The mainnet announcement confirms NU6.3 at height 3,428,143 on 28 July 2026; Zebra 6.0.0 implements that activation and the Ironwood rules.
    • The owner controls the source funds and uses released wallet support, with funds available for the transaction fee. — Available: Zodl 3.8.0 supports Ironwood; released Android 3.9.0 includes migration. The support guide documents manual and assisted sends and confirmations. This review did not execute a transaction.
    • Testing must exercise the migration boundary and relevant failure behavior. — Available: Zebra tests enforce the Orchard value-balance boundary before and after activation, restriction of old-version coinbase use, valid outflows, required Ironwood flags and rejection of duplicate Ironwood nullifiers.
    Confidence: Qualified: source-backed interpretation of the named surface; no independent node, wallet or cryptographic testing was executed. Qualified inference. Checked 2026-09-23. Changes to NU6.3 validation, the released wallet migration mechanism, or disclosed migration/security failures. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · support.zodl.com · Source 5 · tachyon.z.cash
  • NEAR Protocol — Capability evidenced: Release-pinned end-to-end tests add an ML-DSA-65 key with Ed25519 authority, execute a PQ-signed transfer and check the recipient balance. They then remove the added key and verify it is absent. A second test accepts an allowed PQ-signed function call and rejects a disallowed method. Boundary: The test source covers native key adoption, coexistence, removal and permission enforcement. The shown full-access test deletes the PQ key, not every classical key; it does not demonstrate a complete wallet recovery migration or network-wide PQ security. Upstream tests were not run in this review.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Tested native access-key transition and authorization checks

    Path: Use the deployed AddKey/DeleteKey and native verification path exercised by the release’s full-access and function-call end-to-end tests.

    Prerequisites

    • ML-DSA-65 native transaction and access-key support is active on mainnet. — Available: The 2.13.0 mainnet release stabilized the feature at protocol version 85; the official mainnet RPC reported protocol 86 and nearcore 2.13.4 on 2026-09-23.
    • The owner controls an existing full-access key, has the successor key and can fund fees and storage. — Available: Released NEAR CLI v0.30.1 generates ML-DSA-65 keys and supports ordinary AddKey and transaction signing. The native runtime charges fees and storage. The owner must preserve the generated key material.
    • Reviewable tests exercise continuity and relevant failure behavior on the actual native transition path. — Available: The full-access test executes a transfer after adding the successor and verifies key deletion. The restricted-key test rejects MethodNameMismatch; gas tests compare otherwise equivalent classical/PQ transfers.
    Confidence: High for the specified test coverage linked to the deployed release. Public source. Checked 2026-09-23. Reassess after changes to the deployed key-transition mechanism or its end-to-end continuity and failure test coverage. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com

Does the transition mechanism prevent an attacker from forcing a weaker algorithm?

NIST basis: Sections 3.2.3 and 6.3 discuss integrity of algorithm selection and secure switching in configurations. CSWP 39-upd1, section 3.2.3, printed p. 11 · CSWP 39-upd1, section 6.3, printed p. 28

What counts as yes: A yes needs authenticated selection bound to the intended authorization or component and evidence that weaker fallback cannot be attacker-forced. Absence of negotiation alone is insufficient.

Scope: A migrated standard native user-authorizing account or output on the declared authorization transition surface, including all configured authorization routes for that selected object; this does not require a whole-network ban or every wallet to be migrated.

  • Starknet — Capability evidenced: A standard Ready/Argent v0.5.0 account with one Secp256r1 owner and no guardians authenticates owner changes and checks signatures against the stored typed owner. Removing every old owner and guardian invalidates their session authorization and clears escape routes. Old Stark signatures cannot select an old verifier. Boundary: The assessed configuration must be fully initialized and have no retained old owners, guardians or authorized sessions. Legacy-recovery entry conditions require an empty owner list and therefore do not apply. Outside execution and class upgrades require the current policy. A current owner can deliberately authorize a later change; that is not an attacker-forced fallback.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Typed standard-account authorizer replacement with complete old-route removal

    Path: On initialized Ready/Argent v0.5.0, authorize replacement of all old owners by one Secp256r1 owner and removal of all guardians; confirm no remaining old authorization routes.

    Prerequisites

    • The named individual account implementation is deployed on Mainnet. — Available: Ready/Argent lists account v0.5.0 class 0x073414441639dcd11d1846f287650a00c60c416b9d3ba45d31c651672125b2c2 on Mainnet, with its source, ABI and deployment artifacts.
    • The present owner and any configured guardian authorize the account administration transaction. — Available: The standard account authenticates calls that administer the account. It provides methods to update owners and guardians, and a user-controlled upgrade method.
    • The replacement key and verifier are supported by the standard account and existing validation rules. — Available: The published native account supports Secp256r1 alongside Stark signatures, with a signature enum, verifier, signing client and test code. This evidence concerns that standard account, not a custom Falcon account.
    • The selected standard configuration has no remaining old-scheme owner, guardian, session, recovery or upgrade authorization route. — Available: Configure one Secp256r1 owner, remove all old owners and guardians, and finish ordinary account migration. Owner/guardian updates clear escapes; cached sessions require current owner/guardian membership, while uncached sessions revalidate those authorities. Legacy recovery requires an empty owner list and is unavailable on this initialized account. Administrative upgrades and outside execution use the current authorization policy.
    Confidence: High for the reviewed standard configuration and route checks; no individual user's configuration or source-to-bytecode rebuild was audited. Public source. Checked 2026-09-09. Any change to owner/guardian sets, sessions, escapes, legacy recovery, outside execution, upgrade authorization or the deployed account implementation. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com · Source 7 · github.com · Source 8 · github.com
  • Ethereum — Current execution path blocked: No migrated ordinary Ethereum EOA with an enforceable replacement signing policy was established. EIP-7702 delegation retains the original EOA key's authority to change delegation. A delegated policy alone therefore does not retire that authorization route. Boundary: The assessment does not establish that an attacker can defeat every contract wallet. A selected passkey-only Safe's owner and module configuration is evidence about an optional account and earns no point for ordinary native accounts. No relative strength ranking of secp256k1 and P256 is assumed.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Downgrade exclusion on a migrated ordinary EOA

    Path: A delegate may check a new signature, but the protocol-authorized EOA key remains an independent authority; no native migrated-object lock is established.

    Prerequisites

    Confidence: High for the documented native EOA rule. The review does not cover every custom wallet. Public source. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not change the result. Source 1 · ethereum.org · Source 2 · raw.githubusercontent.com · Source 3 · eips.ethereum.org · Source 4 · ethereum.org
  • Bitcoin — Capability evidenced: A standard key-only tr(KEY) successor commits to its Taproot output key with no script tree. Current validation requires a BIP-340 Schnorr signature for that output; an attacker cannot substitute a legacy ECDSA authorization route. Boundary: The selected object is the ordinary key-only Taproot output. This does not apply automatically to arbitrary script trees, legacy outputs elsewhere, or quantum attacks against secp256k1 itself.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Standard key-only Taproot output commitment

    Path: The owner authorizes creation of tr(KEY) with no script tree; subsequent spend verification is bound to its Schnorr output key.

    Prerequisites

    • Taproot and legacy authorization are accepted by current mainnet rules. — Available: Core's maintained implementation list records mainnet activation and the subsequent always-active Taproot validation. Core 22 provides standard wallet support.
    • A released wallet can create and sign the selected ordinary key-only Taproot output. — Available: Core supports Taproot descriptors and signing. The tr(KEY) descriptor creates a Taproot output without a script tree. The owner must control an unspent source output and pay the fee.
    • The selected successor contains no weaker alternate spending branch. — Available: BIP-386 defines tr(KEY) without a script tree; BIP-341 requires either the committed key's valid Schnorr signature or a valid proof of an actually committed script path.
    Confidence: Qualified: an inference from the standard no-script descriptor and deployed validation rules; no new adversarial execution was performed. Qualified inference. Checked 2026-09-09. Changes to tr(KEY) construction, Taproot validation or additional authorization routes for the assessed successor. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · bitcoincore.org
  • Solana — Current execution path blocked: The reviewed evidence did not establish a current standard-account transition between signing schemes. Without that transition, it cannot demonstrate authenticated selection of a replacement scheme or removal of attacker-forced fallback to the old scheme. Boundary: Ed25519-only native authorization and the absence of negotiation are not a downgrade-lock demonstration for a migration. Optional wallet policy tests cannot substitute for the standard native surface.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Standard-account migration with successor authorization

    Path: The ordinary native account first needs an accepted alternative signing route before its migration downgrade behavior can satisfy this question.

    Prerequisites

    • A second native transaction-authorizing signature scheme is accepted by existing rules. — Blocked: Ordinary transaction signatures are fixed 64-byte Ed25519 values over the message. Verification by a precompile does not replace native signer authentication.
    Confidence: High for withholding a migration property without a qualifying native transition. Public source. Checked 2026-09-09. A qualifying standard-account migration, with evidence that successor selection is authenticated and every authorization route is covered. Source 1 · solana.com · Source 2 · solana.com · Source 3 · solana.com
  • Algorand — Capability evidenced: Authenticated rekeying binds a live standard account to a canonical off-curve native Falcon authorizer. With no successor delegation, the old Ed25519 key cannot authorize spending by selecting a legacy signature category. Boundary: The result requires the named off-curve authorizer and no old configured delegate. Salt safety is a tooling/REST safeguard, not a universal consensus rule; closing and later recreating the old address restores its original authority.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native AuthAddr enforcement for a live Falcon-rekeyed account

    Path: Use canonical algokey PQ key generation, authenticate rekey to the new authorizer, and use only its native signing route while the account stays live.

    Prerequisites

    • Native Falcon-1024 authorization is activated on mainnet. — Available: Algorand's official deployment page dates native Falcon-1024 mainnet support to August 2026, after v5.0.0 approval. The release enables the v42 f1 scheme.
    • A native Falcon signer and sufficient transaction fees are available. — Available: The released algokey pq tool generates or imports keys and signs transactions. The documented minimum fee for a basic Falcon transaction is 3,000 microAlgo. The end-to-end workflow creates an unsigned transaction, signs it with algokey and submits it through goal rawsend.
    • The current authorized key can submit a rekey preserving the selected live account. — Available: RekeyTo updates AuthAddr. Later validation uses the new authorizer while the account keeps its address and holdings. The owner must act before losing the old key and keep the account record live.
    • The successor is a canonical off-curve native Falcon address with no old delegated authorization. — Available: algokey uses the canonical off-curve salt. Native validation checks the assigned authorizer, and old delegations do not match the new AuthAddr. The selected Falcon authorizer has no delegation. The off-curve check is a safeguard in key generation and the REST interface, not a consensus-wide ban on unsafe salts.
    Confidence: Qualified. Native rekey and authorizer rules, standard key-generation behavior and rejection tests support this result within the assessed scope. Qualified inference. Checked 2026-09-09. Changes to canonical address generation, AuthAddr validation, delegated routes or close-out behavior. Source 1 · dev.algorand.co · Source 2 · dev.algorand.co · Source 3 · algorand.co · Source 4 · github.com
  • QRL — Capability evidenced: A normal successor XMSS address commits to its public key and the descriptor encoding its chosen hash and height. With no slave authorizations, a transaction using an old different-hash key fails address/authorization matching rather than selecting a fallback algorithm. Boundary: The selected standard successor is created with a supported replacement hash and no delegates. This does not retire the outer SHA256 address commitment, imply a supported hash is presently broken, or change the old address in place.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native XMSS descriptor-bound successor without old slaves

    Path: Generate a normal successor using the replacement hash, receive the owner-authorized transfer, and authorize subsequent spending only with its native key.

    Prerequisites

    • The selected XMSS hash and height are supported by ordinary QRL tooling and native verification. — Available: Wallet documentation lists SHA2-256, SHAKE128, SHAKE256 and heights 8 through 18. The native descriptor selects the supported hash and height for the qrllib verifier, without a custom account.
    • The owner has an unused source OTS index, enough balance for the transfer and fee, and a controlled successor address. — Available: Ordinary signed transfers bind recipient and amount, check balance, nonce and OTS reuse, then debit/credit ledger state. Migration must happen before source OTS capacity or key access is lost.
    • The selected native successor has no old slave-key authorizations. — Available: A newly created ordinary XMSS successor has no inherited slave state; Transaction.validate_slave rejects a public key that neither derives its master address nor has an allowed registered slave entry.
    Confidence: Qualified: native descriptor binding and slave checks support authenticated parameter selection; no fresh adversarial test was run. Qualified inference. Checked 2026-09-09. Changes to descriptor binding, native signature verification or any slave route configured for the selected successor. Source 1 · docs.theqrl.org · Source 2 · github.com · Source 3 · github.com
  • Optimism — Current execution path blocked: No migrated ordinary OP Mainnet EOA with an enforceable replacement signing policy is established. EIP-7702 code delegation retains the original EOA key's ability to authorize delegation changes, so a delegated policy alone does not establish retirement of that route. Boundary: A passkey-only Safe's owner and module configuration is evidence about an optional account, not ordinary native accounts. This finding does not mean an attacker can defeat every contract wallet, and it assumes no stronger-versus-weaker ordering of secp256k1 and P256.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Downgrade exclusion on a migrated ordinary EOA

    Path: A delegate may check a new signature, but the protocol-authorized EOA key remains an independent authority; no enforceable replacement signing policy is established for the migrated native account.

    Prerequisites

    Confidence: Qualified: OP's documented EVM equivalence supports the native-EOA inference; no independent op-reth execution was performed. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.optimism.io · Source 2 · eips.ethereum.org · Source 3 · ethereum.org
  • Robinhood Chain — Current execution path blocked: No migrated ordinary Robinhood Chain EOA with an enforceable replacement signing policy is established. EIP-7702 code delegation retains the original EOA key's ability to authorize delegation changes, so a delegated policy alone does not establish retirement of that route. Boundary: A passkey-only Safe's owner and module configuration is evidence about an optional account, not ordinary native accounts. This finding does not mean an attacker can defeat every contract wallet, and it assumes no stronger-versus-weaker ordering of secp256k1 and P256.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Downgrade exclusion on a migrated ordinary EOA

    Path: A delegate may check a new signature, but the protocol-authorized EOA key remains an independent authority; no enforceable replacement signing policy is established for the migrated native account.

    Prerequisites

    Confidence: Qualified: current Robinhood mainnet documentation establishes the supported EVM account model and delegation, not an independent client-to-deployment audit. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.robinhood.com · Source 2 · docs.robinhood.com · Source 3 · docs.robinhood.com · Source 4 · eips.ethereum.org
  • Zcash — Capability evidenced: When a standard transparent output is spent into an Ironwood note, the authorized transaction commits to the shielded destination and the successor must satisfy its native proof and RedPallas authorization. An attacker cannot substitute the spent output's ECDSA route to authorize that note. Boundary: The scope is one completed SIGHASH_ALL shielding transaction and its resulting Ironwood note under the stated classical cryptographic assumptions. It does not claim resistance after those assumptions break, or prevent a legitimate owner from making a later authorized unshielding transfer.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Authenticated shielding into a native Ironwood successor

    Path: Confirm an ordinary SIGHASH_ALL shielding spend; validate later spending under the Ironwood bundle rules and note/nullifier state, with no transparent fallback for that note.

    Prerequisites

    Confidence: Qualified: source-backed interpretation of the named surface; no independent node, wallet or cryptographic testing was executed. Qualified inference. Checked 2026-09-23. Changes to signature-digest binding, shielded proof/spend validation or a newly configured fallback path for the selected successor. Source 1 · zips.z.cash · Source 2 · zips.z.cash · Source 3 · github.com · Source 4 · github.com · Source 5 · support.zodl.com · Source 6 · github.com
  • NEAR Protocol — Capability evidenced: For a migrated key-only account, the signed transaction binds its account, public key and actions. Signature verification accepts only a matching scheme and key, and authorization requires that exact key in the account's current key set. After every classical key is removed, an attacker cannot select a classical fallback for a newly authorized transaction. Boundary: The selected ordinary named account has no local or global contract or other recovery path, retains usable ML-DSA-65 full access, and has removed every classical full-access and function-call key. The claim applies after migration actions settle; it does not revoke previously authorized in-flight work or protect consensus, other accounts or history.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Authenticated typed signing plus removal of all classical access keys

    Path: Add and verify ML-DSA-65 full access, finalize deletion of every classical account key, and require the retained PQ key for subsequent native transactions on the settled key-only account.

    Prerequisites

    Confidence: High for the combination of native binding and key-removal enforcement within the declared account scope. Qualified inference. Checked 2026-09-23. Reassess after changes to typed signature binding, access-key lookup, deletion semantics or alternative account recovery routes. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com · Source 7 · github.com · Source 8 · docs.near.org

Can new use of an old algorithm be disabled after migration?

NIST basis: Sections 3.2 and 5.2 discuss prohibiting deprecated algorithms and enforcing the resulting policy. CSWP 39-upd1, section 3.2, printed p. 10 · CSWP 39-upd1, section 5.2, printed p. 24

What counts as yes: A yes needs an identified authority or process and an enforceable mechanism that disables new old-algorithm use after migration. A hypothetical hard fork or broad future coordination alone is insufficient.

Scope: A migrated standard native user-authorizing account or output on the declared authorization transition surface, including all configured authorization routes for that selected object; this does not require a whole-network ban or every wallet to be migrated.

  • Starknet — Capability evidenced: The account's current owner/guardian authority can remove all old typed owners and guardians from the standard Ready/Argent account. In the selected configuration, with one Secp256r1 owner and no guardians, future transactions must satisfy the new authorization policy. Old-scheme signatures can no longer authorize new use of that account. Boundary: The finding is per initialized standard account. All old session and recovery paths must be disabled by the completed configuration; the legacy-recovery method cannot reset a nonempty owner list. It is not a network ban, a PQ claim or retirement of Starknet's other primitives.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native owner/guardian removal enforces scoped retirement

    Path: Use the supported change_owners/change_guardians operations to complete migration to one Secp256r1 owner and no guardians; old routes cannot authorize later transactions.

    Prerequisites

    • The named individual account implementation is deployed on Mainnet. — Available: Ready/Argent lists account v0.5.0 class 0x073414441639dcd11d1846f287650a00c60c416b9d3ba45d31c651672125b2c2 on Mainnet, with its source, ABI and deployment artifacts.
    • The present owner and any configured guardian authorize the account administration transaction. — Available: The standard account authenticates calls that administer the account. It provides methods to update owners and guardians, and a user-controlled upgrade method.
    • The replacement key and verifier are supported by the standard account and existing validation rules. — Available: The published native account supports Secp256r1 alongside Stark signatures, with a signature enum, verifier, signing client and test code. This evidence concerns that standard account, not a custom Falcon account.
    • The selected standard configuration has no remaining old-scheme owner, guardian, session, recovery or upgrade authorization route. — Available: Configure one Secp256r1 owner, remove all old owners and guardians, and finish ordinary account migration. Owner/guardian updates clear escapes; cached sessions require current owner/guardian membership, while uncached sessions revalidate those authorities. Legacy recovery requires an empty owner list and is unavailable on this initialized account. Administrative upgrades and outside execution use the current authorization policy.
    Confidence: High for the enforceable standard-account configuration; wallet-wide and network-wide retirement are not assessed. Public source. Checked 2026-09-09. Changes to account administration, alternative authorization paths, owner/guardian configuration or the named deployed implementation. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com
  • Ethereum — Current execution path blocked: The reviewed Ethereum ordinary EOA has no account-level mechanism that disables new use of its old native signature algorithm after migration. Removing Safe owners or modules applies to the optional Safe scope. Boundary: This finding is limited to the selected native account. It does not imply that ERC-4337 wallets need a fork, that all smart wallets retain old authorization routes, or that the criterion requires a network-wide algorithm ban.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Retirement of old native EOA authorization

    Path: No existing native account operation revokes the old EOA verifier; delegation replacement remains available through the original native signing route.

    Prerequisites

    Confidence: High for the documented native EOA rule. The review does not cover every custom wallet. Public source. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not change the result. Source 1 · ethereum.org · Source 2 · raw.githubusercontent.com · Source 3 · eips.ethereum.org · Source 4 · ethereum.org
  • Bitcoin — Capability evidenced: The owner can spend a legacy output into a standard key-only Taproot successor. Consensus consumes the old UTXO and the successor accepts Schnorr authorization without an ECDSA fallback. Boundary: This is enforced for the migrated value/output only. It does not prohibit creating new legacy outputs elsewhere, prevent an authorized later migration back, or claim ECDSA retirement across Bitcoin.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Owner-authorized replacement of a legacy UTXO with key-only Taproot

    Path: Create and confirm a valid legacy spend whose migrated value is assigned to tr(KEY); current UTXO rules prevent respending the consumed source.

    Prerequisites

    Confidence: Qualified: ordinary transfer and standard no-script Taproot enforcement support the scoped retirement result. Qualified inference. Checked 2026-09-09. Changes to source-output consumption or the standard successor's permitted authorization routes. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · bitcoincore.org
  • Solana — Current execution path blocked: The reviewed standard native account cannot migrate to a different signature scheme and disable Ed25519 use for that same native authorization surface under current rules. Boundary: Changing a key, emptying an account or placing assets under an optional program is not retirement of the old algorithm on a migrated standard account. No whole-network ban is required by this question.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Native old-algorithm retirement after migration

    Path: Current native signing rules must first support a successor authorization mechanism; existing account operations do not retire Ed25519 for a migrated standard account.

    Prerequisites

    • A second native transaction-authorizing signature scheme is accepted by existing rules. — Blocked: Ordinary transaction signatures are fixed 64-byte Ed25519 values over the message. Verification by a precompile does not replace native signer authentication.
    Confidence: High for the selected native authorization boundary. Public source. Checked 2026-09-09. An enforceable current native migration policy that disables old-algorithm authorization for the selected migrated object. Source 1 · solana.com · Source 2 · solana.com
  • Algorand — Capability evidenced: The current holder can submit a native rekey that replaces the selected live account's old Ed25519 authority with an off-curve Falcon authorizer. Consensus thereafter requires the new authority, disabling old-key use for that account. Boundary: The scope excludes close-out/address recreation and assumes the successor has no legacy delegation. It does not ban Ed25519 elsewhere, disable future owner-authorized rekeying, or retire consensus cryptography.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Owner-authorized native retirement through RekeyTo

    Path: The old authorized key signs RekeyTo naming the canonical native Falcon authorizer; keep the migrated ledger account live and configure no old delegate.

    Prerequisites

    • Native Falcon-1024 authorization is activated on mainnet. — Available: Algorand's official deployment page dates native Falcon-1024 mainnet support to August 2026, after v5.0.0 approval. The release enables the v42 f1 scheme.
    • A native Falcon signer and sufficient transaction fees are available. — Available: The released algokey pq tool generates or imports keys and signs transactions. The documented minimum fee for a basic Falcon transaction is 3,000 microAlgo. The end-to-end workflow creates an unsigned transaction, signs it with algokey and submits it through goal rawsend.
    • The current authorized key can submit a rekey preserving the selected live account. — Available: RekeyTo updates AuthAddr. Later validation uses the new authorizer while the account keeps its address and holdings. The owner must act before losing the old key and keep the account record live.
    • The successor is a canonical off-curve native Falcon address with no old delegated authorization. — Available: algokey uses the canonical off-curve salt. Native validation checks the assigned authorizer, and old delegations do not match the new AuthAddr. The selected Falcon authorizer has no delegation. The off-curve check is a safeguard in key generation and the REST interface, not a consensus-wide ban on unsafe salts.
    Confidence: Qualified. Native account authority replacement is documented and deployed. This does not establish permanent address retirement or cover every delegated configuration. Qualified inference. Checked 2026-09-09. Changes to rekey authority, native Falcon deployment, authorized routes or close-out/reset semantics. Source 1 · dev.algorand.co · Source 2 · dev.algorand.co · Source 3 · algorand.co · Source 4 · github.com
  • QRL — Capability evidenced: The owner can transfer existing value to a normal XMSS successor with the selected replacement hash and no old slave routes. Native address/verifier checks exclude the former signing configuration from authorizing that successor. Boundary: The retirement applies to the migrated successor's value. The old address still exists and can receive new funds; there is no network-wide hash prohibition or in-place scheme change.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Owner-authorized transfer to a native XMSS successor with a replacement hash

    Path: Before old OTS exhaustion, sign a transfer of the selected balance to a fresh standard replacement-hash address with no old slave authorizations.

    Prerequisites

    • The selected XMSS hash and height are supported by ordinary QRL tooling and native verification. — Available: Wallet documentation lists SHA2-256, SHAKE128, SHAKE256 and heights 8 through 18. The native descriptor selects the supported hash and height for the qrllib verifier, without a custom account.
    • The owner has an unused source OTS index, enough balance for the transfer and fee, and a controlled successor address. — Available: Ordinary signed transfers bind recipient and amount, check balance, nonce and OTS reuse, then debit/credit ledger state. Migration must happen before source OTS capacity or key access is lost.
    • The selected native successor has no old slave-key authorizations. — Available: A newly created ordinary XMSS successor has no inherited slave state; Transaction.validate_slave rejects a public key that neither derives its master address nor has an allowed registered slave entry.
    Confidence: Qualified: native transfer and successor authorization enforcement establish the scoped retirement path. Qualified inference. Checked 2026-09-09. Changes to standard transfer availability, OTS requirements or successor authorization/slave rules. Source 1 · docs.theqrl.org · Source 2 · docs.theqrl.org · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com
  • Optimism — Current execution path blocked: The reviewed OP Mainnet ordinary EOA has no account-level mechanism that disables new use of its old native signature algorithm after migration. Removing Safe owners or modules applies to the optional Safe scope. Boundary: This finding concerns the assessed native account surface. It does not imply that ERC-4337 wallets need a fork, that all smart wallets retain old routes, or that a whole-network algorithm ban is required.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Retirement of old native EOA authorization

    Path: No existing native account operation revokes the old EOA verifier; delegation replacement remains available through the original native signing route.

    Prerequisites

    Confidence: Qualified: OP's documented EVM equivalence supports the native-EOA inference; no independent op-reth execution was performed. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.optimism.io · Source 2 · eips.ethereum.org · Source 3 · ethereum.org
  • Robinhood Chain — Current execution path blocked: The reviewed Robinhood Chain ordinary EOA has no account-level mechanism that disables new use of its old native signature algorithm after migration. Removing Safe owners or modules applies to the optional Safe scope. Boundary: This finding concerns the assessed native account surface. It does not imply that ERC-4337 wallets need a fork, that all smart wallets retain old routes, or that a whole-network algorithm ban is required.

    Path availability

    Status: Blocked. Scope: Standard account / output. New network upgrade required: Yes.

    Mechanism: Retirement of old native EOA authorization

    Path: No existing native account operation revokes the old EOA verifier; delegation replacement remains available through the original native signing route.

    Prerequisites

    Confidence: Qualified: current Robinhood mainnet documentation establishes the supported EVM account model and delegation, not an independent client-to-deployment audit. Qualified inference. Checked 2026-09-09. A deployed authorization mechanism for ordinary native accounts, with a documented adoption path that meets this criterion. Optional contract-wallet functionality alone does not meet it. Source 1 · docs.robinhood.com · Source 2 · docs.robinhood.com · Source 3 · docs.robinhood.com · Source 4 · eips.ethereum.org
  • Zcash — Capability evidenced: The owner can consume the selected transparent UTXO in a confirmed shielding transaction. Consensus spent-output checks retire its ECDSA authorization for that value, and its Ironwood successor has no ECDSA spending branch. Boundary: The retirement applies to the consumed output and the selected successor note. Other transparent outputs remain valid. Orchard-to-Ironwood alone is not credited as retirement of RedPallas, which both pools still use.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Owner-authorized output consumption and shielded successor rules

    Path: Spend the selected UTXO into an Ironwood note and confirm the transaction; the old output cannot be reused and the successor uses its own native authorization.

    Prerequisites

    • The selected native pools and v6 format are active on mainnet. — Available: The mainnet announcement confirms NU6.3 at height 3,428,143 on 28 July 2026; Zebra 6.0.0 implements that activation and the Ironwood rules.
    • A standard wallet supports spending transparent funds into the native shielded pool. — Available: Zodl documents transparent exchange deposits and a Shield action to the wallet shielded address. NU6.3 directs newly shielded value into Ironwood; current wallet releases support it.
    • The old authorization route must cease to authorize the migrated value. — Available: State validation explicitly rejects duplicate spends in one block and outputs spent by previous blocks; spent outputs are absent from finalized UTXO state. The successor note is validated through its pool-specific proof and signature checks, with no transparent-signature branch.
    Confidence: Qualified: source-backed interpretation of the named surface; no independent node, wallet or cryptographic testing was executed. Qualified inference. Checked 2026-09-23. Changes to UTXO spend enforcement or any alternate authorization route for the selected Ironwood note. Source 1 · github.com · Source 2 · github.com · Source 3 · zips.z.cash · Source 4 · support.zodl.com · Source 5 · zips.z.cash · Source 6 · github.com
  • NEAR Protocol — Capability evidenced: An authorized full-access key can execute native DeleteKey for each retiring Ed25519/secp256k1 key. Deletion removes the stored access-key record, and subsequent transactions using that absent key fail the native access-key lookup. Boundary: This is an owner-enforced sunset for one settled, key-only account after all classical full-access and function-call routes are removed. It is not a protocol-wide ban; a legitimate remaining owner can intentionally install another key later. Contract recovery and pre-authorized in-flight work are outside the selected object.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Owner-authorized native DeleteKey retirement

    Path: Retain usable ML-DSA-65 full access, then finalize DeleteKey for every classical authorization key on the account and check the resulting key set.

    Prerequisites

    • ML-DSA-65 native transaction and access-key support is active on mainnet. — Available: The 2.13.0 mainnet release stabilized the feature at protocol version 85; the official mainnet RPC reported protocol 86 and nearcore 2.13.4 on 2026-09-23.
    • The owner controls an existing full-access key, has the successor key and can fund fees and storage. — Available: Released NEAR CLI v0.30.1 generates ML-DSA-65 keys and supports ordinary AddKey and transaction signing. The native runtime charges fees and storage. The owner must preserve the generated key material.
    • All classical authorization routes for the selected account can be removed after the successor is usable. — Available: For an ordinary named account with no local or global contract, the owner can delete every Ed25519/secp256k1 full-access and function-call key, retaining ML-DSA-65 full access. The assessed keys are regular non-gas keys, and the account state is settled. This does not assume that contract recovery or outstanding pre-authorized work is revoked.
    • The authorized owner has an enforceable removal mechanism. — Available: AddKey/DeleteKey require the account actor; DeleteKey removes the trie entry, and future native verification requires a present entry. Regular non-gas keys avoid gas-key withdrawal prerequisites.
    Confidence: High for the native removal mechanism and scoped enforcement. Qualified inference. Checked 2026-09-23. Reassess after changes to key-removal authority, access-key enforcement or alternative account recovery routes. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · docs.near.org · Source 5 · github.com

Is there a migration mechanism for existing data that depends on the old cryptography?

NIST basis: Section 5.1 requires a mechanism for data and signed material already protected by retiring cryptography. CSWP 39-upd1, section 5.1, printed p. 24

What counts as yes: A yes needs a specified migration mechanism for the named stored state, preserving integrity and authorization. A wrapper or new future object does not alone establish this.

Scope: One named standard native account or deployed protocol stored-state surface whose integrity and authorization must survive; this does not require migration of all history. Rewriting is allowed when those properties are preserved.

  • Starknet — Capability evidenced: When an eligible class executes, live Starknet rules migrate its existing class_hash-to-compiled_class_hash state entry from Poseidon to a Blake-based value. The migration preserves class identity and executes the same code, while recording the updated mapping in the state diff. Boundary: This covers eligible Cairo 1 compiled-class-hash mappings. It does not rewrite old signatures, migrate Cairo 0, alter every storage commitment or remove Ethereum settlement dependencies.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Existing compiled-class-hash state migration

    Path: A successful transaction invokes an eligible class still carrying the old compiled-class hash; current protocol rules update the existing trie entry and expose the migration in the state update.

    Prerequisites

    • The compiled-class-hash migration rules are already activated. — Available: Official version notes identify Starknet v0.14.1 as live on Mainnet. Its migration applies to classes used by successful transactions that do not revert.
    • The migration preserves the named stored state's integrity and execution meaning. — Available: Version notes state execution uses class hashes and is unaffected by the compiled-hash update. Sequencer tests assert the exact finalized mapping for executed eligible classes.
    Confidence: High for the documented Mainnet migration mechanism and state-diff tests. This does not establish that every eligible class has already migrated. Public source. Checked 2026-09-09. Changes to eligible class definitions, migration triggers, state-diff commitments or verification of the successor hash. Source 1 · docs.starknet.io · Source 2 · community.starknet.io · Source 3 · github.com
  • Ethereum — Capability evidenced: BLSToExecutionChange migrates an existing validator's stored BLS withdrawal-key commitment into an authenticated execution-address credential in the same validator record. Current protocol rules and supported tooling permit an eligible old-key holder to perform the conversion without another network upgrade. Boundary: The assessed stored state is withdrawal_credentials and the associated validator balance. Conversion is one-way and requires an existing 0x00 credential with its old key still available. It does not migrate an ordinary EOA, rotate the validator consensus key, rewrite history or replace Ethereum's global state and commitment cryptography.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Migration of the existing validator withdrawal_credentials commitment

    Path: For a controlled, unconverted 0x00 validator, create and broadcast a signed BLSToExecutionChange to the intended execution address, then read back the converted credential. The operation changes the existing record while retaining its associated balance.

    Prerequisites

    • Activated protocol support for an existing 0x00 withdrawal-credential conversion — Available: Ethereum's current withdrawal and credential guides document support for this conversion after Shapella. No new activation is required.
    • Control of the existing BLS withdrawal key, an intended execution address and a consensus-node submission path — Available: The standard ethdo workflow generates and broadcasts a signed change. It is available only to an owner who retains the old key and has an unconverted 0x00 credential.
    • Authenticated conversion preserving the existing validator record and its balance — Available: process_bls_to_execution_change checks index, old credential commitment, signature and chain domain, then replaces the withdrawal_credentials field in the existing validator record.
    Confidence: High for the specified state transformation and documented current operation; this audit performed no transaction and does not establish eligibility for every validator. Public source. Checked 2026-09-09. Removal or alteration of the BLS-to-execution conversion, exhaustion of eligible state, changed authority requirements, or an intended claim about a different stored-state surface. Source 1 · raw.githubusercontent.com · Source 2 · ethereum.org · Source 3 · ethereum.org · Source 4 · github.com · Source 5 · raw.githubusercontent.com
  • Bitcoin — Capability evidenced: An owner-authorized spend migrates existing P2WPKH-controlled value into an ordinary key-only Taproot UTXO. The source signature authorizes the successor output and ledger rules conserve value minus fees. Boundary: The assessed stored state is spendable value in one native UTXO. The standard wallet path replaces the earlier arbitrary-script example. It rewrites the object, without migrating history or changing an unspent output in place.

    Path availability

    Status: Available. Scope: Protocol component. New network upgrade required: No.

    Mechanism: Standard P2WPKH balance migration to key-only P2TR

    Path: Spend the existing P2WPKH outpoint with its owner key, using a signature that commits to all outputs, and create a controlled key-only Taproot successor.

    Prerequisites

    • Taproot and legacy authorization are accepted by current mainnet rules. — Available: Core's maintained implementation list records mainnet activation and the subsequent always-active Taproot validation. Core 22 provides standard wallet support.
    • A released wallet can create and sign the selected ordinary key-only Taproot output. — Available: Core supports Taproot descriptors and signing. The tr(KEY) descriptor creates a Taproot output without a script tree. The owner must control an unspent source output and pay the fee.
    • Old authorization commits the migration and value is conserved. — Available: Use the standard fully signed transfer path; the transaction consumes the source and creates the specified successor, preserving transferred value after fees.
    Confidence: Qualified: specified native spending rules and released standard wallet support establish the migration path; no new funded transaction was broadcast. Qualified inference. Checked 2026-09-09. Changes to standard P2WPKH-to-Taproot wallet spending or integrity/authorization rules for the migrated value. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · bitcoincore.org
  • Solana — Not established by reviewed evidence: A native converter for legacy durable-nonce state is available, but the review did not establish an eligible old-state input. Historical mainnet automation is complete, a bounded finalized query found no standard-size initialized legacy nonce accounts, and current native initialization creates Current state. No other currently executable migration of stored state dependent on old cryptography was established. Boundary: UpgradeNonceAccount remains available and has tests showing that it preserves authority. That does not establish a usable migration target today. The query covered one endpoint and slot, and only standard-size accounts. Other stored-state surfaces remain outside that check. The conversion changes the hash-domain construction while retaining SHA-256, so it is not a signing-primitive or post-quantum replacement.

    Path availability

    Status: Not established. Scope: Protocol component. New network upgrade required: Not established.

    Mechanism: Retained native converter for the legacy durable-nonce hash domain, pending an eligible input

    Path: Current CLI and System Program can convert initialized Legacy nonce state, but an eligible live input was not established. The scoped finalized query found zero standard-size Legacy/Initialized accounts; current native creation initializes Current state. A fabricated legacy test account is not a present user migration route.

    Prerequisites

    • The named old-state converter is retained under current protocol rules. — Available: Current official System Program documentation lists UpgradeNonceAccount. Agave v4.2.2 retains an unconditional instruction arm plus a CLI that constructs, signs and submits it. The target must be an initialized legacy nonce account; current or uninitialized state is rejected.
    • A legitimate initialized legacy nonce target is available to migrate under current rules. — Not established: The historical rollout records automated mainnet conversion as complete. A finalized read-only System Program query at slot 449658225, filtered to dataSize80 and Legacy/Initialized prefix, returned zero accounts. Current native initialization writes Current state, while changing an account owner requires empty or zeroed data. No ordinary current route or live legacy target was established; this bounded check does not prove every possible alternative absent.
    • The conversion changes the named cryptographic construction while preserving the stored account and authority. — Available: Agave locks solana-nonce 3.2.0. Its Versions::upgrade replaces only durable_nonce with SHA256(DURABLE_NONCE || old nonce) and changes the version to Current, retaining authority and fee state. The System Program writes that state in the same account without transferring its balance or changing its owner. This is a hash-domain construction change, not a new hash primitive.
    • The migrated state remains usable only through the preserved authorization rules and rejects the old nonce domain. — Available: Versions::verify_recent_blockhash rejects Legacy and requires the stored Current nonce. Advance and withdraw require the retained nonce authority; reauthorization separately requires the current authority signature. Released tests check conversion, preserved fields, repeat-conversion rejection and current-vs-legacy nonce verification. Previously signed transactions using the old nonce are invalidated and require resigning.
    Confidence: Medium. The current converter and creation rules were checked at pinned versions. The remaining uncertainty is whether a legitimate old-state input or another qualifying migration exists today. No public assessment. Checked 2026-09-23. A legitimate current legacy nonce target, or another named migration of state dependent on old cryptography, with an available input, retained converter and preserved integrity and authority. Before awarding nonce-based credit, clarify whether changing a construction while keeping the same primitive satisfies the frozen Q8 definition. Source 1 · solana.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com · Source 7 · github.com · Source 8 · github.com · Source 9 · github.com · Source 10 · github.com · Source 11 · github.com · Source 12 · github.com · Source 13 · crates.io · Source 14 · github.com · Source 15 · github.com · Source 16 · api.mainnet-beta.solana.com
  • Algorand — Capability evidenced: Authenticated native rekeying migrates the authorization of an existing account's balance and holdings to a supported Falcon authorizer while retaining the account address and ledger state. Boundary: The assessed stored state is the live account's holdings and AuthAddr. Historical signatures, address hashes and consensus keys are not replaced. Closing out the account deletes its migrated record.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native account-state preservation through AuthAddr replacement

    Path: Authenticate RekeyTo on the existing account and continue authorizing its retained holdings with the activated native Falcon signer.

    Prerequisites

    • Native Falcon-1024 authorization is activated on mainnet. — Available: Algorand's official deployment page dates native Falcon-1024 mainnet support to August 2026, after v5.0.0 approval. The release enables the v42 f1 scheme.
    • A native Falcon signer and sufficient transaction fees are available. — Available: The released algokey pq tool generates or imports keys and signs transactions. The documented minimum fee for a basic Falcon transaction is 3,000 microAlgo. The end-to-end workflow creates an unsigned transaction, signs it with algokey and submits it through goal rawsend.
    • The current authorized key can submit a rekey preserving the selected live account. — Available: RekeyTo updates AuthAddr. Later validation uses the new authorizer while the account keeps its address and holdings. The owner must act before losing the old key and keep the account record live.
    Confidence: Qualified: current native account/rekey documentation and deployed signer support establish the state-preserving path, without a new mainnet transaction in this audit. Qualified inference. Checked 2026-09-09. Changes to rekey preservation of account holdings, native Falcon signer support or deletion/recreation of the selected ledger account. Source 1 · dev.algorand.co · Source 2 · dev.algorand.co · Source 3 · algorand.co · Source 4 · github.com
  • QRL — Capability evidenced: A standard authorized transfer moves an existing XMSS-controlled balance into a supported successor hash configuration. The signed destination and amount, together with native validation of debits and credits, preserve authorization and transferred value after fees. Boundary: The named stored state is the selected balance; source key access and an unused OTS index are required. Existing address hashes, historical signatures and all other state are not rewritten.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native stored-balance migration between supported XMSS configurations

    Path: Generate a controlled standard successor and use an unused old OTS index to sign the recipient and amount. Native state application debits the old balance and credits the new one.

    Prerequisites

    • The selected XMSS hash and height are supported by ordinary QRL tooling and native verification. — Available: Wallet documentation lists SHA2-256, SHAKE128, SHAKE256 and heights 8 through 18. The native descriptor selects the supported hash and height for the qrllib verifier, without a custom account.
    • The owner has an unused source OTS index, enough balance for the transfer and fee, and a controlled successor address. — Available: Ordinary signed transfers bind recipient and amount, check balance, nonce and OTS reuse, then debit/credit ledger state. Migration must happen before source OTS capacity or key access is lost.
    • The transfer binds the successor and conserves value. — Available: TransferTransaction.get_data_bytes includes recipient addresses and amounts. Extended validation checks the balance including fees, and apply updates sender and recipient balances in ledger state.
    Confidence: Qualified: native transfer validation plus current wallet-supported parameter choices establish the bounded migration mechanism. Qualified inference. Checked 2026-09-09. Changes to transfer value conservation, source OTS availability requirements or supported successor hash configurations. Source 1 · docs.theqrl.org · Source 2 · docs.theqrl.org · Source 3 · github.com · Source 4 · github.com
  • Optimism — Not established by reviewed evidence: Current withdrawal re-proving retains the same Keccak-derived commitments and inclusion machinery. The reviewed Super Root, shared-dispute-game, verifier-transition and alternative-DA candidates do not establish a currently usable migration of existing OP Mainnet state off its old cryptographic dependency. Boundary: Changing a dispute-game reference or wrapping an output root is not itself replacement of the stored commitment's cryptography. The inspected verifier-transition tests use a mocked verifier and feature gates; the interop migrator is a constrained one-off operation. These limits do not establish that every possible stored-state migration is unavailable.

    Path availability

    Status: Not established. Scope: Not established. New network upgrade required: Not established.

    Mechanism: Replacement of the cryptographic dependency of existing OP withdrawal commitments

    Path: Bedrock's fixed migration is complete, while current Portal re-proving keeps the existing withdrawal/storage/output-root hashing and SecureMerkleTrie inclusion. The shared-game migrator is a restricted interop operation; newer verifier-transition tests use a mock. Super Root and alternative-DA support do not establish an available migration away from the old cryptographic dependency for existing OP Mainnet records.

    Prerequisites

    • An identified existing protocol state surface and its present proof path — Available: The specifications identify legacy withdrawal commitment migration, and the current Portal implementation supports re-proving pending withdrawals against eligible dispute games.
    • A current replacement of the old commitment dependency that preserves existing-state integrity and authorization — Not established: The inspected current proof path retains the same withdrawal/storage/output-root hashing and SecureMerkleTrie inclusion. Historical Bedrock migration and changes to a proof-game reference do not establish an available cryptographic-dependency replacement for those records.
    • An applicable executable path in the newly reviewed migration candidates — Not established: The interop migrator is feature-gated and explicitly one-off; the verifier-transition test mocks proof verification. The Upgrade 20 notice targets mainnet execution for 2026-09-24, after this review, and its Super Root format does not by itself replace existing withdrawal commitment cryptography. Alternative-DA commitment constructors/readers do not supply a named existing-state transformation.
    Confidence: Qualified evidence gap: historical Bedrock migration, current Portal re-proving, Super Root/shared-game migration, verifier-transition tests and alternative-DA commitments were reviewed. For the new candidates, mainnet applicability and a replacement for the old stored-state dependency remain unestablished. No public assessment. Checked 2026-09-23. A current OP Mainnet procedure naming existing state, the old and replacement cryptographic dependencies, and integrity/authorization preservation. Recheck executed contract upgrades and verifier deployment evidence; an announced date or proof-format change alone is insufficient. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com · Source 7 · github.com · Source 8 · docs.optimism.io
  • Robinhood Chain — Not established by reviewed evidence: The reviewed blob, coordinator, database and ArbOS paths do not establish migration of a named existing Robinhood Chain record off its old cryptographic dependency. Nitro's newer AnyTrust-retirement option is not applicable to the published Robinhood Rollup configuration, and feed TLS negotiation protects transport rather than migrating stored commitments. Boundary: The published chain configuration disables the data-availability committee. Existing blob formats retain KZG verification; coordinator overlap and state/database updates do not alone replace stored commitment cryptography. A transport change does not rewrite or re-authenticate existing chain records. One qualifying stored surface would suffice.

    Path availability

    Status: Not established. Scope: Not established. New network upgrade required: Not established.

    Mechanism: Migration of existing Robinhood Chain protocol commitments away from an old cryptographic dependency

    Path: The current release reads older blob layouts with the same KZG verification, retains coordinator overlap and versioned database/ArbOS updates, and supports AnyTrust retirement for applicable chains. Robinhood's published Rollup configuration has DataAvailabilityCommittee=false. Feed TLS changes protect a connection; they do not change the cryptographic authority of stored commitments. No reviewed candidate supplies the required existing-state transformation.

    Prerequisites

    Confidence: Qualified evidence gap: the current prescribed release, new AnyTrust-retirement candidate, official chain configuration and live feed transport were checked. No supported existing-state cryptographic migration was established in those paths. The review does not rule out every possible migration. No public assessment. Checked 2026-09-23. A supported Robinhood Chain procedure naming existing stored state, its old and replacement cryptographic dependencies, authorized transformation or re-authentication, and integrity/continuity evidence under current rules. Source 1 · docs.robinhood.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · github.com · Source 7 · github.com · Source 8 · github.com · Source 9 · github.com · Source 10 · cdn.robinhood.com · Source 11 · github.com
  • Zcash — Capability evidenced: Released Zodl tooling migrates existing Orchard notes into Ironwood by authorized sends, consuming old notes and creating integrity-checked successor notes in the new pool. Users can inspect balances by pool and migrate manually or with the guided tool. Boundary: This covers existing spendable note state, not rewriting all chain history or recovering old notes after a quantum break. Cross-pool amounts are public and small residuals may remain; the future post-quantum Recovery Protocol is not deployed.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Native Orchard-to-Ironwood note migration

    Path: Control the source notes and use Zodl 3.8.0 manual sends or released 3.9.0 migration to create Ironwood notes under current NU6.3 rules, paying fees and awaiting confirmation.

    Prerequisites

    • The selected native pools and v6 format are active on mainnet. — Available: The mainnet announcement confirms NU6.3 at height 3,428,143 on 28 July 2026; Zebra 6.0.0 implements that activation and the Ironwood rules.
    • The owner controls the source funds and uses released wallet support, with funds available for the transaction fee. — Available: Zodl 3.8.0 supports Ironwood; released Android 3.9.0 includes migration. The support guide documents manual and assisted sends and confirmations. This review did not execute a transaction.
    • The migration must consume authorized old state and create valid successor state. — Available: The migration guide specifies sending existing Orchard value to Ironwood; native verification checks the respective proof and signature bundles and each pool's separate note and nullifier state. Source notes must still be spendable.
    Confidence: Documented: primary specifications, released implementation and stated deployment establish the named rule; no fresh transaction was executed. Public source. Checked 2026-09-23. Changes to old-note spendability, Ironwood note construction, migration-tool support or deployment of a separate quantum Recovery Protocol. Source 1 · support.zodl.com · Source 2 · support.zodl.com · Source 3 · github.com · Source 4 · zips.z.cash · Source 5 · github.com · Source 6 · zcash.github.io
  • NEAR Protocol — Capability evidenced: Authenticated AddKey and DeleteKey updates migrate the existing account’s stored access-key authorization state from classical keys to ML-DSA-65 while retaining its account ID and native balance, subject to normal fees and storage charges. The account’s authority is updated in place rather than transferred to a new wrapper account. Boundary: The named stored-state surface is the existing account’s authorization records and their control over its balance. This does not migrate historical signatures, block and state commitments, validator credentials, external-chain assets or independently authorized application objects.

    Path availability

    Status: Available. Scope: Standard account / output. New network upgrade required: No.

    Mechanism: Existing account access-key state migration

    Path: Install the successor on the same account, verify usable PQ signing, and retire all old keys with authenticated native state updates while preserving the existing account identity and balance.

    Prerequisites

    • ML-DSA-65 native transaction and access-key support is active on mainnet. — Available: The 2.13.0 mainnet release stabilized the feature at protocol version 85; the official mainnet RPC reported protocol 86 and nearcore 2.13.4 on 2026-09-23.
    • The owner controls an existing full-access key, has the successor key and can fund fees and storage. — Available: Released NEAR CLI v0.30.1 generates ML-DSA-65 keys and supports ordinary AddKey and transaction signing. The native runtime charges fees and storage. The owner must preserve the generated key material.
    • All classical authorization routes for the selected account can be removed after the successor is usable. — Available: For an ordinary named account with no local or global contract, the owner can delete every Ed25519/secp256k1 full-access and function-call key, retaining ML-DSA-65 full access. The assessed keys are regular non-gas keys, and the account state is settled. This does not assume that contract recovery or outstanding pre-authorized work is revoked.
    • The stored-state change preserves the existing account and authenticated authority. — Available: Runtime actions update access-key entries and storage accounting for the existing account ID; account balances are retained apart from fees. Receipt success commits state and failure rolls it back; the end-to-end test demonstrates successor spending from the same sender account.
    Confidence: High for the specified native authorization-state migration; broader stored data is excluded. Qualified inference. Checked 2026-09-23. Reassess after changes to account identity, access-key storage, authenticated state updates or the selected stored-state migration. Source 1 · github.com · Source 2 · github.com · Source 3 · github.com · Source 4 · github.com · Source 5 · github.com · Source 6 · docs.near.org