Your Chain Will Not Save You: Post-Quantum Institutional Risk Across Ethereum, Besu, Solana, Stellar, and Canton

A sufficiently capable, fault-tolerant quantum computer could break widely deployed public-key schemes such as ECDSA and Ed25519 by using Shor's algorithm.

That would threaten transaction authorization, validator or node identities, administrative keys, custody controls, and any application logic that trusts those signatures. It would not automatically break hash functions, rewrite finalized history, or compromise every blockchain component at once. The correct assessment is layer-specific: identify which signatures, encryption schemes, keys, contracts, and operational dependencies are quantum-vulnerable.

No authoritative source can give a reliable date for a cryptanalytically relevant quantum computer.

Institutions should therefore plan against three variables: the confidentiality or asset-control lifetime, the time required to inventory and migrate the stack, and the risk tolerance for exposed public keys. Harvest-now-decrypt-later applies to encrypted data collected today. Signature risk is different: once a capable quantum computer exists, exposed elliptic-curve public keys could become a route to forged authorization.

No environment reviewed in this report is end-to-end post-quantum safe by default.

Ethereum and conventional Besu deployments rely on elliptic-curve transaction authentication; Solana and Stellar classic transactions rely on Ed25519; Canton currently documents classical signing and encryption schemes. Solana has published Falcon research and early implementations, while Ethereum has draft signature-agility proposals and Stellar contract accounts support custom authorization. These are important migration tools, but they are not equivalent to a completed network, custody, wallet, validator, application, and governance migration.

No.

Bitcoin currently relies on secp256k1 ECDSA and, for Taproot, secp256k1 Schnorr signatures. Both are elliptic-curve signature schemes vulnerable to Shor's algorithm once a sufficiently capable quantum computer exists. Exposure differs by output type and spending history: some public keys are revealed only when spent, while Taproot output keys are visible in the output itself. Bitcoin can adopt new rules through consensus, but migration would still require new output types, wallet and custody support, and a policy for funds whose public keys are already exposed.

SLH-DSA is NIST's stateless hash-based digital-signature standard, published as FIPS 205 in August 2024 and derived from SPHINCS+.

Its principal strategic value is assumption diversity: security is based on hash-function properties rather than the lattice assumptions used by ML-DSA or the still-developing FN-DSA standard. The trade-off is large signatures and non-trivial signing or verification cost. Whether SLH-DSA is appropriate for every transaction, only high-assurance roots, or a hybrid design depends on throughput, storage, HSM support, key frequency, and the required assurance horizon.

No.

Solana Foundation reporting says Anza and Firedancer independently converged on Falcon and produced early implementations. Falcon could provide a compact post-quantum signature path if standardized, integrated, activated, and supported across the ecosystem. It would not by itself migrate existing Ed25519 accounts and authorities, validators, wallets, custody systems, hardware signers, programs that verify classical signatures, fee-paying flows, or issued assets. NIST has selected Falcon for FN-DSA, but FIPS 206 remains in development as of July 2026.

Yes, but only through a coordinated, multi-layer migration.

Protocol rules can add new signature schemes or account types, yet existing products may still depend on classical administrator keys, immutable verifier logic, fixed signature interfaces, custody workflows, hardware support, bridges, relayers, and historical encrypted data. The difficulty varies by architecture. The defensible question is not whether a hard fork is theoretically possible, but which dependencies can be upgraded in place, which require replacement, and which require asset or identity migration.

No.

A base-layer roadmap does not automatically migrate the product stack. Ethereum applications may retain immutable contracts, fixed permit interfaces, and classically controlled roles. Besu networks need coordinated changes across native transactions, QBFT validators, external signers, HSMs, custody, and applications. Solana must address existing Ed25519 accounts, authorities, validators, wallets, and programs. Stellar contract-account flexibility does not automatically migrate classic envelopes, issuer accounts, fee payers, validators, anchors, or custody. Canton must address supported scheme sets, namespace-root continuity, operational keys, and historical confidentiality.

Track Executive Order 14412, NSM-10, OMB M-23-02, the Quantum Computing Cybersecurity Preparedness Act, NSA CNSA 2.0, NIST FIPS 203, 204, and 205, NIST migration guidance, and forthcoming CISA and NIST CBOM guidance.

