Question 1

Is Hyperledger Besu post-quantum safe today?

Accepted Answer

No. A standard Hyperledger Besu deployment should not be described as post-quantum safe today. Besu does not natively use the NIST PQC standards FIPS 203 , FIPS 204 , or FIPS 205 for standard Ethereum transaction authorization or permissioned-network validator signing. Besu therefore requires an explicit post-quantum migration design for the cryptographic surfaces that an institution needs to protect.

Question 2

How does EternaX make Hyperledger Besu post-quantum safe?

Accepted Answer

EternaX provides a layered post-quantum architecture for Hyperledger Besu. For existing networks, EternaX can add post-quantum privacy, tokenization authorization, and custody approval controls without replacing the live Besu network. For greenfield deployments, EternaX PQ-Safe Ledger extends the protection boundary into validator authentication, P2P communication, native transaction authorization, and privacy from genesis. Each deployment documents exactly which surfaces are protected and which residual dependencies remain.

Question 3

Can EternaX make an existing Besu deployment post-quantum safe without replatforming?

Accepted Answer

Yes, across defined protection layers. EternaX can add post-quantum privacy, tokenization authorization, and custody approval controls while preserving the existing Besu deployment and, where required, the existing custody provider. Unchanged native consensus, P2P identity, and outer transaction authorization remain outside that retrofit boundary. Full native-network protection is addressed separately through EternaX PQ-Safe Ledger for greenfield deployments.

Question 4

What is post-quantum cryptography for Hyperledger Besu?

Accepted Answer

Post-quantum cryptography (PQC) for Hyperledger Besu means protecting the public-key cryptographic functions that could be broken by a cryptographically relevant quantum computer. For an institutional Besu deployment, that can include transaction authorization, validator authentication, P2P identity, private-payload protection, tokenization controls, and external custody workflows. A credible migration defines the protection boundary layer by layer rather than calling the entire network PQ-safe after changing only one component.

Question 5

Which parts of a Hyperledger Besu network can have quantum exposure?

Accepted Answer

The main surfaces are transaction and account authorization; QBFT or IBFT validator authentication; P2P node identity and secure transport; private-payload confidentiality and sender authentication; tokenization controls such as issuer, compliance, permit, and vault authority; and external MPC, HSM, wallet, bridge, oracle, or custody dependencies. EternaX maps these surfaces independently so institutions can see what is protected, what remains exposed, and what can be migrated without replatforming.

Question 6

What makes EternaX different from other post-quantum approaches for Hyperledger Besu?

Accepted Answer

The differentiation is architectural. EternaX separates retrofit protection for live Besu networks from full-stack greenfield protection, and treats privacy, tokenization, custody authorization, consensus, P2P, and transaction authorization as distinct security boundaries. The architecture is designed for crypto-agility and explicitly documents residual non-PQ dependencies instead of describing a partially hardened network as fully post-quantum safe. This allows institutions to phase migration without losing technical precision.

Question 7

What is the difference between EternaX PQ Privacy Overlay and EternaX PQ-Safe Ledger?

Accepted Answer

EternaX PQ Privacy Overlay is for existing live Besu networks that need post-quantum privacy without changing consensus. EternaX PQ-Safe Ledger is for greenfield deployments that want post-quantum controls across native network layers from genesis. The overlay deliberately leaves unchanged Besu consensus, P2P identity, and outer transaction authorization outside its boundary; PQ-Safe Ledger is designed to move the protection boundary down into those native layers.

Question 8

Which post-quantum algorithms does EternaX use for Hyperledger Besu?

Accepted Answer

EternaX's current Besu design uses ML-KEM-768 for post-quantum key establishment and AES-256-GCM for symmetric authenticated encryption, with SLH-DSA as the conservative signature path and ML-DSA-65 as an operational alternative where appropriate. ML-KEM is standardized in NIST FIPS 203 , ML-DSA in FIPS 204 , and SLH-DSA in FIPS 205 . The exact suite depends on the layer, deployment profile, performance target, and institutional policy.

