Make existing custody PQ-safe without replacing your custodian or moving assets.

Post-quantum custody replaces the pre-quantum signatures used in institutional custody stacks, including ECDSA and EdDSA, with quantum-resistant algorithms, specifically SLH-DSA / SPHINCS+ (NIST FIPS 205). Institutions need it because a sufficiently powerful quantum computer can derive private keys from exposed ECDSA or EdDSA public keys, forge signatures, and authorize asset transfers without accessing custody infrastructure. Executive Order 14412 accelerates the post-quantum compliance clock for high-value systems and covered infrastructure. EternaX's PQ Custody SDK is designed to integrate into existing MPC-based, HSM-based, and EVM smart-contract custody architectures so that custody providers can make custody signing, custody approvals, and smart-account authorization quantum-durable without replacing the custody platform.

Ethereum and EVM chains break at exposed EOA public keys: once an account has sent a transaction, a quantum attacker could derive the private key and forge asset movement. Solana breaks at native Ed25519 transaction authorization and runtime-level signing assumptions. Canton breaks at participant identity, namespace authority, and contract relationships that depend on pre-quantum signing roots. Stellar breaks at Ed25519 account authorization and quorum authentication. EternaX can harden custody signing and approval workflows across all four rails, and can add Ethereum/EVM on-chain authorization protection through PQ Vault. Native authorization and consensus on Solana, Canton, and Stellar remain chain-level upgrade problems.

EternaX can make custody signing, custody approval workflows, and Safe-style EVM policy controls post-quantum safe when integrated by the custody provider. On Ethereum and EVM-compatible chains, PQ Vault can also protect on-chain asset authorization by requiring post-quantum verification before assets move. On Solana, Canton, and Stellar, EternaX hardens the custody control layer today, while native transaction authorization and consensus remain residual chain-level risks until those networks complete their own cryptographic upgrades.

No. EternaX does not compete with custody providers such as Fireblocks, Zodia Custody, Anchorage Digital, BitGo, Copper, or Hex Trust, and does not replace internal HSM key management systems or Safe-style smart-account treasury workflows. EternaX provides the post-quantum authorization layer that custody providers can integrate underneath their existing architecture. The custody platform, operational workflows, and compliance integrations remain unchanged. The cryptographic primitives and authorization controls upgrade from pre-quantum-only ECDSA or EdDSA assumptions to SLH-DSA / SPHINCS+ (NIST FIPS 205) enforced controls once the custody provider completes integration.

EternaX is designed for environments that use MPC custody, HSM signing infrastructure, and Safe-style EVM smart accounts. That includes architectures operated through providers such as Fireblocks, BitGo, Copper, Anchorage Digital, Zodia Custody, Hex Trust, Safe, Thales, Utimaco, Securosys, and Futurex. This is not a claim of partnership, certification, or active integration with those providers. The point is architectural compatibility: EternaX's PQ Custody SDK is built so that custody providers can integrate a post-quantum authorization layer underneath their existing controls rather than requiring the institution to replace the custodian, workflow, compliance stack, or asset venue.

EternaX's PQ Custody SDK is architecturally compatible with both MPC-based and HSM-based custody stacks. The dual-gate architecture abstracts individual participant authentication and threshold group authorization above the specific hardware layer. It is designed to integrate with MPC coordination protocols used by providers like Fireblocks and BitGo as well as HSM hardware environments from Thales Luna, Utimaco, Securosys, and Futurex. Institutions running on-premise HSM infrastructure can benefit from the PQ Custody SDK without switching to MPC once their custody provider completes integration. The protocol requires only an ordinary signature over the contribution envelope, so any device exposing a standard sign API can participate directly.

Yes, for EVM smart-contract custody, including Safe-style multisigs, EternaX can add a post-quantum authorization layer without moving assets or changing chains. The precise mechanism is not to claim that every Safe is automatically PQ-safe. The correct model is ERC-1271-compatible PQ verifier contracts and policy guards that require SLH-DSA / SPHINCS+ authorization before asset movement or privileged account changes execute. For institutional deployments, EternaX treats Safe configuration as part of the risk boundary: owner changes, threshold changes, guard changes, fallback-handler changes, module enablement, and module transactions must be covered by PQ policy enforcement. Where a Safe retains ECDSA-only execution paths, those paths are documented as residual configuration risk.

No. Making your custody PQ-safe protects two of four quantum risk layers: stored key material and custody approval workflows. Assets on Ethereum remain vulnerable to on-chain transaction forgery, where a quantum adversary derives the private key from the public key exposed in any prior Ethereum transaction and forges a valid ECDSA signature to move assets without touching the custody stack. Protecting this third layer requires PQ Vault on Ethereum, an EIP-4337 Account Abstraction smart contract that enforces SPHINCS+ signature verification on-chain. EternaX provides PQ Custody SDK and PQ Vault as one bundle because neither product alone creates a defensible institutional risk posture.