The exact legal obligation depends on whether the organization is a federal agency, a covered contractor, part of a regulated supply chain, or a critical-infrastructure operator. For digital assets, the practical requirement is a chain-aware cryptographic inventory covering transaction signatures, validators, account models, smart-contract verification, custody, HSMs, wallets, bridges, identity, privacy, and upgrade authority.

Executive Order 14412, signed on June 22, 2026, accelerates the U.S.

Federal Government's migration to NIST-approved post-quantum cryptography. It sets deadlines for high-value assets and high-impact systems, directs public CBOM guidance, initiates a NIST migration pilot, and directs proposed FAR rules for covered contractors. It does not automatically regulate every blockchain company. Its significance is the procurement and diligence cascade: agencies, contractors, banks, custodians, infrastructure providers, and software vendors will increasingly need to identify what cryptography is deployed, where it is used, and how it will migrate.

Within 30 days of June 22, 2026, agency heads must identify a PQC migration lead.

Within 90 days, OMB must issue guidance requiring agencies to review high-value assets and high-impact systems, transition key establishment by December 31, 2030, transition digital signatures by December 31, 2031, and submit migration plans. Within 180 days, NIST must initiate a pilot to finish by December 31, 2027; the FAR Council must publish a proposed contractor-compliance rule; and the cryptographic-module validation process must be reviewed for acceleration. Within 270 days, CISA and NIST must publish minimum CBOM guidance, and the FAR Council must propose cryptographic-vulnerability disclosure requirements. NIST's broader 2035 transition target is separate guidance, not an EO 14412 deadline.

Primarily through procurement, covered federal contracts, critical-infrastructure assistance, vendor diligence, cryptographic inventory requests, and vulnerability-disclosure expectations.

The order does not directly impose the same duties on every private blockchain company. However, a provider serving agencies, contractors, regulated institutions, custodians, or financial-market infrastructure should expect increasing requests for NIST-aligned algorithms, migration plans, validated modules, residual-risk disclosure, and machine-readable cryptographic inventories.

A chain-aware post-quantum CBOM produces a clear PASS or FAIL assessment for the deployed cryptographic control plane.

For the environments reviewed here, it would identify classical transaction or account signatures, validator and node keys, application verifiers, custody and HSM dependencies, wallet and relayer keys, issuer and administrator controls, and any classical encryption protecting confidential data. It would also record compensating controls and migration capabilities, such as smart-account verification, contract-account authorization, alternate signer types, or draft protocol proposals. For the environments reviewed here, Ethereum, Besu, Solana, Stellar, and Canton FAIL; EternaX PASSES.

Not fully.

A hard fork can change future protocol rules, but it cannot retroactively make existing application-layer infrastructure quantum safe. Ethereum has five layers of ECDSA exposure: address derivation, transaction signing, the ecrecover precompile, immutable smart contracts, and frozen permit interfaces. Address derivation exposes public keys once an EOA transacts. Transaction signing requires coordination across clients, validators, wallets, L2s, and infrastructure providers. ecrecover is a protocol-level primitive. Immutable contracts cannot be patched. ERC-2612 permit interfaces cannot accept PQ signatures because their ABI is ECDSA-specific. A hard fork may protect part of future transaction validation, but it does not rewrite the institutional application stack.

An Ethereum externally owned account is derived from a secp256k1 public key.

Before an account sends its first transaction, the public key is not visible onchain, only the address is visible. Once the account signs and sends a transaction, the signature reveals enough information for the public key to be recovered. Under classical assumptions this is acceptable. Under a cryptographically relevant quantum computer, elliptic-curve public keys become a path to private-key recovery through Shor's algorithm. That means any Ethereum address with an exposed public key becomes materially different from a never-used address. For institutions, this matters because operational wallets, admin keys, signer keys, custody keys, and treasury addresses are usually active, not dormant.

ERC-3643 is not inherently tied to one signature algorithm, so the specification itself should not be called ECDSA-only.

