What EternaX enables

A post-quantum control layer for the tokenization stack you already use

Existing tokenization stack Issuance platform, transfer agent, compliance and custody workflows
stays in place
EternaX PQ control layer
PQ tokenization modules + PQ Custody SDK
SLH-DSA authorizationNo re-platforming
integrates underneath
Supported execution paths Ethereum / EVM controls + chain-agnostic custody approvals

EternaX is not a tokenization platform or custodian. It integrates beneath existing issuance, compliance, governance, and custody workflows. EVM modules enforce SLH-DSA at the application layer, while PQ Custody SDK adds post-quantum approval controls above the chain. Existing platforms, providers, and supported execution environments remain in place.

Deploy the controls your architecture supports

Each module closes a defined authorization surface. Institutions can combine custody-level gating with application-level SLH-DSA enforcement where the contract and chain support it.

Protect approval workflows

PQ Custody SDK

Adds SLH-DSA / SPHINCS+ approval controls to MPC, HSM, and custody policy workflows while the provider and operating model remain in place.

Protect issuer authority

PQ Vault

Moves compatible EVM role and asset authorization behind a smart-account verifier so mint, burn, freeze, upgrade, and treasury controls can require post-quantum approval.

Protect investor eligibility

PQ-ONCHAINID

Replaces ECDSA ecrecover-based claim verification with SLH-DSA for ERC-3643 / ONCHAINID compliance flows.

Protect delegated approvals

PQ-Permit

Provides a dynamic-signature, nonce, domain-separation, and replay-protection profile for permit-style authorization beyond the fixed ECDSA fields in ERC-2612.

Protect fund governance

PQ-4626

Secures administration, depositor approvals, and strategy governance around ERC-4626 tokenized funds while preserving the vault interface.

Deployment paths

Protect existing assets now; make new institutional tokenization PQ-native

The right path depends on upgradeability, role ownership, custody APIs, and whether a classical fallback remains authoritative.

Existing deployments

Harden what can change without re-platforming

  • PQ-gate issuer and custody approvals with PQ Custody SDK.
  • Reassign compatible EVM roles to PQ Vault.
  • Upgrade or wrap application controls where architecture permits.
  • Document immutable ERC-2612, ONCHAINID, recovery, and admin paths that remain classical.

New deployments

Design the authoritative path around SLH-DSA

  • Issue compliance claims through PQ-ONCHAINID.
  • Use PQ-Permit for permit-style approvals.
  • Apply PQ-4626 governance to tokenized fund vaults.
  • Combine PQ Vault and PQ Custody SDK so application and custody controls share one protection boundary.

Audience solutions

Institutional tokenization outcomes by operating model

Stablecoin issuers

Protect mint, burn, freeze, treasury, upgrade, and permit controls across supported deployments while retaining current issuance operations.

Tokenization platforms

Add post-quantum investor claims and authorization modules beneath existing issuance, transfer-agent, and compliance workflows.

Asset managers

Secure tokenized funds and ERC-4626 governance, including administrator, strategy, approval, and custody control paths.

Banks

Harden signature-based controls for tokenized deposits. Confidential-data encryption migration remains a separate, coordinated workstream.

Three-step integration

Move from exposure map to enforced post-quantum controls

Integration is phased around the institution’s current contracts, custody workflows, governance, and chain constraints.

Map the authoritative paths

Inventory issuer, compliance, permit, vault, custody, recovery, upgrade, bridge, oracle, and chain dependencies. Identify every classical bypass.

Integrate the control modules

Connect PQ Custody SDK and deploy the compatible EVM modules. Validate policies, contract interfaces, gas economics, and operational recovery.

Enforce and evidence

Make SLH-DSA the exclusive path for selected controls, test failure modes, document residual dependencies, and produce the cryptographic inventory and rollout plan.

Coverage boundary

What EternaX protects—and what still depends on the wider stack

