Five Coupled PQ Attack Surfaces. No Public End-to-End Remediation Plan.
A 2024 Blockdaemon analysis of 92 firms cited Besu more often than any other protocol, with over 40% mentioning it. Public deployments span market infrastructure, tokenized payments, post-trade systems and public-sector networks; institutional transaction volumes must not be misrepresented as Besu-processed volume.
Besu's default transaction authentication, common QBFT validator configurations and RLPx transport rely on elliptic-curve cryptography vulnerable to a sufficiently capable quantum computer. The risk spans five coupled layers, with no publicly documented programme covering them as one institutional migration.
Report path: institutional exposure, global urgency, the DTCC case, five technical surfaces, the 48-point control map, and a credible migration path.
What Is Hyperledger Besu?
Besu began as PegaSys' Pantheon in 2018 and joined Hyperledger, now LF Decentralized Trust, in 2019. The Apache 2.0 Java client implements enterprise Ethereum specifications.
Besu runs on Ethereum mainnet and private permissioned networks. Private deployments commonly use QBFT for deterministic finality after validator quorum.
Its institutional appeal is EVM compatibility: Solidity, ERC standards, JSON-RPC and established tooling can operate in permissioned environments, subject to each network's consensus, permissioning, privacy and transaction design.
Which Institutions Use Hyperledger Besu?
The tables distinguish confirmed Besu use from historical, component-level and frequently misclassified systems. EVM compatibility, working-group membership or adjacent-project participation does not prove a current deployment.
Confirmed, Historical, and Adjacent Institutional Systems
| Network | Institutions and status | Besu position |
|---|---|---|
| DTCC Tokenization Service | More than 50 firms contributed through DTCC's working group; more than 30 joined the July 2026 production initiative. Service launch is planned for October 2026. | CONFIRMED July trades used LFDT Besu on DTCC's private network and Canton. |
| Swift Shared Ledger | Seventeen banks were preparing to pilot live transactions as of July 2026. | BESU-BASED ARCHITECTURE Swift describes an EVM-compatible architecture based on Besu. |
| Fnality | Sterling wholesale settlement entered live operation in December 2023. | CONFIRMED LF Decentralized Trust identifies Fnality as Besu-based. |
| LACChain / LACNet | Public- and private-sector ecosystem across Latin America and the Caribbean. | CONFIRMED Besu-based network for identity, credentials, inclusion, and tokenization use cases. |
| mBridge | Central banks and commercial banks use the purpose-built mBridge Ledger. | NOT BESU EVM compatibility does not make the mBridge Ledger a Besu network. |
| BIS Project Agorá | Eight central banks and more than 40 regulated financial institutions participated. | UNCONFIRMED Public BIS materials do not identify Besu as the runtime. |
| Kinexys / JPM Coin | JPMorgan's production enterprise Ethereum platform. | GOQUORUM, NOT BESU GoQuorum is a separate Geth fork. |
| eNaira | Central Bank of Nigeria CBDC, live since October 2021. | NOT BESU The official design paper identifies a Hyperledger Fabric variant. |
FSWG Membership, Deployments, and Component Use
| Entity | Publicly documented relationship | Status |
|---|---|---|
| Visa, Mastercard, Santander | Founding Financial Services Working Group members. Membership does not establish production Besu use. | FSWG MEMBERS |
| Citi | Selected Besu for its internal digital-asset platform and Citi Token Services infrastructure. | CONFIRMED PLATFORM |
| JSCC | Deployed Besu for commodity-futures settlement tokenization. | CONFIRMED DEPLOYMENT |
| Drex | Banco Central do Brasil participated in Besu-based experimentation. | HISTORICAL PILOT |
| Digital Rupiah | Bank Indonesia evaluated multiple DLT approaches; production Besu use is not established. | NOT VERIFIED |
| Hedera | Uses Besu-derived EVM components while operating its own consensus. | COMPONENT USE |
| Linea | Uses Besu with L2-specific plugins for EVM execution. | BESU-BASED EXECUTION |
The DTCC-chaired FSWG coordinates enterprise priorities; membership does not prove production use.
The next question is which regulatory, procurement and supervisory timelines govern these institutions and shared transaction paths.
Why Besu Institutions Must Act Now: Global Post-Quantum Deadlines
The issue is not one universal prohibition date. It is whether a multi-year Besu migration can finish before the earliest applicable federal, critical-infrastructure, procurement, supervisory or counterparty deadline across a cross-border transaction path.
Completion targets are not start dates. Migration can require cryptographic discovery, transaction and validator redesign, privacy and contract changes, HSM/KMS upgrades, procurement, testing, governance and coordinated activation. Long-lived ciphertext is exposed from the moment it is captured.
Jurisdiction-to-Institution Mapping
The table maps official PQ positions to publicly supported programme, home-jurisdiction or operating nexuses. It does not assert that every named entity is directly bound; applicability depends on the legal entity, system, contract, data and local implementation.
| Framework | Official timeline or position | Weight and applicability | Institutions and programmes |
|---|---|---|---|
| G7 financial sector | The January 2026 roadmap identifies 2030-2032 as a possible priority window for the most critical financial systems and 2035 as a general overall planning target reflected in national roadmaps. | NON-BINDING FINANCIAL ROADMAP It expressly does not set regulatory expectations, but it addresses financial entities, authorities, critical service providers and technology suppliers. |
DTCC/DTC; BNY; Citi; Wells Fargo; BNP Paribas; HSBC; Lloyds; MUFG; BlackRock; Goldman Sachs; J.P. Morgan; Bank of America. |
| United States | Executive Order 14412 sets federal targets of 31 December 2030 for PQ key establishment and 31 December 2031 for digital signatures. It also directs proposed FAR requirements for covered contractors by 31 December 2030. | BINDING FEDERAL DIRECTION; CONTRACTOR RULEMAKING Private institutions are directly affected only where federal-system, covered-contract, critical-infrastructure or other applicable requirements attach. |
DTCC/DTC; Citi; BNY; Wells Fargo; BlackRock; Goldman Sachs; J.P. Morgan; Bank of America; Broadridge; CME Group. |
| European Union | Member States should start transitioning by the end of 2026. Critical infrastructure and high-risk use cases should transition as soon as possible and no later than the end of 2030. | COORDINATED EU ROADMAP It is not a universal directly applicable private-sector prohibition, but it drives national plans, critical-entity priorities, procurement and future supervisory expectations. |
Swift (Belgium); BNP Paribas (France); Santander (Spain, FSWG); EU entities participating in DTCC and Swift programmes. |
| France | ANSSI urges immediate inventory and risk prioritisation, plans PQC obligations for product qualification from 2027, and states that buying products without PQC support after 2030 will not be reasonable. | NATIONAL CYBER AUTHORITY AND QUALIFICATION OVERLAY Binding scope is narrower than a universal private-sector mandate, but the procurement and assurance signal is strong. |
BNP Paribas, named in the Swift Besu pilot and DTCC tokenization initiatives, plus France-regulated entities and suppliers on those transaction paths. |
| United Kingdom | NCSC targets discovery and an initial plan by 2028, highest-priority migration by 2031, and completion by 2035. The Bank of England stated in July 2026 that firms should begin planning. | NATIONAL GUIDANCE WITH FINANCIAL-STABILITY SIGNAL The dates are guidance, but they are aimed at large organisations, critical infrastructure and bespoke systems and are feeding regulated-sector planning. |
Fnality; HSBC; Lloyds; Standard Chartered, plus UK operations supporting DTCC and cross-border tokenized-market infrastructure. |
| Australia | ASD recommends a refined plan by the end of 2026, critical migration underway by the end of 2028, and completion by the end of 2030. The ISM recommends ceasing traditional asymmetric cryptography by the end of 2030. | GOVERNMENT SECURITY STANDARD AND NATIONAL GUIDANCE Direct applicability depends on system and ISM scope, but the guidance also addresses large organisations, infrastructure and vendor assurance. |
ANZ in the Swift Besu pilot, plus Australian operations and suppliers in cross-border tokenized-payment workflows. |
| Japan | Japan's FSA published a dedicated PQC migration report for deposit-taking institutions in November 2024. Japan also participates in the G7 roadmap and continued developing an inter-ministry roadmap in 2026. | FINANCIAL-SECTOR GUIDANCE AND ROADMAP DEVELOPMENT No universal public completion date for Japanese private financial institutions is asserted here. |
MUFG in the Swift Besu pilot and JSCC in Besu-based commodity-futures settlement tokenization. |
| Singapore | Singapore uses NIST standards as its baseline and released a Quantum-Safe Migration Handbook and Quantum Readiness Index in July 2026, particularly for critical-information-infrastructure owners, government agencies and critical services. | NATIONAL MIGRATION GUIDANCE AND CII PREPAREDNESS The public material reviewed does not set one universal completion date for all private financial institutions. |
DBS; OCBC; UOB, plus Singapore operations of Citi; HSBC; Standard Chartered and DTCC's regional ecosystem. |
| Hong Kong | HKMA publicly recruited in 2026 for responsibility to manage the transition from RSA and ECC to quantum-resilient standards, primarily PQC. | SUPERVISORY PREPAREDNESS SIGNAL The public evidence reviewed does not establish a sector-wide HKMA migration deadline for banks. |
Hong Kong operations of HSBC; Standard Chartered; Citi may face future local expectations, but public Besu announcements do not identify the relevant Hong Kong legal entities. |
| Switzerland | The Swiss NCSC has published an assessment of required action and a technology brief on quantum computers and PQC. | NATIONAL CYBER GUIDANCE No fixed national completion date is asserted from the public material reviewed. |
UBS in the Swift Besu pilot and related Swiss-regulated infrastructure and suppliers. |
| Brazil | Brazil's Federal Digital Government Strategy requires the government to define a post-quantum cryptographic standard by 2027. Federal security material also identifies blockchain signatures, PKI and long-lived data as migration concerns. | FEDERAL GOVERNMENT STRATEGY This is not presented as a direct private-bank PQC deadline. |
Itaú Unibanco; Banco Central do Brasil's historical Besu-based Drex experimentation; LACChain/LACNet and related regional ecosystems. |
| UAE and South Africa | No dedicated public national PQC migration deadline was identified in the official sources reviewed as of 3 August 2026. | PUBLIC DEADLINE NOT ESTABLISHED This does not exclude internal, sectoral, contractual, cross-border or future requirements. |
First Abu Dhabi Bank; Mashreq; FirstRand, all named in the Swift Besu pilot and connected to counterparties, vendors and infrastructures in other jurisdictions. |
Shared-path rule: the earliest applicable requirement can govern the path. Operators, validators, custodians, cloud providers, HSM vendors and software suppliers may sit in different jurisdictions; one classical-only participant can block end-to-end assurance.
For DTCC, Swift, Citi, Fnality, JSCC and similar systems, the question is whether a coordinated, auditable migration can finish before procurement, critical-infrastructure, supervisory and counterparty timelines converge around 2030–2035.
DTCC provides the clearest production-oriented case study of this gap.
Primary sources: G7 roadmap; U.S. EO 14412; EU roadmap; ANSSI; UK NCSC; Australia ASD; Japan FSA; Singapore CSA; HKMA; Swiss NCSC; Brazil strategy; and official DTCC, Swift and Citi disclosures.
Is DTCC's Tokenization Architecture Post-Quantum Safe Across Besu, Canton and Stellar?
It is not publicly documented as end-to-end post-quantum safe. On 15 July 2026, more than 30 firms used DTC-tokenized assets in production transactions, with digital conversions occurring on DTCC's private LFDT Besu network and Canton. DTCC expects its Tokenization Service to launch in October 2026 and DTC-tokenized assets to become available on Stellar in the first half of 2027.
This creates a single asset lifecycle governed across several cryptographic domains: DTC custody and conversion, ComposerX lifecycle management, CATF policy enforcement, participant wallets and custodians, Besu execution, Canton identity and synchronization, and planned Stellar issuance and transfer. The central post-quantum question is therefore not whether any one network is resilient. It is whether the authority controlling the same DTC-backed asset can migrate consistently across every network, role and recovery path.
The DTCC control gap: policy compliance is not post-quantum authentication
CATF can determine whether a transaction satisfies configured regulatory and transactional rules. It does not, by itself, protect the private key behind the participant, issuer, administrator, custodian or infrastructure role requesting that transaction. If a classical key were compromised, the request could still arrive under a valid role and satisfy valid business policy. End-to-end assurance therefore requires both policy correctness and post-quantum-safe authority.
DTCC's Post-Quantum Exposure Across the Asset Lifecycle
| DTCC control surface | What the public architecture establishes | Post-quantum exposure | Required migration outcome |
|---|---|---|---|
| DTC asset creation, conversion and servicing | DTC can create tokenized representations of DTC-custodied securities, convert assets between traditional and tokenized form, preserve the same rights and protections, and deliver tokens to DTC Participant wallets of choice within approved blockchain ecosystems. | Equivalent investor protections and lifecycle controls do not establish post-quantum authenticity for the cryptographic authorities governing mint, burn, conversion, force transfer, freeze, recovery, corporate-action or servicing instructions. | Bind every critical DTC lifecycle instruction to governed PQ authorization, key rotation, recovery and audit evidence without changing the legal asset record. |
| ComposerX Factory and CATF | ComposerX supports token creation and lifecycle management. Factory provides templates, role-based access, minting, burning, clawback and allowlists. CATF validates regulatory and transactional policies in real time. | Role and policy enforcement depend on the authenticity of the account, wallet, service or administrator invoking the permitted action. Public materials do not define an end-to-end PQ profile for those authorities. | Separate business-policy validation from signer authentication, then protect issuer, transfer-agent, compliance, recovery and administrative roles with crypto-agile PQ authorization. |
| DTCC AppChain on Besu | DTCC describes an enterprise-grade, Ethereum-compatible, permissioned AppChain based on Hyperledger Besu. It was one of the networks used for the July 2026 production conversions. | The exact private configuration is not public. Mainline Besu's standard transaction, QBFT, smart-contract authorization, node-identity and RLPx paths are not documented as using NIST-standardized PQ cryptography. | Harden token and privileged-role controls that can be upgraded around the current stack, while planning coordinated migration for native transaction authentication, validator signatures, node identity and transport. |
| Canton Network | DTCC used Canton for July 2026 conversions. Canton provides need-to-know sub-transaction privacy and a topology-based identity model spanning parties, Participant Nodes and Synchronizer services. | Canton's published supported key specifications include EC-Curve25519, EC-P256, EC-P384, EC-Secp256k1 and RSA-2048. Its documented signing and asymmetric-encryption profiles are not listed as using NIST-standardized post-quantum schemes. DTCC's specific Canton configuration is not public. | Migrate DTCC-controlled and participant authority where possible, while Canton-native topology, protocol signing, encryption and Synchronizer dependencies move through a coordinated network migration. |
| Stellar connectivity | DTCC and the Stellar Development Foundation expect DTC-tokenized assets on Stellar in the first half of 2027, supporting conversion and the asset lifecycle on a public network. | Standard Stellar account transactions use Ed25519 authorization, although Stellar provides mechanisms for additional signer types. Validator nodes still require secret keys to participate in consensus and sign ledger changes. Issuer controls such as authorization, freeze and clawback depend on account authority, while custom contract accounts can add application-specific checks without replacing classic-account or validator cryptography. | Protect DTC issuer, administrator, participant and custody authority at the application layer where possible, while treating classic account and validator migration as a Stellar-network dependency. |
| Participant wallets, custody and recovery | DTC-tokenized assets can be delivered to Participant wallets of choice, and the production ecosystem includes multiple wallet, custody, infrastructure and application providers. | Each participant may introduce separate MPC, HSM, KMS, wallet, approval, delegated-authority and recovery keys. A PQ-safe DTCC service cannot create end-to-end assurance if the final participant approval remains classical-only. | Require PQ-safe institutional approval before execution, independent of the selected wallet or custodian, with auditable key ownership, policy, rotation and recovery. |
| Multi-network orchestration and data | DTCC's strategy spans Besu, Canton and Stellar. ComposerX supports lifecycle processing, while LedgerScan aggregates, reports and reconciles data across traditional and digital ledgers. | Conversion instructions, wallet delivery, attestations, API messages, oracles, data feeds and recovery actions can create cryptographic authority outside the destination chain. Multi-chain choice does not itself create crypto agility or prevent fallback to a classical-only route. | Establish one governed authority model across every permitted network path, bind cross-network instructions to PQ authentication and prevent downgrade to weaker authorization. |
What DTCC Can Upgrade Now, and What Requires Coordination
| Control owner | Actions that can begin now | Dependencies that require coordination |
|---|---|---|
| DTCC-controlled architecture | Inventory every signer and verifier; protect ComposerX and CATF privileged roles; introduce PQ authorization for issuance, conversion, servicing, recovery and cross-network instructions; define crypto-agile policy and downgrade controls. | Production integration, governance approval, HSM/KMS support, performance testing, audit evidence and operational rollout. |
| DTC Participants and providers | Harden wallet and custody approvals, delegated authority, treasury workflows, recovery and provider access without replacing the existing custodian by default. | Participant adoption, provider capability, key migration, certification, interoperability and common assurance requirements. |
| Network protocols | Map residual dependencies and deploy compatible application-layer protections while native migration is prepared. | Besu transaction, QBFT and RLPx changes; Canton topology, protocol and encryption changes; Stellar classic-account and validator changes. |
A credible DTCC pilot: select one DTC-tokenized workflow and trace every authority from DTC instruction through ComposerX and CATF, participant custody, network execution, servicing and recovery. EternaX can use its live dual-gate custody authorization demo as the technical starting point for a controlled Besu pilot: post-quantum member authentication and signature-agnostic threshold authorization across a selected participant approval or asset-control path, with measured integration and performance impact and an explicit dependency plan for native Besu, Canton and Stellar changes requiring broader coordination.
Evidence-bounded conclusion: DTCC has institutionalized tokenization, lifecycle controls and multi-network distribution. Public materials do not establish one end-to-end PQ authority profile across DTC instructions, ComposerX and CATF roles, participant wallets, custody, Besu, Canton, Stellar, recovery and cross-network orchestration. This assessment makes no assumption about undisclosed DTCC or participant controls.
The strategic distinction: DTCC has modernized the asset lifecycle across Besu, Canton and Stellar. The next requirement is to ensure that the authority governing that lifecycle can migrate consistently across every network, participant and custody path before classical cryptography becomes the weakest link.
The Besu-specific dependencies beneath DTCC AppChain are examined next across five coupled technical surfaces.
Primary sources: DTCC's July 2026 production announcement, Tokenization Service update, tokenization architecture, ComposerX and CATF, ComposerX Factory, and Stellar connectivity; Digital Asset's Canton documentation on privacy, topology, key management and supported cryptographic schemes; and Stellar documentation on transaction signatures, validators, asset controls and custom account authorization.
The Five Post-Quantum Attack Surfaces
Besu has five coupled PQ migration surfaces requiring different interventions. Fixing one does not secure the others: PQ transaction signing cannot prevent validator impersonation, protect retained ciphertext or replace classical node transport.
Surface 1: Transaction Signing and the Address-Identity Binding
CriticalBesu's default externally owned account authentication uses secp256k1 ECDSA. The signature exposes a recoverable public key, and the EOA address is derived as keccak256(recovered_pubkey)[12:]. Contract and smart-account identities use different control rules.
After an EOA broadcasts a recoverable signature, a future quantum computer using Shor's algorithm could derive its private key. Impact depends on that account's balances, roles, approvals and administrative authority.
ML-DSA and SLH-DSA do not provide Ethereum-style key recovery. Native migration therefore needs an explicit key reference, new address binding or another authorization mechanism. ERC-4337 can support alternative smart-account signatures, but does not migrate native transactions, validators, node identities or transport.
Surface 2: QBFT Validator Block Signing
CriticalQBFT commits a block after validator quorum. Consensus messages and commit seals are authenticated below the smart-contract layer with the network's configured elliptic-curve signing implementation.
Recovering enough validator keys to meet quorum could enable impersonation or malicious consensus messages; recovering enough to deny quorum could halt finality. Exact thresholds depend on validator-set size and QBFT rules.
ERC standards and account abstraction cannot change validator authentication. Migration requires new consensus signing and seal encoding, validation logic, signing-infrastructure support and coordinated activation. Mainline Besu documents no native hybrid classical-plus-PQ validator mode.
A consortium must coordinate client activation, HSM or remote-signing support, testing, governance and rollback. Scheme support and certification remain vendor- and version-specific.
Surface 3: Privacy Encryption (Tessera and Paladin)
CriticalLegacy Besu privacy used Tessera: Curve25519 ECDH for key exchange and XSalsa20-Poly1305 for payload encryption. Curve25519 is vulnerable to Shor's algorithm.
Native Tessera privacy was sunset and removed from mainline Besu by release 25.6.0. Paladin is the modular successor framework, with Pente for private EVM groups and Zeto privacy domains. These components do not make an entire deployment end-to-end PQ-safe.
Institutions retaining Tessera-era privacy must maintain or migrate it outside current mainline Besu; other deployments may use different privacy models or none.
Recorded Tessera ciphertext and key-agreement material create harvest-now-decrypt-later exposure. Future compromise of Curve25519 confidentiality would expose data according to payload content, retention, backups and deployment design.
Institutions must inventory ciphertext, keys, recipients, backups and retention duties, then re-encrypt controlled data where possible. Data already copied by an adversary cannot be retroactively protected.
Surface 4: Smart Contracts and the ecRecover Precompile
CriticalThe ecRecover precompile at 0x01 recovers an ECDSA signer's 20-byte address from a message hash and signature. It is widely embedded in EVM authorization and costs 3,000 gas.
Mainline Besu has no generally deployed PQ signature precompile. Draft EIP-8051 proposes ML-DSA and EIP-8052 Falcon; pure-Solidity verification is more expensive and requires reproducible implementation-specific benchmarking.
ERC-2612 Permit and common ERC-3009 authorizations use recoverable ECDSA signatures. A future quantum adversary could derive the key and forge later authorizations; exposure depends on implementation, nonces, deadlines, rotation and message retention.
Contracts tied to ecrecover remain ECDSA-bound unless preserved through compatibility, upgraded, wrapped or migrated. Non-upgradeable contracts may require replacement. ERC-3643 may also require migration of privileged roles, identity claims, trusted issuers, compliance and proxy administration.
Surface 5: Node Identity and P2P Transport
HighBesu node identity uses secp256k1. RLPx transport uses ECIES and secp256k1 ECDH to derive secrets for AES-256-CTR session encryption.
Recorded handshakes may expose P2P sessions to future quantum decryption. Compromised node keys can also weaken permissioning and enable impersonation, eclipse or routing attacks, although other controls may limit impact.
Privacy requires separate treatment because copied ciphertext creates irreversible exposure.
The Post-Quantum Privacy Problem in Besu
Privacy has the longest risk horizon. Keys can be rotated before a quantum attack; copied ciphertext cannot be recalled. For retained positions, settlement instructions, bilateral exposures and private state, exposure begins when data is captured.
Which Privacy Architecture Do Major Besu Deployments Use Today?
Public disclosures often say private, permissioned or secure without naming the confidential-transaction engine. Permissioning controls network access; transaction privacy controls which permitted parties see payloads, state, counterparties or amounts. The table records only public evidence as of 4 August 2026.
| Besu-linked system | Publicly disclosed privacy model | Privacy engine | PQ implication |
|---|---|---|---|
| DTCC AppChain and Tokenization Service | Private, permissioned Besu AppChain; the broader programme also uses Canton. | NOT PUBLICLY DISCLOSED Official materials do not identify Tessera, Paladin or another Besu confidential-transaction manager. |
Permissioning does not prove PQ confidentiality. Inventory participant and administrator keys, private data, transport, backups and the Besu–Canton path. |
| Swift Shared Ledger | Besu-based shared orchestration; Swift operates the ledger while banks retain authority over keys, assets, funding and settlement. | NOT PUBLICLY DISCLOSED No Tessera, Paladin, ZK-domain or other transaction-level privacy implementation is identified publicly. |
Assess visibility of commitments, bank environments, off-ledger settlement messages, keys and retained records. Permissioning does not guarantee payload confidentiality between participants. |
| Citi Integrated Digital Assets Platform and Citi Token Services | Internal, private, permissioned blockchain owned and managed by Citi; clients need not operate nodes or hold tokens. | NOT PUBLICLY DISCLOSED Public materials do not identify Tessera, Paladin or another confidential-transaction engine. |
Restricted membership reduces outsider access but not quantum risk in platform keys, privileged roles, encrypted records, node communication or retained data. |
| Fnality Payment System | Private Ethereum payment network with permissioned participation and multiple security layers. | NOT PUBLICLY DISCLOSED Public architecture does not identify the transaction-level privacy manager or confirm Tessera or Paladin. |
The private-network label does not show who sees each payment or how data is encrypted, retained, recovered and protected from harvest-now-decrypt-later exposure. |
| JSCC commodity tokenization platform | Production Besu platform for commodity-futures settlement tokenization. | NOT PUBLICLY DISCLOSED Official materials do not identify a privacy manager or confidential-transaction mechanism. |
Do not infer Tessera or Paladin. Confirm deployed version, visibility model, encryption, backups, access and retention with the operator. |
| LACChain / LACNet | Public-permissioned Besu network for broad ecosystem participation. | NO NETWORK-WIDE ENGINE PUBLICLY IDENTIFIED Public material does not establish Tessera or Paladin; later CBDC work treats privacy as a separate design requirement. |
Permissioned validation is not confidential execution. Sensitive use cases require separate encryption, selective disclosure, private execution or off-chain controls, each with PQ dependencies. |
| Legacy Besu privacy deployments | Historical Besu private transactions used Tessera privacy groups and marker transactions. | TESSERA, LEGACY ONLY Tessera was removed from current mainline releases; older pinned networks may still operate it. |
Curve25519 key agreement is not PQ-safe, and copied historical ciphertext cannot be protected retroactively. |
| Paladin-based Besu deployments | Modular EVM privacy framework with Pente, Noto and Zeto domains. | AVAILABLE FRAMEWORK, DEPLOYMENT-SPECIFIC No public evidence reviewed shows the named systems use Paladin today. |
Paladin does not replace base transaction, consensus, node identity or RLPx cryptography. Domain ownership, proofs, endorsements, transport, KMS, backup and recovery need separate PQ assessment. |
Critical disclosure gap: most major Besu-linked systems do not publicly identify their privacy engine. Private, permissioned or secure labels cannot establish PQ privacy; the operator must disclose or inventory the actual cryptographic path.
1. Legacy Tessera confidentiality depends on quantum-vulnerable key agreement
Tessera used Curve25519 to protect symmetric payload keys. Shor's algorithm targets that key-agreement layer, not primarily XSalsa20-Poly1305. Recorded ciphertext and public material could therefore become decryptable later.
2. Migration protects future payloads, not ciphertext already copied
A PQ KEM protects new payloads, not data already copied. Re-encryption is possible only for controlled archives where keys, recipient mappings and legal authority remain. Backups, replicas, databases, queues, telemetry and third-party archives are inside the risk boundary.
3. Paladin is not an end-to-end post-quantum privacy stack
Paladin is a modular EVM privacy sidecar; the base ledger still orders and finalizes transactions. It therefore does not replace Besu transaction authentication, validator consensus, node identity, RLPx or finality.
Its domains require separate assessment: Pente provides private EVM execution, Noto notary-backed flows and Zeto zero-knowledge token implementations. Public materials do not define an end-to-end NIST-standardized profile for every authorization, endorsement, data-distribution and communications path.
The public Zeto stack includes Circom, BabyJubjub and Groth16 verifier contracts. BabyJubjub and pairing-based Groth16 verification are classical elliptic-curve systems, not NIST PQ standards. An isolated encrypted component therefore does not secure ownership, proofs, endorsements, finality, transport, vaults, backups or recovery end to end.
4. Encryption does not eliminate metadata exposure
Encryption may still expose timing, frequency, gas-payer activity, commitments, access patterns and links between public and private state. PQ encryption protects content, not metadata, governance or authorization.
What an Institutional Besu Privacy Migration Must Cover
| Privacy component | Post-quantum question | Required action |
|---|---|---|
| Legacy Tessera payloads | Were ciphertext, keys, recipient mappings or backups retained or exposed? | Inventory, classify by confidentiality horizon and re-encrypt controlled data where possible. |
| New key establishment | Does key establishment rely on Curve25519, ECDH, RSA or another vulnerable primitive? | Use a tested, crypto-agile ML-KEM path, with hybrid transition where required. |
| Paladin, Pente, Noto, and Zeto | Which primitives secure ownership, proofs, endorsements, distribution, vaults and verification? | Inventory proof systems, account signatures, secure channels, KMS and base-ledger finality; replace or isolate vulnerable dependencies. |
| KMS, HSM, backups, and recovery | Can KMS, HSM, backup and recovery systems store, rotate and audit the new keys and objects? | Validate support, certification, lifecycle, rollback and cross-participant interoperability. |
| Metadata and governance | What metadata and governance exposure remains after encryption changes? | Threat-model timing, access patterns, commitments, administration, recovery and disclosure separately. |
Institutional conclusion: replacing Tessera with Paladin changes the architecture but does not itself deliver PQ privacy. Privacy needs its own CBOM, retained-ciphertext treatment and validation of every domain and operational dependency.
Sources: DTCC, Swift, Citi, Fnality, JSCC, LACNet, the Tessera sunset, Paladin, Zeto and NIST FIPS 203.
ERC Standard Exposure on Besu
Institutional ERCs fall into four PQ categories. Some mandate classical signatures; many are cryptographically neutral but inherit the security of controlling accounts and the network.
Explicitly ECDSA-Bound Standards
| Standard | Function | PQ Severity |
|---|---|---|
| ERC-2612 (Permit) | Requires r, s, v constituting a valid secp256k1 signature from the token owner. | Critical |
| ERC-3009 (Transfer With Authorization) | Defines EIP-712 transfer authorizations commonly represented with ECDSA signature components. | Critical |
| ERC-2098 | Compact representation of a secp256k1 signature. | Critical |
| EIP-7702 | Set Code for EOAs. Authorization tuples contain y_parity, r, s. | Critical |
Inherited Exposure Through Account Control
ERC-20, ERC-721, ERC-1155, ERC-3525, ERC-4626, ERC-7540, ERC-173, ERC-1967 and ERC-7943 are not intrinsically ECDSA-bound. Exposure depends on implementation and controlling accounts; EOA-controlled deployments inherit Besu's elliptic-curve authentication.
ERC-3643: The Concentrated Exposure
ERC-3643 concentrates authority across token owners and agents, identity and claim registries, compliance, claim issuers, investor wallets and proxy administration. Compromise has role-specific consequences; a token-agent key can enable minting, burning, freezing, forced transfer and recovery.
ERC-3643 does not mandate ECDSA, but conventional Besu deployments commonly authenticate its authorization graph with elliptic-curve accounts.
PQ-Enabling Standards (Not Automatically PQ-Safe)
ERC-1271, ERC-4337 and ERC-7913 can support alternative application-layer verification. They do not migrate validators, native transactions, node identities, privacy or networking.
EIP-7932, EIP-8051, EIP-8052, EIP-8164, EIP-8197 and EIP-8202 propose secondary, PQ or scheme-agile authorization. As of August 2026, none is an established mainline Besu production capability.
Besu Performance Under Post-Quantum Signatures: An Illustrative Model
PQ performance depends on scheme, implementation, hardware, workload, validators, block period and topology. These are EternaX scenario calculations, not measured production Besu limits.
Signature Size, TPS Retained, and Percentage Throughput Loss
| Scheme | Pubkey | Signature | Verification | TPS Range | TPS Retained | TPS Loss vs 1,000 Baseline |
|---|---|---|---|---|---|---|
| secp256k1 ECDSA (current) | 33 B | 65 B | ~0.1 ms | 1,000 (baseline) | 100% | 0% |
| ML-DSA-44 (Dilithium2) | 1,312 B | 2,420 B | ~0.5 ms | ~600 to 800 | 60% to 80% | 20% to 40% |
| ML-DSA-65 (Dilithium3) | 1,952 B | 3,309 B | ~0.7 ms | ~450 to 650 | 45% to 65% | 35% to 55% |
| Falcon-512 (future FN-DSA) | 896-897 B | 666 B | ~0.1 ms | ~700 to 900 | 70% to 90% | 10% to 30% |
| SLH-DSA-128s | 32 B | 7,856 B | ~3.6 ms | ~30 to 250 | 3% to 25% | 75% to 97% |
| SLH-DSA-192s | 48 B | 16,224 B | ~5.5 ms | ~15 to 150 | 1.5% to 15% | 85% to 98.5% |
| SLH-DSA-128f | 32 B | 17,088 B | ~7 to 8 ms | ~10 to 100 | 1% to 10% | 90% to 99% |
Illustrative throughput loss: at a 1,000 TPS baseline, SLH-DSA-128s loses approximately 75%–97%, SLH-DSA-192s 85%–98.5%, ML-DSA-44 20%–40%, and ML-DSA-65 35%–55%. Results vary by implementation and deployment.
Illustrative Block-Level Impact at 1,000 TPS (6-Second Blocks)
| Metric | ECDSA (Current) | SLH-DSA-128s | SLH-DSA-192s |
|---|---|---|---|
| Signature data per block (6,000 tx) | 390 KB | 47 MB | 97 MB |
| Total block size | ~1.5 MB | ~48-50 MB | ~100 MB |
| CPU verification (single core) | 0.6 seconds | 21.6 seconds | 33 seconds |
| CPU verification (8 cores parallel) | 0.08 seconds | ~2.7 seconds | ~4.1 seconds |
| Daily signature storage | 5.6 GB | 678 GB | 1.4 TB |
Illustrative Network-Profile TPS Scenarios and Percentage Loss
| Deployment Profile | Baseline TPS | SLH-DSA-128s TPS | 128s TPS Loss | SLH-DSA-192s TPS | 192s TPS Loss |
|---|---|---|---|---|---|
| Well-tuned QBFT, 8-core validators, LAN | 1,000 | ~150 to 250 | 75% to 85% | ~80 to 150 | 85% to 92% |
| Multi-jurisdiction WAN validator network | 1,000 | ~30 to 80 | 92% to 97% | ~15 to 40 | 96% to 98.5% |
| High-volume permissioned payment network | 500 to 1,000 | ~50 to 150 | 70% to 95% range envelope |
~25 to 80 | 84% to 97.5% range envelope |
| L2 sequencer-style workload | 5 to 15 (assumed) | ~1 to 3 | ~80% at matched endpoints broad envelope 40% to 93% |
Sub-1 | >80% to >93% depending on baseline and sub-1 result |
Loss equals (baseline TPS − PQ TPS) / baseline TPS. Range rows show the arithmetic envelope, not a benchmark confidence interval.
Bandwidth may bind before CPU. A 48 MB block takes roughly 3.8 seconds to transmit at 100 Mbps or 0.4 seconds at 1 Gbps before overhead, fanout, latency and consensus messaging. Deployment benchmarks remain essential.
Additional Operational Constraints
Gas repricing: SLH-DSA verification would require materially higher pricing than ecRecover under these assumptions; final pricing needs client benchmarks, worst-case analysis and governance.
Signing latency: software and HSM results vary by library, hardware, parameter set and concurrency. Capacity planning must use the exact production configuration.
Archive storage: at 1,000 TPS, signatures alone imply about 678 GB/day for SLH-DSA-128s versus 5.6 GB/day for 65-byte ECDSA, excluding framing, receipts, state, database overhead, compression and pruning.
Performance is one constraint within the wider 48-point exposure map.
The Full Besu Post-Quantum Exposure Map: 48 Control Points
A complete Besu migration can span accounts, consensus, network infrastructure, EVM contracts, interoperability, confidentiality and governance. The 48 points below are an engineering inventory, not 48 independent attacks.
Accounts and Transactions (9 exposure points)
secp256k1 externally owned accounts, public-key hiding providing only temporary protection, harvest-now-forge-later transaction records, mempool key-extraction race conditions, contract wallets that ultimately trust ECDSA, token issuer/mint/burn/freeze keys, custodian and participant wallet keys, permit and meta-transaction delegated-authority signatures, and old approvals remaining exploitable after account migration.
Consensus (7 exposure points)
QBFT/IBFT validator signatures, Byzantine threshold collapse from quantum key recovery, forged block proposer identity, forged historical consensus evidence, long-range or offline-node deception, validator onboarding and voting key compromise, and consensus DoS from PQ signature overhead.
Network Infrastructure (6 exposure points)
Node identity keys and peer authentication, local and on-chain permissioning identities, TLS for RPC and peer gateways, remote-signing services and institutional PKI, certificate authorities, JSON-RPC administrator authentication, and DNS or software-update signing.
EVM and Smart Contracts (7 exposure points)
ecRecover precompile, fixed 20-byte address model, PQ verification implemented only in Solidity (expensive and error-prone), upgrade keys and proxy administrators, oracles and off-chain attestations, zero-knowledge proofs based on elliptic curves (Groth16, PLONK, KZG), and trusted setup or proof-verifier immutability.
Cross-Chain and Interoperability (5 exposure points)
Bridge and interoperability committee signatures, Chainlink CCIP or similar external trust dependencies, ISO 20022 and off-chain instruction signatures, destination-chain weakness, and cross-chain replay during algorithm migration.
Data Confidentiality (4 exposure points)
Harvest-now-decrypt-later of network traffic, encrypted private payloads and off-chain storage, backups and disaster-recovery archives, and privacy leakage from public ledger data.
Governance and Operations (10 exposure points)
Governance authorization, emergency recovery controlled by classical keys, cryptographic downgrade during hybrid deployment, PQ algorithm monoculture, PQ implementation defects, HSM and key-management incompatibility, legal non-repudiation erosion, asset and contract immobility, scalability failure from PQ overhead, and incomplete vendor and dependency migration.
The scope exceeds any one wallet, validator or privacy component and requires coordinated ownership.
Why Besu Still Lacks an End-to-End Post-Quantum Migration Path
The 48-point map is a coordination problem as much as a cryptographic one. Besu is open source, while institutions operate different releases, plugins, managed services, custody systems, privacy designs and governance models. No single actor controls every dependency.
Why a Shared Migration Profile Is Missing
Interoperability Expands the Boundary
Swift, DTCC, Fnality and other infrastructures connect ledgers, settlement, messaging, identity, oracles and destination chains. Each authorization or verification boundary adds another cryptographic dependency.
NIST standardized ML-KEM, ML-DSA and SLH-DSA in 2024, but mainline Besu still lacks a built-in migration covering all five surfaces.
Make Critical Besu Workflows Post-Quantum Safe Without Rebuilding Your Stack
Institutions should not need to abandon Besu, rewrite compatible applications, move asset records or replace custody to address PQ risk. EternaX upgrades selected authorization and confidentiality paths while preserving compatible contracts, assets, APIs, integrations, governance and workflows.
The goal is not one PQ signature before an otherwise vulnerable stack. It is to secure a selected workflow, including issuance, approval, transfer, recovery, administration, disclosure and settlement, while isolating native Besu changes for a coordinated phase.
The operating principle: upgrade the trust boundary, not the business workflow
EternaX maps one priority workflow and defines its lowest-friction protection boundary. Compatible components stay; exposed authorization, identity, custody, privacy and verification controls are upgraded, wrapped or re-authorized. Protocol-native dependencies are governed separately.
EternaX Post-Quantum Protection for Hyperledger Besu
Institutions can start with tokenization, custody or privacy, then map remaining native Besu dependencies into a controlled network-level plan.
| EternaX product | What it makes post-quantum safe | What the institution can preserve |
|---|---|---|
| EternaX Post-Quantum Tokenization for Besu | Issuer and token-agent authority; mint, burn, freeze, recovery and upgrade controls; identity, eligibility, permits, vault governance and privileged contract actions. | Compatible contracts and ERC interfaces, asset and investor records, issuance, transfers, compliance, APIs, reporting and execution environment. |
| EternaX Post-Quantum Custody Hardening for Besu | Custody and treasury approvals, distributed authorization, recovery, policy administration and asset-movement gates. | The appointed custodian, MPC/HSM environment, supported Safe controls, treasury process, approval hierarchy and operating model. EternaX is not a custody provider. |
| EternaX Post-Quantum Privacy Manager for Besu | Private-payload key establishment and encryption, group authority, membership and rotation, distribution, recovery, regulatory access and PQ peer authentication. | The Besu node-plus-sidecar pattern, supported privacy interfaces, private contracts, participant governance and confidentiality workflows. |
Live Technical Proof: Post-Quantum Distributed Custody Authorization
EternaX's live Pluto testnet demo implements a dual-gate custody model. Gate 1 uses post-quantum member signatures to authenticate each approval. Gate 2 separately enforces that the required threshold authorized the same operation. Assets move only when both gates pass.
This preserves distributed MPC-style approval without claiming a threshold SLH-DSA signature or replacing the custodian. It applies where the Besu asset-control path can enforce programmable verification, such as a smart account, vault, issuer module, bridge controller or HSM-controlled execution gate. Native Besu transactions, QBFT, node identity and RLPx remain outside the demo's protection boundary. Try dual-gate custody on the live testnet. Review the institutional custody architecture.
Shared capability: crypto agility. A signature-agnostic model lets approved algorithms, parameters, providers and policies change without rebuilding the protected workflow. Policy can vary by asset, role, transaction type, jurisdiction, performance and assurance horizon, with downgrade controls.
Scope boundary: these products harden workflows around an existing Besu deployment. Classical native transactions, QBFT signatures, node identity and RLPx remain separately mapped and require the relevant client, validator or network phase.
Example: An Existing ERC-3643 Asset on Besu
A regulated ERC-3643 asset can retain compatible contracts, identity structures, records, transfer rules, reporting, custody and operations. EternaX can move issuer, agent, compliance, claim, custody, recovery and other privileged actions behind PQ authorization, including PQ-ONCHAINID-compatible controls. Immutable verification and native Besu dependencies remain a separate wrapper, upgrade or network phase.
Why This Migration Path Is Credible
Current technical status: Pluto validates PQ verification precompiles, PQ-ONCHAINID for ERC-3643-compatible identity and PQ privacy capabilities. Production still requires workflow integration, HSM/KMS validation, governance, interoperability, assurance and performance testing, with migration state evidenced across keys, roles, contracts, providers, validators and residual dependencies.
Prove the Migration Path Before Production Change
A pilot starts with one tokenization, custody or privacy workflow and turns the assessment into an institution-specific migration path.
| Phase | What happens | Institutional output |
|---|---|---|
| 1. Scope | Map contracts, roles, custody approvals, privacy, HSM/KMS, interoperability and relevant QBFT or node dependencies. | Dependency map, exposure assessment and lowest-friction protection boundary. |
| 2. Build | Apply the relevant Besu product while preserving compatible contracts, records, APIs, providers and operations. | Working testnet path separating controls protectable now from wrapper, upgrade or network phases. |
| 3. Evaluate | Measure authorization, privacy, throughput, finality, audit, compliance, HSM/KMS, interoperability and operational effort. | Measured results and phased production blueprint for integration, governance, assurance and remaining dependencies. |
Pilot outcome: a working path, measured integration and performance evidence, and a production roadmap before new contracts, validator settings, custody or interoperability dependencies increase migration debt. Review the pilot framework.
Continue the Technical Review
EternaX research: Institutional Risk Framework, Exposure Map 2026, Signature Ranking 2026 and tokenization architecture.
Evaluate a Live Besu Post-Quantum Protection Path
Start with the live dual-gate custody authorization demo, or select one tokenization, custody or privacy workflow for an institution-specific pilot. EternaX will map the dependencies, preserve compatible components, measure the protection path and produce a phased production blueprint.
Hyperledger Besu Post-Quantum Security FAQ
Direct answers to high-intent institutional questions about Hyperledger Besu quantum risk, QBFT, Tessera, Paladin, institutional privacy architectures, DTCC tokenization, NIST post-quantum standards, crypto agility, migration performance, and EternaX's Besu-specific tokenization, custody, and privacy products.
Is Hyperledger Besu quantum-safe?
ecRecover in many smart contracts, and elliptic-curve node identity and key agreement in devp2p/RLPx. These public-key dependencies are vulnerable to Shor's algorithm. See the five attack surfaces.Why is Hyperledger Besu vulnerable to quantum computers?
Which institutions and financial-market systems use Hyperledger Besu?
Is DTCC's tokenization architecture across Besu, Canton and Stellar post-quantum safe?
Is Besu QBFT consensus quantum-safe?
Is Besu privacy with Tessera quantum-safe?
Which privacy technologies do major Hyperledger Besu deployments use today?
Does Paladin make Besu post-quantum safe?
Does Besu support ML-DSA, SLH-DSA, or ML-KEM?
Can Besu simply adopt NIST-approved post-quantum algorithms?
ecRecover, node identity and RLPx transport, custody, HSM/KMS systems, privileged roles, recovery, and coordinated activation. Crypto agility is also required so the next algorithm, parameter, or provider change does not become another full-stack rebuild. See what a credible Besu migration must deliver.What does crypto agility mean for a Hyperledger Besu deployment?
Can existing Besu smart contracts remain in place during migration?
ecRecover, ECDSA permits, immutable classical-key authorities, non-upgradeable verifiers, or fixed address assumptions may need an upgrade, wrapper, compatibility layer, or replacement. See the smart-contract and ERC analysis.