A conventional deployment can nevertheless remain materially post-quantum exposed because owners, agents, investors, claim issuers, identity registries, compliance controllers, recovery authorities, and proxy administrators are commonly controlled through classical Ethereum accounts or ECC-backed governance. Claim-signature security is implementation-dependent. A PQ claim verifier alone does not migrate the surrounding accounts, validators, custody, and upgrade controls.

ONCHAINID-style identities contain claims signed by trusted issuers, but the applicable signature scheme depends on the implementation.

Where claim validation uses ECDSA or management keys are controlled by ECDSA accounts, a quantum compromise of the relevant issuer or identity-management key could enable forged eligibility claims or unauthorized identity changes. The accurate conclusion is implementation-specific: an ECDSA-only claim path is exposed, while a PQ claim path managed by an ECDSA owner is only partially migrated.

Any issuer, transfer agent, identity provider, claim issuer, custodian, wallet provider, compliance operator, exchange, or infrastructure vendor supporting an ERC-3643 deployment should assess the implementation.

Association membership or ecosystem participation alone does not prove that an institution runs an exposed production system. The diligence question is specific: which accounts control owners, agents, registries, claims, recovery, compliance, and upgrades; which signature schemes validate claims; and which network, custody, and HSM keys ultimately authorize those actions?

Not in a scheme-agnostic way.

The canonical interface encodes a signature as v, r, and s, matching Ethereum's secp256k1 convention. Most post-quantum signatures do not fit that representation. An upgradeable token can add a new authorization function, support contract-wallet validation through a different path, or deploy a replacement interface using opaque bytes and an explicit algorithm identifier. It should not claim that the original ERC-2612 ABI itself has become post-quantum signature-agile.

Not for the ERC-2612 authorization path itself.

An issuer can disable or deprecate permit, restrict its use, add a separate signature-agile authorization method, migrate users to smart accounts, or issue an upgraded token version. Existing integrations may continue to call the original v, r, s interface, so a complete migration also requires wallet, custody, relayer, paymaster, exchange, and application changes. The relevant exposure exists only where ERC-2612 is implemented and used.

No, not as an end-to-end property of the current rails.

On EVM networks, USDC authorization and administrative workflows can involve secp256k1 accounts and EIP-2612, EIP-3009, or external Permit2 integrations, depending on the chain and application. On Solana, USDC depends on Solana's current account, transaction, authority, wallet, custody, and token-program environment. Circle can upgrade some contract logic and operational controls, but full post-quantum safety also requires migration of the underlying chain authorization, user and issuer keys, custody, wallets, integrations, and any fixed classical signature interfaces.

Permit2's deployed authorization model relies on Ethereum-style signatures and contract verification that were designed for classical keys.

The canonical deployment is intentionally non-upgradeable, so it cannot be patched in place to add a new signature format. Applications can stop trusting it, deploy replacement approval infrastructure, use contract-wallet validation where supported, and migrate integrations. The precise risk depends on the signature path used and the exposure of the authorizing key; the durable remediation is replacement and ecosystem migration, not an Ethereum client update alone.

Its bytecode cannot be patched in place.

If authorization or verification is hard-coded to a quantum-vulnerable scheme, the contract will continue to apply that rule for as long as it is used. This does not mean every immutable contract is automatically exploitable or that all pool logic directly verifies signatures. Owners and protocols can remove approvals, stop integrations, deploy replacements, migrate liquidity or assets, and change surrounding account controls. The institutional problem is the coordination and residual exposure created by code that cannot itself be upgraded.

Start with an implementation-specific cryptographic inventory: token owner, agents, investors, identity-registry administrators, trusted issuers, claim topics, claim-signature schemes, compliance controllers, recovery authorities, proxy administrators, transaction signers, custody, validators, and HSM paths.

Classify each control as classical, hybrid, PQ-capable, or unverifiable. Then design application-level signature agility and a separate network-layer migration plan. Do not describe an ERC-3643 deployment as end-to-end PQ-safe merely because one claim verifier accepts a PQ signature.

Solana currently uses Ed25519 for standard transaction signatures, and public keys serve directly as account addresses.

