What does the EternaX 90-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 PQ Vault, PQ-ONCHAINID, PQ-Permit, PQ-4626, and PQ Custody SDK; 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, integrate post-quantum custody controls, 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; Custody and MPC Authorization for MPC, HSM, or Safe-style approval workflows; 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. Institutions can combine paths around one programme. Review the
tokenization controls,
custody architecture, and
PQ-native settlement path.
How long is the EternaX pilot and what does my institution need to provide?
The standard pilot runs for 90 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. PQ Custody SDK is designed for architectural compatibility with existing MPC, HSM, and Safe-style custody environments, while PQ Vault, 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
Custody and MPC Providers 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. Compatible EVM roles can be reassigned to PQ Vault, upgradeable controls can adopt PQ-ONCHAINID, PQ-Permit, or PQ-4626, and custody approvals can be PQ-gated through PQ Custody SDK. 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 PQ Custody SDK with application-layer controls such as PQ Vault, 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 dual-gate custody work with MPC, HSM, and Safe-style workflows?
EternaX separates post-quantum member authentication from threshold group authorization instead of attempting to threshold SLH-DSA itself. At Gate 1, custody participants sign ordinary SLH-DSA approval envelopes. At Gate 2, a Shamir-shared seal enforces the required authorization threshold before the protected action can proceed. This signature-agnostic separation is designed to integrate above MPC coordination, through standard signing interfaces in compatible HSM environments, and with ERC-1271 or policy-guard patterns for Safe-style accounts. Provider-specific engineering, validation, key rotation, recovery testing, and removal of bypass paths remain part of production integration. The architecture is described in the
dual-gate paper and the
custody solution 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 90-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.