Question 9

What is crypto-agility according to NIST, and why does it matter for Besu?

Accepted Answer

NIST CSWP 39upd1 defines crypto-agility as the capabilities needed to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. For Besu, this matters because PQ migration should not create a new permanent algorithm dependency. EternaX is designed to version and govern cryptographic suites so supported algorithms can be introduced, overlapped, retired, or retained for historical verification within the relevant protection boundary.

Question 10

Is QBFT consensus in Hyperledger Besu post-quantum safe?

Accepted Answer

Not by default. Besu QBFT is a proof-of-authority consensus protocol in which a super-majority of validators sign a block before it is inserted into the chain. The standard QBFT path is not natively based on NIST post-quantum digital-signature standards. See the official Besu QBFT documentation . EternaX treats validator authentication as a separate migration surface rather than assuming that application-layer PQC makes consensus post-quantum safe.

Question 11

Is IBFT 2.0 in Hyperledger Besu post-quantum safe?

Accepted Answer

Not by default. IBFT 2.0 is a Byzantine-fault-tolerant permissioned consensus mode whose standard validator authentication is not natively implemented with NIST-standardized post-quantum signatures. An institution using IBFT 2.0 should therefore treat validator authorization as its own PQ migration surface. Privacy, tokenization, or custody hardening above the consensus layer does not by itself make IBFT 2.0 post-quantum safe.

Question 12

What is harvest-now-decrypt-later risk for Besu private transactions?

Accepted Answer

Harvest-now-decrypt-later (HNDL) is the risk that an adversary records encrypted data today and decrypts it later if the public-key mechanism used to protect key establishment becomes breakable by a future quantum computer. For long-lived confidential financial data, historical confidentiality can therefore matter before a cryptographically relevant quantum computer exists. EternaX assesses HNDL exposure separately from future signature-forgery risk because the remediation paths are different.

Question 13

What happened to Tessera privacy in Hyperledger Besu?

Accepted Answer

Tessera privacy was deprecated and removed from the mainline Besu codebase. LF Decentralized Trust announced the sunset plan in 2024, and the Besu maintainers stated in February 2026 that Privacy/Tessera removal was complete, including the EEA and PRIV RPC methods. See the Tessera sunset announcement and the 2026 Besu maintainer update . EternaX treats historical Tessera data and migration compatibility as explicit assessment items.

Question 14

Is Paladin or Pente a post-quantum replacement for Tessera?

Accepted Answer

Paladin and Pente should not by themselves be treated as an end-to-end post-quantum migration for Besu. They address application-layer privacy and tokenization use cases, while native Besu consensus, P2P identity, transaction authorization, historical encrypted data, and external custody dependencies remain separate cryptographic surfaces. EternaX therefore evaluates the actual protection boundary component by component rather than assuming that replacing Tessera automatically makes the surrounding network post-quantum safe.

Question 15

What is the EternaX PQ Privacy Overlay for Hyperledger Besu?

Accepted Answer

EternaX PQ Privacy Overlay is a retrofit privacy layer for existing Besu networks. It adds post-quantum key establishment, private-payload encryption, sender authentication, privacy-group governance, private execution, availability, recovery, and migration controls alongside the existing Besu node. The design preserves the existing consensus layer and explicitly documents that native consensus, P2P identity, and outer transaction authorization remain outside the overlay's protection boundary.

Question 16

Does the EternaX PQ Privacy Overlay require changing Besu consensus?

Accepted Answer

No. The native overlay profile runs alongside an existing Besu deployment through standard JSON-RPC plus an on-chain anchor contract. Existing QBFT or IBFT 2.0 consensus can remain in place, and validators that do not participate in a privacy group do not need the privacy node. This is a post-quantum privacy upgrade, not a claim that unchanged Besu consensus becomes post-quantum safe.

Question 17