Operational authority can also sit in transaction signers, mint and freeze authorities, program-upgrade authorities, stake and vote accounts, wallets, custody systems, and validator operations. A sufficiently capable quantum computer would threaten Ed25519. Solana has taken substantive preparatory steps, including Project Eleven testnet work and early Falcon implementations from Anza and Firedancer, but these are readiness measures rather than a completed mainnet and ecosystem migration.

A Winternitz-style vault can use hash-based one-time authorization to protect a specific asset-control path, particularly for low-frequency or pre-planned withdrawals.

It is not a replacement for Solana's default transaction scheme. It does not automatically migrate validators, ordinary accounts, fee-paying source accounts, token authorities, program-upgrade keys, wallets, custodians, or applications. One-time-signature designs also require strict key-use and rotation discipline. It should be described as a targeted containment mechanism, not system-wide post-quantum safety.

The challenge is ecosystem-wide rather than a claim that every token program is permanently unfixable.

Widely used token programs and deployed assets rely on existing account and authority conventions. A new or extended program can introduce different authorization patterns, but issuers, wallets, exchanges, custodians, DeFi applications, indexers, and users must adopt it and move authority or asset flows. Legacy programs and existing keys may remain active during transition. Institutions should inventory the exact token program, loader and upgrade status, mint and freeze authorities, multisig configuration, and custody path for each asset.

No.

Alpenglow is a consensus and performance redesign, not a complete cryptographic migration. Faster finality or a different consensus protocol does not automatically replace Ed25519 transaction signatures, user and authority keys, validator operational keys, wallet and custody integrations, token-program controls, or application-level signature verification. Post-quantum readiness must be evaluated separately across consensus, transaction authorization, accounts, programs, and operational infrastructure.

Not by default.

Current Canton documentation lists classical signing schemes such as Ed25519 and ECDSA variants, and classical asymmetric-encryption options including ECIES over P-256. Canton supports key rotation and delegation for many operational keys, but the namespace root is structurally tied to its key fingerprint and cannot simply be rolled without creating a new namespace. A complete migration would require supported post-quantum schemes, synchronizer compatibility, KMS and custody support, operational-key migration, namespace-continuity design, and a plan for already-captured encrypted traffic.

A Canton namespace is identified by the fingerprint of its root signing key.

Digital Asset documentation states that the root namespace key cannot be rolled because a new key would define a new namespace. Operators can keep the root offline and delegate authority to rotatable intermediate keys, which substantially reduces day-to-day exposure. However, replacing the root trust anchor with a different cryptographic scheme raises an identity-continuity problem: the system needs a governed way to preserve or transition identifiers, delegations, parties, references, and legal or operational mappings without treating the new key as an unrelated namespace.

Canton uses confidentiality mechanisms that can involve classical public-key encryption, including documented ECIES P-256 configurations.

An adversary able to record encrypted traffic or stored ciphertext today could attempt to decrypt it later if a cryptanalytically relevant quantum computer becomes available and the ciphertext remains obtainable. The severity depends on the actual scheme, session-key design, data captured, retention period, network access, and confidentiality lifetime. Future migration protects new traffic; it cannot recall ciphertext already copied by an adversary.

Inventory the configured signing and encryption schemes, namespace-root and delegated keys, protocol and authentication keys, synchronizer requirements, KMS capabilities, certificate and TLS dependencies, encrypted-data retention, and the confidentiality horizon of transaction information.

Separate root-identity continuity from ordinary key rotation, and separate future signing migration from historical ciphertext exposure. Ask the operator or vendor for a scheme-agility roadmap, interoperability plan, downgrade controls, and treatment of data already encrypted under classical public-key assumptions.

No.

MPC changes key management, not the underlying signature scheme. An MPC wallet can split control of an ECDSA or Ed25519 private key across multiple parties, reducing single-point custody risk under classical assumptions. But if the final onchain signature is ECDSA or Ed25519, the asset still depends on a quantum-vulnerable public-key scheme. Once a cryptographically relevant quantum computer can recover private keys from exposed public keys, distributing the key shares does not make the signature algorithm quantum safe. MPC is valuable custody infrastructure. It is not a substitute for post-quantum signatures, post-quantum address design, and post-quantum verification logic.

Not automatically.