PQ Vault is an EIP-4337 Account Abstraction smart contract on Ethereum that replaces ECDSA signature verification with SPHINCS+ verification using Ethereum's existing SHA-256 precompile at address 0x02. Institutional assets held inside a PQ Vault contract require a valid SPHINCS+ signature for every transaction authorization. A quantum adversary who derives the underlying EOA private key cannot move the assets because the PQ Vault contract, not the EOA, controls authorization. Gas cost is approximately 1.4M to 3M gas depending on SPHINCS+ parameter set. No Ethereum protocol upgrade is required for deployment.

After deploying both PQ Custody SDK and PQ Vault, three of four quantum risk layers are PQ-safe on EVM chains: on-chain transaction authorization, stored key material, and custody approval workflows. The fourth layer, the chain consensus mechanism (validator signatures, attestation, block proposal signing, and finality), remains vulnerable because it requires the chain itself to upgrade. This residual vulnerability should be documented clearly in the institution's risk register because it cannot be remediated externally by a custody-layer integration.

PQ Vault requires three architectural preconditions: programmable smart contracts with custom verification logic, an Account Abstraction mechanism to separate asset authorization from the native signature scheme, and sufficient computational budget for SPHINCS+ verification. Solana's hard 1,232-byte transaction size limit cannot accommodate SPHINCS+ signatures (7,856 bytes minimum for SPHINCS+-SHA2-128s). Canton is not EVM-compatible, has no Account Abstraction, and its namespace identity root is structurally tied to pre-quantum signing keys, meaning the identity layer cannot be PQ-upgraded without re-establishing every contract relationship across the participant graph. Stellar's Ed25519 protocol-level requirement and Soroban resource limits prevent deployment. On these chains, EternaX makes the custody control layer PQ-safe through PQ Custody SDK, while on-chain transaction authorization and consensus-layer risks remain residual chain-level vulnerabilities.

Ethereum's native PQ upgrade faces structural barriers that an external custody-layer integration cannot control. Ethereum's immutable contract corpus (ERC-2612 Permit, WETH9, Uniswap, Aave, Compound) is frozen on ECDSA. Ethereum's address derivation uses keccak256 of the ECDSA public key. Ethereum's consensus uses BLS signatures across approximately 1 million validators. Upgrading these layers requires coordinated protocol and ecosystem changes. EternaX therefore focuses on what can be hardened today inside the institution's current operating model: custody signing, custody approvals, and EVM asset authorization through PQ Vault, without requiring a chain change.

Because institutional custody needs conservative cryptographic assumptions, not only fast signatures. NIST finalized three post-quantum signature standards. SLH-DSA / SPHINCS+ (NIST FIPS 205) is hash-based: its security relies solely on hash function security, the most conservative and well-studied assumption in cryptography with over 30 years of analysis. ML-DSA / CRYSTALS-Dilithium (NIST FIPS 204) relies on lattice hardness (Module-LWE), a newer mathematical assumption with active research into lattice attacks. FN-DSA / Falcon (NIST FIPS 206 draft) requires complex constant-time floating-point or integer emulation, creating higher implementation and side-channel risk. For rare, high-value custody operations where billions in assets are at stake, the conservative security foundation of hash-based SLH-DSA outweighs the compact signature sizes of lattice-based alternatives. Ethereum's own Lean Ethereum roadmap (Vitalik Buterin, February and July 2026) also selects hash-based cryptography (leanXMSS, STARKs) for its post-quantum future, confirming the conservative hash-based approach. EternaX's dual-gate architecture avoids thresholding SLH-DSA / SPHINCS+ itself: members sign ordinary SLH-DSA approval envelopes, while threshold authorization is enforced separately through a Shamir-shared seal.

For rare, high-value institutional custody authorization, EternaX treats SLH-DSA / SPHINCS+ as the conservative choice. SLH-DSA / SPHINCS+ (NIST FIPS 205) is NIST's stateless hash-based digital signature standard, so its security rests on hash-function assumptions rather than lattice assumptions or floating-point implementation complexity. ML-DSA / CRYSTALS-Dilithium (NIST FIPS 204) is a strong general-purpose NIST standard and may be appropriate where speed and compactness matter more. FN-DSA / Falcon (NIST FIPS 206 draft) is compact but more implementation-sensitive and remains a draft standard. For custody, where operations are lower-frequency but high-value, conservative hash-based assurance is the better risk-adjusted profile. Dual-gate custody preserves crypto-agility so future NIST-approved schemes can be adopted as Gate 1 member authentication without redesigning threshold authorization.

Cryptographic agility — also called crypto-agility — is the ability to replace signature algorithms, parameters, keys, and modules without rebuilding the custody platform. In EternaX dual-gate custody, members authenticate with ordinary SLH-DSA / SPHINCS+ signatures at Gate 1, while Gate 2 enforces threshold authorization through a signature-agnostic seal. That separation lets institutions anchor on the most conservative NIST standard today and rotate Gate 1 to future approved schemes later without another MPC protocol redesign.