Does the EternaX PQ Privacy Overlay require a Hyperledger Besu binary fork?

Accepted Answer

No for the native overlay profile. It does not require modifying the Besu binary, creating a Besu client fork, or replacing the live validator set. Standard JSON-RPC and ordinary EVM transactions are used for integration. Optional deeper integrations can be evaluated separately when an institution requires additional validator-side enforcement.

Question 18

Does the PQ Privacy Overlay make QBFT, P2P, and native Besu transaction signing post-quantum safe?

Accepted Answer

No. EternaX PQ Privacy Overlay protects the defined privacy and private-authorization boundary while leaving existing Besu consensus, native P2P identity, and outer transaction authorization unchanged. Those residual dependencies remain visible in the security documentation. EternaX PQ-Safe Ledger is the separate greenfield path designed to address those native network layers.

Question 19

Can EternaX protect historical Tessera-encrypted transactions?

Accepted Answer

EternaX PQ Privacy Overlay protects new traffic from the point at which the PQ path is enforced. Historical protection is a separate migration problem. Where archived private payloads are available and the institution controls the required keys and data, a re-encryption or rewrapping program can be evaluated. The resulting coverage should state exactly which historical range has been remediated and which range remains dependent on the original cryptography.

Question 20

Can EternaX make tokenization on a Besu network post-quantum safe?

Accepted Answer

EternaX can add post-quantum authorization controls to tokenization workflows running on Besu, including issuer authority, compliance claims, permit approvals, and vault governance. EternaX modules include PQ Vault, PQ-ONCHAINID, PQ-Permit, and PQ-4626. These modules protect the application-layer authorization paths they enforce; they do not automatically make unchanged Besu consensus or every external dependency post-quantum safe. See Post-Quantum Stablecoins & Tokenization .

Question 21

Can EternaX make MPC or HSM custody workflows for Besu post-quantum safe?

Accepted Answer

EternaX PQ Custody SDK is designed to add a post-quantum authorization gate around existing custody, MPC, and HSM workflows rather than replace the custody provider. The EternaX-enforced approval path becomes a separately defined protection boundary, while the underlying provider, wallet, transaction, and network dependencies are assessed independently. See Post-Quantum Custody & MPC Providers .

Question 22

Is EternaX a custody provider?

Accepted Answer

No. EternaX is not a custody provider. EternaX PQ Custody SDK adds a post-quantum authorization layer around existing MPC, HSM, and institutional custody workflows. An institution can retain its custody provider and operating model while adding a separately enforced PQ approval boundary. Provider-specific integration requirements still depend on the custody interface and deployment. See Post-Quantum Custody & MPC Providers .

Question 23

Does EternaX post-quantum infrastructure for Besu require EternaX Chain?

Accepted Answer

No. EternaX Besu products are designed to deploy on Besu networks independently of EternaX Chain. An institution can evaluate PQ Privacy Overlay, tokenization modules, PQ Custody SDK, or PQ-Safe Ledger without migrating its application to EternaX Chain. EternaX Chain is a separate post-quantum settlement network for cross-institution use cases.

Question 24

What is the EternaX PQ-Safe Ledger for Hyperledger Besu?

Accepted Answer

EternaX PQ-Safe Ledger is the greenfield Besu-compatible deployment path based on the open-source Besu codebase, with post-quantum controls designed into the network from genesis. The architecture targets PQ validator authentication, PQ P2P identity and communication, PQ transaction authorization, PQ verification precompiles, and integrated PQ privacy. It is intended for institutions that want the native network protection boundary to be post-quantum by design rather than retrofitted layer by layer later.

Question 25

Does EternaX PQ-Safe Ledger preserve EVM and Solidity compatibility?

Accepted Answer

The design objective is EVM and Solidity compatibility so that application business logic does not need to be rewritten solely because the underlying authorization and network cryptography changes. Integration testing is still required for wallets, SDKs, precompiles, signature assumptions, and any smart-contract logic that explicitly depends on Ethereum ECDSA semantics such as ecrecover . EternaX treats those dependencies as migration surfaces rather than hiding them behind a generic compatibility claim.