Fireblocks and other MPC custody platforms can materially reduce single-key and operational risk, but MPC does not change the signature algorithm ultimately accepted by the blockchain or application. If an asset movement, permit, validator action, or administrative function is authorized by ECDSA or Ed25519, that authorization remains dependent on the classical scheme. A complete assessment must distinguish Fireblocks' internal controls from the chain, token, smart-contract, wallet, bridge, and external-signature dependencies of the specific workflow.

At the infrastructure level, a tokenized fund inherits the cryptography of each chain, wallet, custodian, transfer-agent workflow, administrator account, bridge, liquidity venue, and smart contract it uses.

The token interface itself may be portable or upgradeable, while surrounding authorization paths remain classical. This is not a claim that BUIDL or any named fund is presently compromised. It is a diligence requirement: map every representation and control path, then distinguish upgradeable contracts from immutable integrations and classically controlled operational roles.

The common exposure is not 'blockchain' in the abstract; it is classical public-key cryptography embedded across user accounts, validators, custody, issuer roles, permits, identity claims, upgrade authorities, bridges, and encrypted settlement data.

Ethereum and Besu commonly rely on secp256k1, Solana and Stellar classic transactions use Ed25519, and Canton documents classical signing and encryption options. Failure at one authorization or confidentiality layer can propagate into tokenized funds, stablecoins, regulated securities, collateral, and settlement workflows even when the token contract itself is technically sound.

A Cryptographic Bill of Materials is an inventory of the cryptographic algorithms, libraries, keys, and dependencies used by a system.

For blockchain products, a CBOM cannot stop at the issuer's backend. It must include the underlying chain, signature algorithm, address derivation method, precompiles, smart-contract standards, identity systems, custody signing flows, wallet integrations, hardware security modules, MPC providers, encrypted settlement data, and immutable contracts. A tokenized product that says it is institution-grade but cannot name its ECDSA, Ed25519, ECIES, permit, and ONCHAINID dependencies is not ready for serious post-quantum diligence.

There is no universal percentage.

Results depend on the algorithm and parameter set, signature and public-key sizes, transaction format, verification implementation, block and message limits, batching, hardware, HSM support, consensus, network topology, and whether the migration covers transactions, validators, applications, or all three. Publish measured test conditions, software versions, hardware, workload, latency percentiles, bandwidth, storage growth, and security parameter. Label modeled results as models and prototypes as prototypes; do not convert them into a production-wide claim.

Only partially.

Some standards, including ERC-20, ERC-721, ERC-4626, ERC-4337, and newer signature-agnostic standards, can be ported or adapted more cleanly. But full post-quantum safety requires more than a clean token interface. It requires PQ-safe wallets, PQ-safe custody flows, PQ-safe admin controls, PQ-safe permit or approval mechanisms, PQ-safe identity and compliance logic, and avoidance of immutable classical contracts. A tokenized fund can reduce exposure on Ethereum, but it cannot make the full legacy environment disappear. For new issuance, the cleaner strategic choice is to separate future institutional products from avoidable cryptographic debt.

The report distinguishes standards that explicitly encode classical signatures from those that are cryptographically neutral or signature-agile.

ERC-2612 is explicitly secp256k1-shaped. ERC-20, ERC-721, ERC-4626, ERC-1967, ERC-3643, and ERC-7943 do not universally mandate ECDSA, but conventional deployments can inherit classical account and administrator risk. ERC-1271 and ERC-4337 can enable custom authorization, but do not migrate the underlying network. This classification avoids claiming that every ERC is intrinsically broken.

Institutions should stop treating post-quantum migration as a protocol-team problem.

The immediate task is a cryptographic exposure map covering every chain, signature scheme, address model, smart-contract standard, permit flow, custody provider, MPC or HSM dependency, compliance verifier, immutable contract, and encrypted settlement path used by the product. Classify each dependency as clean-port, replaceable, coordination-heavy, or non-upgradeable; then assign an owner, migration trigger, budget, and deadline. Existing products may need containment and staged hardening. New products should use rails where post-quantum security and cryptographic agility are native. EternaX provides that new-issuance path and hardens critical authorization across legacy rails.

Besu is an Ethereum execution client.