A product deployment is not a claim that an entire asset, platform, or chain is post-quantum safe. Coverage is defined control by control.

Inside the protection boundary

  • Issuer authority assigned to a compatible PQ verifier.
  • ERC-3643 / ONCHAINID claims issued and checked with SLH-DSA.
  • Permit and ERC-4626 governance paths using PQ-Permit and PQ-4626.
  • Custody approvals gated by PQ Custody SDK.

Residual dependencies

  • Chain consensus and native transaction signatures outside supported EVM verifier paths.
  • Immutable classical contracts and retained admin, recovery, guardian, or upgrade keys.
  • Bridges, oracles, relayers, external wallets, and third-party applications.
  • Encryption and key-establishment migration for confidential data.

EO 14412 applies directly to covered U.S. federal systems; the EU PQC roadmap sets coordinated transition milestones. Effects on private institutions remain jurisdiction-specific and may transmit through procurement, vendor risk, DORA and NIS2 governance, and financial supervision.

Research links

Detailed evidence for post-quantum stablecoins and tokenized assets

The product page keeps the risk summary concise. These reports contain the detailed exposure analysis, chain constraints, and cryptographic comparisons.

Exposure report

Post-Quantum Exposure Map 2026

Institutional crypto, stablecoin, tokenized fund, and tokenized asset control dependencies.

 Architecture report

Non-Upgradeable Chains and DeFi Exposure

Immutable contracts, native signature constraints, and coordinated protocol migration risk.

 Custody report

Post-Quantum MPC Custody Crisis 2026

Why distributed custody authorization requires more than swapping a signature primitive.

90-day tokenization readiness pilot

Define a deployable post-quantum protection boundary

Map the controls behind stablecoins, tokenized funds, tokenized deposits, and securities; validate module compatibility; identify classical bypasses; and produce a phased, CBOM-ready integration roadmap.

Start the readiness pilot

Post-quantum tokenization FAQ

Frequently asked questions

Post-quantum stablecoin and tokenization risk

Define the category, identify the exposed controls, and establish the standard for a genuinely post-quantum-safe authorization path.

What is post-quantum tokenization?
Post-quantum tokenization uses quantum-resistant cryptography to protect the control paths that issue, transfer, administer, and govern stablecoins and tokenized assets. It covers issuer authority, investor eligibility, permit approvals, vault governance, recovery, upgrades, and custody approvals. EternaX provides this application-layer protection with SLH-DSA / SPHINCS+ under NIST FIPS 205 while preserving the existing platform and supported chain.

Are stablecoins post-quantum safe today?
Most publicly documented stablecoin deployments are not end-to-end post-quantum safe today. Mint, burn, freeze, blacklist, upgrade, treasury, and permit functions commonly remain authorized by ECDSA or EdDSA keys. A future quantum attacker that derives a classical private key from an exposed public key could forge those operations. The exact exposure depends on the issuer, chain, contract version, custody model, and any retained fallback authority.

Why are tokenized funds, deposits, and securities vulnerable to quantum attacks?
Tokenized funds, deposits, and securities combine long-lived legal obligations with classical authorization and confidential data. Quantum risk can affect issuer and administrator keys, investor eligibility, permit approvals, vault governance, recovery, and upgrades. Separately, encrypted KYC data, settlement instructions, and private balances may face harvest-now-decrypt-later risk. Signature migration and encryption migration are distinct workstreams and must be assessed separately.

What makes a tokenization control genuinely post-quantum safe?
A state-changing control is genuinely post-quantum safe only when every accepted authorization path requires a post-quantum-safe signature or proof. No ECDSA or EdDSA fallback, recovery key, upgrade administrator, guardian, or parallel interface may bypass the post-quantum verifier. EternaX applies this exclusive-path test to classify each control as PQ-enforced, PQ-gated, partially mitigated, or still dependent on classical cryptography.