Question 26

Can EternaX rotate post-quantum algorithms without a Besu hard fork?

Accepted Answer

Within the EternaX-controlled protection boundary, that is the design goal. Algorithms and cryptographic suites are represented through governed, versioned components so supported schemes can be activated, overlapped, retired, or retained for historical verification without redesigning the whole application each time. Whether a specific change requires a network upgrade still depends on the layer being changed and the deployment profile. EternaX does not claim that an unchanged Besu client can rotate native consensus cryptography by configuration alone.

Question 27

Why not migrate Besu to one post-quantum algorithm and stop?

Accepted Answer

Because long-lived financial infrastructure has to survive future algorithm transitions as well as the first PQ migration. NIST crypto-agility guidance focuses on the ability to replace and adapt cryptography while preserving security and ongoing operations. EternaX therefore treats PQC plus governed algorithm agility, explicit versioning, transition modes, and historical verification as the stronger institutional design target rather than embedding one new algorithm as another permanent dependency.

Question 28

Which institutional Besu deployments can EternaX assess for post-quantum exposure?

Accepted Answer

Institutional initiatives named on this page include DTCC AppChain, SWIFT Shared Ledger, Fnality, Citi CIDAP, BIS Project Agora, mBridge, and eNaira. Their architectures and cryptographic boundaries are not assumed to be identical. EternaX assesses each deployment surface by surface across privacy, sender authentication, tokenization controls, validator or consensus authentication, P2P identity, and custody or key management, then identifies the exact residual exposure and the appropriate retrofit or greenfield remediation path.

Question 29

Can Fireblocks, Taurus, BitGo, DFNS, Zodia Custody, or Anchorage Digital workflows be post-quantum hardened for Besu?

Accepted Answer

EternaX PQ Custody SDK is designed to add a post-quantum approval boundary around existing institutional custody and MPC workflows, including integrations with providers such as Fireblocks, Taurus, BitGo, DFNS, Zodia Custody, and Anchorage Digital. The custodian remains in place. EternaX adds the PQ authorization layer on top, while exact integration requirements depend on the provider interfaces, signing workflow, and deployment. See Post-Quantum Custody & MPC Providers .

Question 30

Why should a bank designing a new permissioned tokenization ledger consider PQC and crypto-agility from day one?

Accepted Answer

A bank may use an internal permissioned ledger to maintain governance, privacy, data control, operational authority, and regulatory separation for tokenized deposits, securities, funds, or internal settlement workflows. If Besu or another EVM-compatible permissioned architecture is selected, designing post-quantum protection and crypto-agility at inception can avoid creating another cryptographic migration dependency later. EternaX PQ-Safe Ledger is the greenfield path for institutions that want that protection boundary from genesis.

Question 31

Which NIST post-quantum cryptography standards are most relevant to Besu migration?

Accepted Answer

The core finalized NIST PQC standards are FIPS 203 for ML-KEM key establishment, FIPS 204 for ML-DSA digital signatures, and FIPS 205 for SLH-DSA hash-based digital signatures. Which algorithm belongs at each Besu layer depends on the security function, performance target, implementation boundary, and applicable validation or policy requirements. EternaX maps the algorithm to the function rather than treating one PQ scheme as the answer to every layer.

Question 32

What is ERC-3643 and why can a Besu ERC-3643 deployment still have quantum exposure?

Accepted Answer

ERC-3643 is a permissioned token standard used for regulated tokenization on EVM-compatible networks. A Besu deployment can still depend on quantum-vulnerable authorization around issuer or administrator accounts, identity and claim signatures, wallet approvals, permit-style authorization, custody, or governance. Those paths must be assessed individually. EternaX targets these application-layer authorization surfaces through PQ-ONCHAINID, PQ-Permit, PQ-4626, and PQ Vault. See Post-Quantum Stablecoins & Tokenization .