It can participate in public Ethereum or run private and consortium networks using configurations such as QBFT, known validators, permissioning, and enterprise-specific gas and governance policies. On public Ethereum, its protocol-level behavior follows Ethereum. In private mode, governance and consensus differ, but the EVM, Ethereum transaction model, address conventions, tooling, and application standards can preserve many of the same cryptographic dependencies. It is therefore a distinct institutional migration case, not a separate cryptographic family.

No.

Standard Besu transaction and account authentication remains elliptic-curve based. Private networks can configure secp256r1 in early-access mode instead of secp256k1, but both are classical elliptic curves. Full migration must cover transaction authentication, QBFT validator keys, external signers, HSMs, custody, privileged smart-contract roles, wallets, relayers, tooling, TLS and node authentication where applicable, and any separate privacy or middleware layer. A PQ verifier inside one contract protects only that authorization decision.

No.

Permissioning controls who may connect, submit transactions, or validate. It can reduce the attack surface and make governance more coordinated, but it does not change the mathematical security of the signatures or encryption used by approved participants. A permissioned network can still depend on quantum-vulnerable transaction keys, validator keys, administrator accounts, custody systems, TLS certificates, and application signatures.

They can make selected smart-account authorization paths signature-agile.

ERC-1271 lets a contract define signature validity, and ERC-4337 lets a smart account define UserOperation validation. Neither automatically changes Besu's native transaction authentication, QBFT validator keys, bundler and relayer accounts, network authentication, custody, HSMs, or other classically controlled contracts. The accurate claim is application-level PQ authorization, unless the complete network and operational stack has also migrated.

Not as a standard production transaction scheme as of July 2026.

Ethereum proposals such as EIP-7932 and EIP-8051 address alternative algorithms and ML-DSA verification, but remain Draft. A verifier contract, plugin, relayer, meta-transaction system, or bespoke Besu fork can demonstrate or deploy a selected PQ path, but that capability is deployment-specific. It must not be described as upstream, network-wide Besu support unless the transaction, validator, tooling, and interoperability layers actually implement it.

No.

Stellar documentation identifies Ed25519 as the standard signature scheme for classic transactions, although the protocol also supports alternate signer types such as pre-authorized transactions and hash(x). Thresholds and multisig improve governance, while Soroban contract accounts provide programmable authorization. None of those features by itself migrates classic transaction envelopes, issuer and distribution accounts, validators, wallets, anchors, exchanges, custody systems, or fee-paying source accounts to a standardized post-quantum signature scheme.

Not when the required signers all rely on the same quantum-vulnerable public-key family.

Thresholds and multiple signers can reduce single-key compromise risk, separate duties, and preserve control when one signer is unavailable. Against a future adversary capable of attacking Ed25519 at scale, multiple Ed25519 signers add operational separation but not cryptographic assumption diversity. A defensible design needs at least one genuinely post-quantum authorization path, plus downgrade prevention and a migration plan for the envelope and fee-paying layers.

In principle, yes.

A Soroban contract account implements custom __check_auth logic and can validate a user-defined authorization format, subject to host capabilities, resource limits, implementation correctness, and auditability. This can protect the contract-account authorization path. Stellar documentation also makes clear that C-accounts cannot sign transaction envelopes or pay fees directly; a separate G-account must submit the transaction and pay XLM fees. Therefore, PQ contract authorization does not by itself migrate the envelope source, fee payer, validator, wallet, custody, or ecosystem layers.

Issuing-account and distribution-account control, authorization flags, trustline authorization or revocation, clawback, signer and threshold changes, treasury movement, and administrative operations are high-impact surfaces.

These controls are legitimate features for regulated assets. The risk arises when the accounts and signers authorized to exercise them rely only on quantum-vulnerable keys. Institutions should also inventory anchors, custodians, exchanges, relayers, and recovery procedures that can influence or depend on those accounts.

No.

A Stellar Asset Contract exposes a classic asset to Soroban and can participate in programmable contract workflows. A contract account can add custom authorization for selected holders or applications. The underlying classic asset, issuer and distribution accounts, trustline controls, transaction-envelope source, G-account fee payer, validators, wallets, anchors, custody, exchanges, and other integrations may still use classical authorization. The contract layer can improve selected paths; it does not automatically complete a network-wide migration.