Yes, a custody provider can eventually add ordinary SLH-DSA / SPHINCS+ (NIST FIPS 205) signing support. But ordinary SLH-DSA / SPHINCS+ (NIST FIPS 205) support does not automatically solve MPC-style threshold custody, because hash-based threshold signatures are not a practical drop-in replacement for threshold ECDSA in institutional custody (see the Post-Quantum MPC Custody Crisis 2026 report for the full analysis across 15 providers, and the dual-gate architecture paper (arXiv) for the formal specification). EternaX solves the harder authorization problem by not thresholding SLH-DSA at all. Members sign ordinary SLH-DSA / SPHINCS+ approval envelopes, while threshold authorization is enforced separately through a Shamir-shared seal. That is the difference between adding a post-quantum signature primitive and making distributed custody authorization post-quantum safe.

Executive Order 14412 accelerates the post-quantum compliance clock for high-value systems and covered infrastructure, creating transition pressure around 2030 for key establishment and FIPS compliance, and around 2031 for authentication and signature migration. The order also pushes Cryptographic Bill of Materials (CBOM) readiness by requiring minimum CBOM elements to be defined within 270 days. NIST finalized the SLH-DSA / SPHINCS+ standard (NIST FIPS 205) in August 2024. Institutions that have not begun a PQ custody upgrade face regulatory, fiduciary, and operational-risk scrutiny.

Canton Network cannot support a PQ Vault equivalent because Canton is not EVM-compatible, does not have Account Abstraction, and does not have a SHA-256 precompile path for SPHINCS+ verification. Canton's DAML smart contract language and Synchronizer architecture are proprietary, and its namespace identity root is structurally tied to pre-quantum signing keys, meaning the identity layer cannot be PQ-upgraded without re-establishing every contract relationship and domain registration across the participant graph. The Synchronizer scheme gate makes partial cryptographic upgrades operationally difficult because each bilateral sync requires both counterparties on compatible cryptographic schemes. For institutions on Canton, EternaX can harden the custody control layer through PQ Custody SDK, while the remaining on-chain and consensus-layer risks should be explicitly documented as residual chain-level vulnerabilities. This preserves the institution's current operating model rather than forcing a chain change.

Yes, once your custody provider integrates EternaX's PQ Custody SDK, your existing MPC or HSM custody stack gains PQ-safe authorization, and EVM assets can be wrapped in PQ Vault to make three of four quantum risk layers PQ-safe, with no chain change required. Your custody provider, workflows, compliance stack, and asset venue remain unchanged. The integration is between EternaX and your custody provider; the institution benefits from PQ-safe custody without re-platforming.

EternaX offers a 90-day integration pilot covering PQ Custody SDK integration with your custody provider's MPC or HSM stack, PQ smart-account authorization review for Safe-style EVM accounts where applicable, and PQ Vault deployment for on-chain asset protection on EVM chains via EIP-4337 Account Abstraction with SPHINCS+ verification. The pilot is conducted jointly with the custody provider and the institution. It includes integration engineering support, quantum risk layer documentation, residual vulnerability reporting, smart-account configuration risk review, and a post-pilot compliance readiness assessment aligned to EO 14412 and CBOM disclosure requirements. For complete solution architecture and pilot scoping, email info@eternax.ai.

Institutional programmes involving tokenized funds, stablecoins, transfer-agent signing, MPC policy engines, HSM-controlled keys, Safe-style treasury accounts, and Ethereum/EVM on-chain authorization should assess post-quantum custody exposure. Relevant examples include BlackRock BUIDL, Franklin Templeton BENJI, Hamilton Lane tokenized funds, JPMorgan Onyx, Standard Chartered and Zodia Custody, HSBC Orion, Citi Token Services, BNY Mellon, Goldman Sachs DAP, DBS, Circle USDC, Tether USDT, Paxos, PayPal PYUSD, Visa, Fidelity, Apollo, and KKR. The question is not whether these institutions are negligent. The question is whether their custody, transfer-agent, smart-account, and on-chain authorization paths still depend on ECDSA, Ed25519, BLS, MPC key shares, or HSM signing controls that are not yet post-quantum safe. EternaX's Post-Quantum Exposure Map and Already Broken report are designed to help institutions assess this exposure defensibly.

Tokenized funds like BlackRock BUIDL should assess post-quantum custody exposure because tokenized fund operations can depend on multiple authorization layers: custodian signing, transfer-agent controls, administrator keys, smart-contract permissions, and Ethereum/EVM transaction authorization. Where those layers rely on ECDSA, Ed25519, MPC key shares, HSM-controlled signing, or exposed EOA public keys, a future quantum-capable attacker could create transaction-forgery or authorization-forgery risk. This does not require claiming that BUIDL is uniquely vulnerable or poorly managed. It means tokenized funds are exactly the kind of high-value institutional asset class that should map PQ exposure now, document residual risks, and define a migration path toward SLH-DSA / SPHINCS+ (NIST FIPS 205) custody authorization where deployable.