What does the EternaX 30-day institutional pilot deliver?
The pilot converts post-quantum risk into a tested, institution-specific decision package. It delivers six outputs: a cryptographic inventory of every authorization and dependency that can move value or change state; a compatibility assessment for EternaX Vault, EternaX Vault for Issuers, PQ-ONCHAINID, PQ-Permit, and PQ-4626; a representative testnet deployment; a control-by-control protection boundary; a phased integration roadmap; and a crypto-agility and CBOM plan. The final recommendation identifies whether the institution should harden its existing stack, protect holdings with EternaX Vault, issue natively, or move selected settlement workflows to EternaX Chain.
Which institutions should evaluate an EternaX post-quantum pilot now?
Banks, stablecoin issuers, asset managers, fund administrators, tokenization platforms, custodians, payment networks, and settlement operators should evaluate a pilot when a classical signature can move assets or change an authoritative state. The highest-priority surfaces include mint, burn, freeze, blacklist, treasury, permit, investor eligibility, vault governance, custody release, recovery, upgrades, bridges, oracles, and validator or namespace authority. The trigger is not a provider logo or chain name; it is the continued acceptance of ECDSA, EdDSA, Schnorr, BLS, multisig, MPC, or HSM-backed classical authorization in a high-value workflow. See the
EternaX Post-Quantum Exposure Map.
Which EternaX pilot path is right for my institution?
The correct path depends on where the authoritative classical control sits. Use Tokenized Funds and RWA Issuance for issuer, compliance, permit, or ERC-4626 governance; EternaX Vault for treasury and client holdings approved by existing HSMs, MPC, or custodians; Stablecoins and Tokenized Deposits for mint, burn, freeze, blacklist, treasury, and permit authority; PQ-Native Settlement when authorization, custody, consensus, privacy, and finality must sit inside one post-quantum boundary; and Tailored PQ Migration Readiness when exposure spans several systems or the target architecture is not yet clear — including Hyperledger Besu privacy, consensus, tokenization, and custody surfaces. Institutions can combine paths around one programme. Review
EternaX Vault, the
tokenization controls,
PQ-native settlement path, and
Besu PQ infrastructure.
How long is the EternaX pilot and what does my institution need to provide?
The standard pilot runs for 30 days across Map, Build, and Validate phases. The institution provides an accountable sponsor, technical and risk owners, architecture and governance documentation, a contract or workflow inventory, and focused working sessions. EternaX provides the control modules, integration engineering, test environment, exposure analysis, protection-boundary testing, and decision package. The pilot is scoped around the institution's actual asset, custodian, chain, approval model, recovery design, and regulatory drivers rather than delivered as a generic demonstration.
Does EternaX replace our custodian, tokenization platform, transfer agent, or supported chain?
No. EternaX is not a custodian, tokenization platform, transfer agent, issuer, or market operator. EternaX Vault works with existing HSMs, MPC, and custodians, which keep signing as approvers, while EternaX Vault for Issuers, PQ-ONCHAINID, PQ-Permit, and PQ-4626 integrate beneath supported EVM issuance, compliance, permit, and governance workflows. Existing providers and execution environments can remain in place where their interfaces and control models support integration. References to providers such as Fireblocks, BitGo, Copper, Anchorage Digital, Zodia Custody, Thales, Utimaco, Securitize, or Tokeny describe architectural relevance, not a partnership, certification, or completed vendor integration. See
EternaX Vault and
Stablecoins and Tokenization.
Can we keep our existing assets and workflows, and what may still need to change?
Often yes, but post-quantum safety is control-specific and cannot be promised without checking every accepted authorization path. Holdings can move into an EternaX Vault approved by existing HSMs, MPC, or custodians, compatible EVM roles can be reassigned to EternaX Vault for Issuers, and upgradeable controls can adopt PQ-ONCHAINID, PQ-Permit, or PQ-4626. Immutable contracts, fixed ECDSA interfaces, retained recovery or upgrade keys, unsupported custody APIs, and chain-native signature rules may require wrapping, replacement, redeployment, key rotation, or an explicitly documented residual-risk decision. The pilot identifies precisely what can remain, what must change, and which classical fallbacks must be retired before a control can be classified as PQ-enforced.
Why is post-quantum custody alone not enough to protect tokenized assets?
Custody protection covers the custody approval path; it does not automatically secure every on-chain function that can move assets or change state. A smart contract may still accept a forged ECDSA or EdDSA authorization through mint, burn, freeze, upgrade, permit, governance, recovery, or guardian interfaces, even if the custodian has added a post-quantum approval step. EternaX therefore combines EternaX Vault with application-layer controls such as EternaX Vault for Issuers, PQ-ONCHAINID, PQ-Permit, and PQ-4626. For programmes that also require post-quantum consensus and quantum-durable privacy, the
PQ-Native Settlement path evaluates EternaX Chain.
What do PQ-gated, PQ-enforced, PQ-hardened, and PQ-native mean?
These terms describe different protection boundaries and should not be used interchangeably. PQ-gated means a post-quantum approval is required before an existing system produces or releases a classical transaction or signature, while downstream classical dependencies may remain. PQ-enforced means the defined state-changing control accepts no classical authorization path that can bypass the post-quantum verifier. PQ-hardened means selected custody or application controls are protected, but residual chain, contract, bridge, oracle, recovery, consensus, or privacy dependencies remain. PQ-native means the relevant authorization, key lifecycle, custody, consensus, privacy, and migration model was designed around post-quantum requirements from genesis. The pilot classifies every material control using this vocabulary.
How does EternaX Vault work with our existing HSMs, MPC, and custodians?
Your existing HSMs, MPC, and custodians become the approvers of a vault your institution owns. Post-quantum keys are generated in HSMs with SLH-DSA or ML-DSA support, and assets leave the vault only with NIST post-quantum signatures from the required approvers. MPC platforms that sign with threshold ECDSA or EdDSA, such as Fireblocks, Copper, or Dfns, are not post-quantum, but they can remain the approval workflow while the post-quantum key sits in an HSM; post-quantum MPC signers that produce ML-DSA can sign vault approvals directly. The custodian is not replaced and can hold an approver key. EternaX validates each integration on the institution's own hardware during the pilot. The architecture is described in the
dual-gate paper and on the
EternaX Vault page.
Which post-quantum signature standards does EternaX support, and is the architecture crypto-agile?
EternaX currently anchors high-value authorization in SLH-DSA under NIST FIPS 205 and supports a governed path to ML-DSA under FIPS 204 and future approved schemes. SLH-DSA is the conservative stateless hash-based profile used for institutional authorization. FN-DSA, based on Falcon, remains in development for FIPS 206 and is treated as a future testing and activation option rather than a finalized FIPS production path. EternaX distinguishes signature-agnostic support from full crypto-agility: the pilot evaluates whether algorithms, parameters, keys, modules, providers, and policy can be changed without rebuilding business workflows or recreating the same migration problem. See the
EternaX crypto-agility analysis.
What residual classical dependencies can remain after an EternaX integration?
An EternaX module protects only the controls placed inside its verified protection boundary. Residual dependencies may include chain consensus and native transaction signatures, immutable contracts, retained administrator, guardian, recovery, or upgrade keys, bridges, oracles, relayers, external wallets, third-party applications, software-update signing, certificates, and classical encryption or key establishment used for confidential data. A custody gate may also remain PQ-gated rather than PQ-enforced if the final asset-moving verifier still accepts a classical bypass. The pilot records each dependency as PQ-enforced, PQ-gated, partially mitigated, or still exposed, and produces a residual-risk register rather than making a blanket claim that an entire asset, provider, or chain is post-quantum safe.
What post-quantum regulatory and procurement timelines should institutions track?
The relevant timelines differ by jurisdiction and by whether the institution is directly regulated, a critical-infrastructure operator, or a government supplier. U.S. Executive Order 14412 directs covered federal high-value and high-impact systems to use PQC for key establishment by December 31, 2030 and digital signatures by December 31, 2031; it also requires public CBOM guidance within 270 days of June 22, 2026 and a proposed FAR rule for covered contractors. The EU roadmap calls for Member States to begin coordinated transition by the end of 2026 and critical infrastructure to transition no later than the end of 2030. The UK NCSC targets discovery by 2028, highest-priority migration by 2031, and broad completion by 2035. The HKMA's July 2026 Quantum Preparedness Index targets full banking-sector readiness by 2030. Private-sector applicability remains jurisdiction-specific and should be assessed with legal, procurement, risk, and supervisory teams.
Does our custody or infrastructure provider need to participate from day one?
Not for the initial exposure map and representative validation, but provider participation becomes important before production integration. EternaX can begin with architecture documents, contract inventories, policy flows, role maps, recovery procedures, and a testnet representation of the target workflow. The custodian, HSM operator, wallet provider, tokenization platform, or transfer agent should participate when the pilot reaches API integration, signing-policy configuration, key rotation, recovery validation, operational controls, performance testing, and removal of classical bypasses. The roadmap identifies the exact provider evidence, engineering decisions, and approval milestones required.
How is the EternaX pilot scoped and what does it cost?
The pilot is a defined professional-services engagement priced around the workflow, protection boundary, and integration depth, not a generic software trial. The scoping conversation identifies the asset class, current contracts, custody provider, chain or settlement rail, approval and recovery model, regulatory driver, target controls, required evidence, and decision deadline. EternaX then proposes a fixed scope with named inputs, outputs, phases, responsibilities, assumptions, and exclusions. Pricing varies with the number of pilot paths, systems, chains, providers, test integrations, and governance deliverables being evaluated.
Does the EternaX pilot require production access, live signing authority, or sensitive key material?
No production credentials, live signing authority, or sensitive key material are required for the initial 30-day assessment and representative testnet validation. The pilot can use architecture documentation, contract and role inventories, governance policies, custody workflow descriptions, synthetic data, and test keys. Any later production integration follows the institution's own security architecture, change-management process, vendor governance, key ceremony, cryptographic-module validation, access controls, and approval requirements. The pilot documents those production prerequisites without taking control of the institution's assets or operating responsibilities.