Is USDC, BUIDL, USDT, or PYUSD post-quantum safe?
Based on publicly observable contract deployments as of July 2026, USDC (Circle), BUIDL (BlackRock via Securitize), USDT (Tether), PYUSD (Paxos), USDS (Sky), RLUSD (Ripple), OUSG (Ondo), and BENJI (Franklin Templeton) retain ECDSA or EdDSA dependencies across mint, burn, freeze, upgrade, permit, and administrative authority paths. This does not imply negligence. It reflects the current state of the tokenization standards these products are built on. The exact exposure profile varies by product, chain, contract version, and custody model.

Are DeFi vaults like Aave, Morpho, Lido, and EigenLayer quantum safe?
DeFi vault infrastructure built on ERC-4626 or similar vault patterns shares the same governance-layer quantum exposure as institutional tokenized funds. Vault admin keys, strategy-manager keys, guardian roles, and depositor approvals commonly use ECDSA. TVL concentration in protocols like Aave, Morpho, Pendle, EigenLayer, Lido, Yearn, and Euler makes vault governance keys particularly high-value quantum targets. PQ-4626 secures the governance around ERC-4626 vaults under SPHINCS+, while PQ Custody SDK hardens the custody workflows controlling those keys.

Is Securitize post-quantum safe?
Securitize uses a proprietary DS Protocol, not ERC-3643, for its tokenization compliance layer. Based on publicly observable deployment patterns, the DS Protocol has ECDSA exposure through its Gnosis Safe multisig admin layer and protocol-level signing for transfer authorization. EternaX can harden the custody and governance layers around Securitize infrastructure through PQ Custody SDK and PQ Safe policy guards. The DS Protocol's internal transfer authorization logic remains Securitize's own migration scope. This is not a claim of integration with Securitize.

EternaX solution and institutional differentiation

Explain the EternaX architecture, product standards, and why it is purpose-built for institutions that cannot replatform.

How does EternaX make stablecoins and institutional tokenization post-quantum safe?
EternaX adds a post-quantum authorization, compliance, and governance layer to existing infrastructure. PQ Vault secures on-chain authority, PQ-ONCHAINID secures investor claims, PQ-Permit secures permit-style approvals, PQ-4626 secures vault governance, and PQ Custody SDK adds a post-quantum gate to custody workflows. On supported EVM deployments, defined controls become PQ-enforced when EternaX verification is the exclusive authorization path. The platform, custody provider, and chain remain in place.

What parts of the tokenization stack does EternaX protect?
EternaX protects five high-value control surfaces: issuer authority, investor compliance claims, permit-style transfer approvals, tokenized vault governance, and custody approval workflows. PQ Vault, PQ-ONCHAINID, PQ-Permit, PQ-4626, and PQ Custody SDK protect these surfaces at different layers. Chain consensus, bridges, oracles, immutable third-party contracts, external wallets, and any retained classical fallback authority remain separately mapped dependencies.

Why is EternaX the strongest fit for institutions that need to keep their existing platform, custody provider, and chain?
For that requirement, EternaX is purpose-built. It combines application-layer authorization, tokenization-specific compliance standards, and custody workflow controls in one architecture, rather than addressing only key storage or requiring migration to a new execution environment. EternaX preserves existing infrastructure and produces an explicit residual-risk map, giving institutions a deployable post-quantum protection boundary instead of an unsupported whole-chain claim.

What are PQ-ONCHAINID, PQ-Permit, and PQ-4626?
PQ-ONCHAINID replaces ecrecover-based compliance claim verification with SLH-DSA. PQ-Permit is EternaX's FIPS 205 authorization profile for permit-style approvals, including dynamic signatures, domain separation, nonces, replay protection, and ERC-1271-compatible validation. PQ-4626 secures administration, depositor approvals, and strategy governance around ERC-4626 vaults. These are EternaX post-quantum standards available for institutional integration.