Question 33

What is a Cryptographic Bill of Materials (CBOM) for a Hyperledger Besu deployment?

Accepted Answer

A CBOM is a structured inventory of the cryptographic algorithms, key types, certificate chains, libraries, protocol dependencies, and implementation locations used across a system. For Besu, that means mapping cryptography across transaction authorization, consensus, P2P, privacy, tokenization, and custody. Executive Order 14412 directs CISA, in coordination with NIST, to release guidance on minimum CBOM elements. EternaX produces CBOM-ready documentation as part of the Besu readiness assessment.

Question 34

What is SLH-DSA and why does EternaX use it for Besu?

Accepted Answer

SLH-DSA is the stateless hash-based digital signature algorithm standardized in NIST FIPS 205 . Its security foundation is hash-based rather than lattice-based. EternaX uses SLH-DSA as a conservative root-signature path where that security and performance trade-off is appropriate, while retaining crypto-agility for other approved schemes and future transitions. EternaX does not treat one signature algorithm as universally optimal for every Besu workload.

Question 35

How does Executive Order 14412 affect Hyperledger Besu infrastructure?

Accepted Answer

Executive Order 14412 , signed June 22, 2026, directs OMB guidance requiring federal agencies to transition High Value Assets and high-impact systems, excluding National Security Systems, to PQC for key establishment by December 31, 2030 and digital signatures by December 31, 2031. Besu used inside an affected federal system therefore needs a mapped migration path across the cryptographic functions actually in scope. The order also directs support for critical-infrastructure PQC planning.

Question 36

How does Executive Order 14412 affect federal contractors using Hyperledger Besu?

Accepted Answer

Executive Order 14412 directs the FAR Council to publish a proposed rule requiring covered contractors to comply by December 31, 2030 with NIST FIPS, including applicable FIPS incorporating PQC-compliant algorithms. A contractor should not assume that every Besu deployment is automatically covered; applicability depends on the proposed and final FAR rule, contract scope, system boundary, and agency requirements. EternaX readiness work can map the technical cryptographic boundary that would need to be assessed.

Question 37

Do the EO 14412 deadlines automatically apply to every bank or private Besu network?

Accepted Answer

No. EO 14412 does not automatically make every private bank, market infrastructure, or private Besu network subject to the federal 2030 and 2031 HVA deadlines. Private-sector applicability can instead arise through federal procurement, covered-contractor rules, contracts, sector regulation, counterparties, critical-infrastructure guidance, or internal risk policy. EternaX therefore separates technical PQ readiness from the institution's legal determination of scope.

Question 38

Does adding post-quantum cryptography automatically make a Besu deployment compliant?

Accepted Answer

No. PQC is a technical control, not a complete compliance determination. Compliance can depend on system scope, approved algorithms and modules, implementation assurance, key management, cryptographic inventory, transition planning, procurement obligations, testing, audit evidence, and the exact legal or contractual regime. EternaX can define and enforce a technical PQ protection boundary and produce readiness evidence, while the institution remains responsible for legal, regulatory, and certification determinations.

Question 39

What should an institution inventory before migrating a Besu network to post-quantum cryptography?

Accepted Answer

At minimum: Besu and client versions; consensus mode; validator and transaction-signing keys; P2P identity and transport; Tessera or Paladin dependencies; privacy groups; encrypted historical data; token contracts and privileged roles; ecrecover and permit assumptions; wallets, bridges, oracles, HSMs, MPC and custody providers; cryptographic libraries; data-retention horizons; and every route that could bypass the intended PQ authorization path. EternaX turns that inventory into an explicit protection boundary and phased remediation plan.

Question 40

What does the EternaX Besu post-quantum readiness assessment deliver?

Accepted Answer