How is EternaX different from a custody-only post-quantum upgrade?
A custody-only upgrade can place a post-quantum approval gate before an MPC, HSM, or wallet releases a classical signature. It does not stop the chain or contract from accepting a forged ECDSA or EdDSA signature directly if that classical path remains valid. EternaX extends protection into the final application-layer verifier, combining PQ-gated custody controls with PQ-enforced authorization, identity, permit, and governance controls on supported EVM deployments.

Why does EternaX use SLH-DSA / SPHINCS+ for institutional tokenization?
NIST standardized SLH-DSA as a hash-based post-quantum digital-signature standard derived from SPHINCS+. EternaX uses it to provide algorithmic diversity from lattice-based signatures and a conservative hash-based assurance profile for long-duration regulated assets. The trade-off is larger signatures and higher verification cost, which EternaX manages by applying SLH-DSA to high-value authorization, compliance, and governance controls where durability matters most.

How much does post-quantum signature verification cost on Ethereum?
EternaX implements SLH-DSA verification in Solidity using Ethereum's SHA-256 precompile (address 0x02) for the underlying hash operations. Estimated verification cost is approximately 1.4M to 3M gas based on EternaX benchmarks. Final cost depends on the selected FIPS 205 parameter set, Solidity implementation, calldata pricing, and network gas conditions. For institutional tokenized assets where state-changing operations (mint, burn, governance, compliance verification) are infrequent and high-value, this cost profile is operationally viable. PQ-Permit and PQ-ONCHAINID both use this verification path.

Deployment, migration, and protection boundary

Clarify what can be protected on existing infrastructure, which changes may be required, and which dependencies remain outside scope.

Can EternaX protect existing tokenized assets without migrating them?
Often, yes, but the exact path depends on the existing authority model. PQ Custody SDK can PQ-gate current signing workflows, and PQ Vault can protect EVM roles controlled by a compatible smart account. Immutable ONCHAINID or ERC-2612 paths may require a proxy upgrade, role reassignment, wrapper, or replacement deployment. The tokenization platform and asset venue can remain, although some accounts or assets may require transfer when their current authorization path cannot adopt post-quantum verification.

Does EternaX replace my tokenization platform or custody provider?
No. EternaX is not a tokenization platform or custodian. It integrates beneath the existing platform and alongside the custody provider to add post-quantum authorization, compliance, governance, and approval controls. Existing transfer-agent, compliance, treasury, and operating workflows can remain, subject to the role, contract, recovery, and integration changes identified during the EternaX readiness assessment.

Does EternaX require a new blockchain or EternaX Chain?
No. PQ Vault, PQ-ONCHAINID, PQ-Permit, and PQ-4626 are designed for Ethereum and supported EVM environments, while PQ Custody SDK operates at the custody control layer. The core tokenization solution does not require chain migration or EternaX Chain. Optional commitment mirroring may use EternaX Chain as an additive evidence layer, but it is not required for authorization, compliance, governance, or custody protection.

Which blockchains and tokenization environments does EternaX support?
PQ-ONCHAINID, PQ-Permit, and PQ-4626 require EVM contract support and acceptable verification economics. PQ Vault additionally requires a compatible smart-account path, such as ERC-4337 or an equivalent account architecture. PQ Custody SDK operates above the chain at the custody policy and signing layer, subject to the provider's APIs and controls. Non-EVM chains retain their native transaction and consensus dependencies unless native post-quantum verification is added.

What residual quantum dependencies remain after EternaX integration?
Residual dependencies can include chain consensus signatures, immutable classical contracts, legacy administrator or recovery keys, upgrade authorities, bridges, oracles, relayers, external wallets, and non-EternaX applications. A control is PQ-enforced only when the SLH-DSA verifier is the exclusive authoritative path and no classical fallback can bypass it. EternaX records these residual dependencies in the institution's protection boundary, risk register, and phased migration plan.