The assessment maps the Besu cryptographic attack surface and the institution's actual dependencies, then defines a deployable protection boundary. Deliverables can include privacy and HNDL exposure mapping, consensus and P2P dependency analysis, custody and tokenization review, cryptographic inventory or CBOM inputs, compatibility validation, residual-risk documentation, target PQ suites, and a phased integration and evidence roadmap. The objective is a technically defensible migration plan, not a generic PQC checklist.

Question 41

Should an institution choose EternaX PQ Privacy Overlay or EternaX PQ-Safe Ledger?

Accepted Answer

For a live Besu network where changing consensus or the client is not practical, start with PQ Privacy Overlay and separately harden tokenization and custody authorization as required. For a new permissioned network where the institution controls genesis and wants the native network protection boundary to be post-quantum from day one, evaluate PQ-Safe Ledger. The decision is therefore retrofit compatibility versus greenfield full-stack control, not simply one product being stronger than the other.

Question 42

How long does an EternaX Besu post-quantum pilot take?

Accepted Answer

The EternaX readiness assessment and initial pilot profile is designed as a 90-day engagement. It can include exposure mapping, compatibility validation, deployment of a bounded privacy group or tokenization module under controlled conditions, and production of the phased integration roadmap. The exact timeline depends on the institution's Besu configuration, privacy-group complexity, tokenization contracts, custody integrations, security review, and regulatory requirements.

Migration surface	Current dependency	Quantum exposure	EternaX product	Coverage
Private payload confidentiality	Tessera (deprecated) / Paladin BN254	All historical private txns subject to HNDL	PQ Privacy Overlay	ML-KEM-768 + AES-256-GCM
Private sender authentication	ECDSA / EdDSA	Forgery under Shor's algorithm	PQ Privacy Overlay	SLH-DSA / ML-DSA-65
Tokenization controls	ECDSA admin keys, ecrecover claims, ERC-2612 permits	Issuer forgery, compliance bypass, unauthorized mint/burn	PQ Vault, PQ-ONCHAINID, PQ-Permit, PQ-4626	SLH-DSA application-layer enforcement
Consensus & validator signatures	QBFT/IBFT ECDSA/BLS	Validator impersonation, block forgery	PQ-Safe Ledger	QBFT with SLH-DSA
P2P and node communication	devp2p classical keys	Node impersonation, network partition	PQ-Safe Ledger	PQ P2P
Custody and key management	MPC/HSM ECDSA threshold	Key derivation under Shor's algorithm	PQ Custody SDK	Dual-gate construction

PQ-ONCHAINID	PQ-safe compliance claims validation. SLH-DSA claim issuance via precompile. Identity Registry, Trusted Issuers Registry, Claim Topics Registry unchanged in shape.
PQ Vault	PQ-safe vault governance. EIP-4337 account abstraction with SLH-DSA verification for institutional vault controls.
PQ-Permit	PQ-safe gasless approvals. Replaces ERC-2612 ECDSA permits with SLH-DSA permit signatures.
PQ-4626	PQ-safe tokenized vault standard. Deposit, withdraw, and governance authority protected by SLH-DSA.

Gate 1: PQ authentication	Each party authenticates with SLH-DSA-SHAKE-128s (FIPS 205) before any signing operation proceeds.
Gate 2: Threshold authorization	Affine secret sharing over a prime field. Resolves the impossibility result on threshold hash-based signatures.
Provider preserved	Fireblocks, Taurus, BitGo, DFNS, or any MPC/HSM provider remains in place. EternaX adds the PQ approval gate on top.
Signature-agnostic	Works regardless of the custodian's internal signing scheme. No custodian code change required.

PQ payload encryption	ML-KEM-768 key establishment + AES-256-GCM
PQ sender authentication	SLH-DSA-SHAKE-128s (conservative) / ML-DSA-65 (operational)
Privacy group governance	Dynamic membership, epoch keys, compartmentalized blast radius
Private execution	Deterministic EternaX Private Execution Engine (pinned EVM)
Data availability	Signed overlay receipts; retrievability challenges
Regulatory observation	Group-bound policies, scoped credentials, threshold controls
Recovery	Availability receipts, archives, snapshots, certified recovery
Tessera migration	Version-specific adapters, dual-read, workflow-by-workflow
Crypto-agility	Full-stack governed rotation (see below)

Profile	Target environment	Consensus change
A: Native Overlay	Any existing Besu. JSON-RPC + anchor contract.	No
B: Legacy Compatibility	Besu/GoQuorum with Tessera/EEA. Dual-read migration.	No
C: Middleware Adapter	FireFly, bank APIs, custody engines, compliance.	No
D: Assured Integration	Optional. Besu plugins, validator-side checks.	Optional

Make your Besu network post-quantum safe.

No other provider addresses Besu's post-quantum exposure.

Product coverage across migration surfaces

What stays in place

What EternaX adds

PQ-safe Besu stack

Why G-SIBs will need an internal permissioned ledger

Privacy, tokenization, consensus, and custody on one Besu network.

Full-stack crypto-agility. Algorithm rotation without hard fork.

Post-quantum readiness by deployment condition.

Make your Besu tokenization PQ-safe before quantum risk reprices your instruments.

Harden your existing Besu privacy layer before EO 14412 transmission arrives.

Make your Besu MPC custody PQ-safe without replacing your custodian.

Your next internal ledger should be PQ-native from genesis.

Produce a defensible PQ readiness position for your Besu infrastructure.

Reference architecture for institutional Besu PQ remediation.

From exposure map to enforced post-quantum controls.

Map.

Deploy.

Enforce.

Detailed evidence for post-quantum Besu infrastructure.

Define a deployable post-quantum protection boundary for your Besu infrastructure.

Hyperledger Besu post-quantum security and EternaX: frequently asked questions

Hyperledger Besu post-quantum security and EternaX

Existing Besu networks: privacy, Tessera, tokenization, and custody

PQ-Safe Ledger and full-stack crypto-agility

Institutional Besu deployments and integrations

NIST standards, tokenization, and cryptographic inventory

EO 14412, institutional readiness, and pilot

PQ consensus	QBFT with SLH-DSA validator signatures
PQ P2P	Post-quantum node communication and credentials
PQ transaction signing	SLH-DSA native account signatures
PQ precompiles	SLH-DSA verify (0x0404), ML-DSA-65 verify (0x0405)
PQ privacy	PQ Privacy Overlay integrated natively
EVM compatibility	Full. Existing Solidity contracts deploy without modification.
TPS under PQ	~2% loss vs. 84–90% for post-hoc migration on other chains
Crypto-agility	Full-stack governed rotation (see below)

Besu deployment layer	EternaX product	What it protects
Privacy	PQ Privacy Overlay	Private payloads, sender authentication, privacy groups, regulatory observation
Tokenization	PQ Vault, PQ-ONCHAINID, PQ-Permit, PQ-4626	Issuer authority, compliance claims, permit approvals, vault governance for ERC-3643 / ERC-4626 on Besu
Consensus & P2P	PQ-Safe Ledger	QBFT validator signatures, P2P credentials, transaction signing, precompiles
Custody	PQ Custody SDK	MPC/HSM approval workflows, dual-gate construction, signature-agnostic authorization

Chain	To rotate one algorithm	Consequence
Classical Besu	Hard fork. QBFT format change. Genesis reconfiguration.	Network-wide coordination. 84–90% TPS loss. Every rotation.
EternaX Besu products	Governance parameter change	Zero downtime. Zero breakage. Zero incremental cost.
Ethereum	Hard fork across 5 client teams	Multi-year. Breaks ecrecover, L2s, wallets
Solana	Runtime upgrade	Breaks GPU parallelization. ~90% TPS loss
Canton	Participants + Synchronizer + Chainlink DON	Full network disruption
Stellar	Protocol bump + validator vote	Breaks SDKs, wallets, anchors