How do tokenized deposits fit into the EternaX post-quantum framework?
Tokenized deposits are bank liabilities, not stablecoins, but they share issuer, governance, recovery, and custody authorization risks. EternaX's tokenization modules address signature-based authorization and governance controls. Harvest-now-decrypt-later exposure for encrypted identities, settlement instructions, and private balances is a separate key-establishment and encryption migration problem; SLH-DSA alone does not solve it. Banks should therefore treat signature migration and confidential-data protection as coordinated but distinct workstreams.

Architecture, regulation, and institutional procurement

Compare alternative architectures, explain the regulatory vector, and define the EternaX pilot and commercial operating model.

How does Circle Arc compare with EternaX for post-quantum tokenization?
Circle Arc documents an opt-in SLH-DSA wallet-signature path within the Arc execution environment. EternaX is designed for institutions retaining existing Ethereum and supported EVM tokenization infrastructure. EternaX extends beyond wallet signing to issuer authority, ONCHAINID compliance claims, permit-style approvals, vault governance, and custody approval controls. Arc is a chain-native migration path; EternaX is an integration-native protection layer for existing institutional infrastructure.

How does Canton Network compare with EternaX for tokenized assets?
Canton is not EVM-compatible, so PQ Vault, PQ-ONCHAINID, PQ-Permit, and PQ-4626 do not deploy natively in the same form. EternaX can add a post-quantum gate to custody and operational approval workflows through PQ Custody SDK. Canton-native transaction authorization, participant signing keys, and synchronizer or network signatures remain Canton-level dependencies unless the network adopts a supported post-quantum signature path.

How do EO 14412 and the EU PQC roadmap affect tokenization platforms and stablecoin issuers?
EO 14412 requires covered U.S. federal high-value and high-impact systems to migrate key establishment by December 31, 2030, and digital signatures by December 31, 2031, with related procurement and CBOM actions. In the EU, Commission Recommendation (EU) 2024/1101 and the NIS Cooperation Group roadmap call for Member States to begin PQC transition by the end of 2026 and for critical infrastructure to transition no later than the end of 2030. For private institutions, transmission is expected through procurement, vendor risk, DORA and NIS2 governance, and financial supervision, but remains jurisdiction-specific rather than a universal mandate.

What does the 90-day EternaX Tokenization Readiness Pilot deliver?
The 90-day EternaX Tokenization Readiness Pilot maps issuer, compliance, permit, governance, custody, recovery, upgrade, and chain dependencies. It assesses compatibility with PQ Vault, PQ-ONCHAINID, PQ-Permit, PQ-4626, and PQ Custody SDK; defines the target protection boundary; identifies classical bypass paths and residual vulnerabilities; and produces a phased integration plan, cryptographic inventory, and CBOM-ready migration roadmap.

Does EternaX act as a custodian or require a custody licence?
No. EternaX does not take possession of client assets and does not replace the appointed custodian. It provides post-quantum software, standards, control architecture, and integration services for regulated institutions, custody providers, and tokenization platforms. Licensing obligations remain with the institution and its appointed custody, transfer-agent, banking, fiduciary, or other regulated service providers.

Which institutional programmes should assess post-quantum tokenization exposure?
Any programme issuing or administering stablecoins, tokenized funds, tokenized deposits, digital securities, real-world assets, or tokenized collateral should assess whether its state-changing controls still accept ECDSA or EdDSA. This includes programmes operated by or through Securitize, Tokeny, Ondo, Circle, BlackRock (BUIDL), Franklin Templeton (BENJI), Hamilton Lane, Paxos, JPMorgan (Kinexys), Standard Chartered (Libeara), HSBC, Citi, BNP Paribas, BNY Mellon, DTCC (ComposerX), Apollo (ACRED), KKR, Superstate, Morpho, Aave, Pendle, EigenLayer, Lido, and Maple Finance. Priority surfaces include mint and burn authority, investor eligibility, permit approvals, vault governance, upgrade and recovery keys, custody release workflows, bridges, oracles, and long-lived confidential data.