At Fireblocks, we rotated a funded NEAR account from Ed25519 to ML-DSA-65 in two transactions. The account kept its address, accepted another payment, and sent funds using the new key. The critical choice was the sequence: the new key signed the transaction that retired the old one.
Why We Need to Start Planning for Migration
The quantum threat extends across the classical public-key algorithms widely used today: RSA, ECDSA, EdDSA, and elliptic-curve and finite-field Diffie-Hellman. A sufficiently powerful quantum computer running Shor’s algorithm could solve the mathematical problems underlying them. Switching between these algorithms therefore does not address that threat.
NIST’s proposed transition schedule calls for deprecating specified classical algorithms after 2030 and disallowing the listed quantum-vulnerable algorithms after 2035. These are transition targets within NIST’s guidance, rather than predictions of when quantum attacks will become practical. For institutions, the planning question is how much work migration will require before it becomes urgent.
With encrypted data, the quantum risk is harvest-now-decrypt-later: an adversary collects encrypted material today and waits for a machine capable of decrypting it. For blockchain signatures, the exposure is different. Wherever a spending public key is already visible on-chain, a future attacker has the material needed to attempt private-key recovery. There is no private traffic to intercept. If that key still controls assets when a sufficiently powerful quantum computer becomes available, those assets could be at risk.
When that exposure begins depends on the chain and the account or output type. Bitcoin’s public-key-hash outputs generally conceal the public key until spending, provided it has not already been revealed elsewhere. Other output types, including Taproot, expose a public key from the outset. BIP 360 discusses this distinction between long-term exposure and exposure during spending.
For the NEAR implicit account used in this experiment, exposure begins at creation: the account address itself is the hexadecimal encoding of the original Ed25519 public key. Migration therefore requires retiring that key’s authority. Its public key remains visible after rotation, but it can no longer authorize transactions while its access key remains removed.
The question for anyone holding on-chain assets is how to make that transition a controlled, repeatable operation.
Why We Started with ML-DSA
NIST selected three signature schemes in its initial post-quantum standards. Two were standardized in August 2024: ML-DSA as FIPS 204 and SLH-DSA as FIPS 205. The third, FN-DSA, is based on FALCON and remains under standardization. Its signing implementation presents particular challenges around numerical precision, side-channel protection, and validation: an incorrect signature distribution can leak information about the private key. NIST’s FN-DSA status presentation explains these challenges.
Chains are taking different approaches. NEAR supports ML-DSA signing, while Algorand supports FALCON verification for quantum-resistant transactions. Bitcoin’s BIP 360 remains a draft proposal to reduce long-term public-key exposure without introducing post-quantum signatures; its inclusion in the proposals repository does not mean it has been activated. Ethereum’s roadmap distinguishes consensus research focused on hash-based signatures from execution-layer work on account abstraction, allowing accounts to adopt new verification schemes. Those plans remain subject to research and governance.
For key infrastructure, ML-DSA already has concrete deployment options. AWS KMS supports ML-DSA, and Google Cloud KMS supports both ML-DSA and SLH-DSA. That availability matters for custodians, which need to manage the complete key lifecycle as well as produce signatures.
ML-DSA is also a promising starting point for our threshold-signing work, supported by constructions and experimental implementations published by other research teams. Production suitability depends on more than signing performance: key generation, recovery, proactive share refresh, and implementation assurance all need evaluation against the custody system’s requirements.
What Changed in 2026
NEAR’s 2.13 mainnet upgrade, live since July 2026, added ML-DSA-65 alongside its existing signing schemes. This gave us a live environment in which to test how an existing account could adopt post-quantum signing.
NEAR treats an account identifier as independent of the keys that control it. An account can hold several access keys of different types, and adding or removing them is an ordinary protocol action. Post-quantum support fits into that model as a third key type alongside Ed25519 and secp256k1.
For this account, migration can happen through in-place key rotation, without transferring assets to a new address.
Why In-Place Rotation Matters
- The address stays the same and continues accepting payments. We confirmed this with a successful incoming payment after removing the Ed25519 access key. Counterparties can continue using the existing deposit address.
- No assets move during the rotation. Signing authority changes on the existing account, avoiding a transfer to a replacement account.
- Two transactions, deliberately. The first registers the new key. The second is signed by the new key and removes the old one, demonstrating control as the previous authority is retired.
The institution’s signing infrastructure must support the new scheme, and the change remains subject to its operational and compliance controls.
The Mainnet Experiment
For this mainnet experiment, we generated and held the ML-DSA-65 key behind a PKCS#11 interface using kryoptic, an open-source software HSM.
The account is a NEAR implicit account, so its address is the hexadecimal encoding of the original Ed25519 public key:
fdffb331840d8fe4830dcc95b533fde827ce662e27f2780ccc2628faddff9215
The account starts with an Ed25519 access key derived from its address. We register the ML-DSA key with AddKey, then use that new key to remove the original access key.
The six transactions below cover account creation, a baseline transfer, the two-step rotation, and incoming and outgoing payments after rotation.
| Step | Signed by | Action | Transaction |
|---|---|---|---|
| 1 | Outside party | Fund the address, implicitly creating the account. | An3wAwz9… |
| 2 | Ed25519 | Send an Ed25519-signed transfer to establish the baseline for later comparison, and show control over the account. | D9NpuHWG… |
| 3 | Ed25519 | Register the ML-DSA-65 key (AddKey). | 79rvfcT6… |
| 4 | ML-DSA-65 | Remove the Ed25519 key (DeleteKey). | JB8S3aNs… |
| 5 | Outside party | Receive another payment at the same address. | 9WwrAMa9… |
| 6 | ML-DSA-65 | Send an ML-DSA-65-signed transfer to the baseline destination. | BaR4UqHw… |
Steps 3 and 4 perform the rotation. The new key signs the transaction that removes the old key, demonstrating control as the old authority is revoked. If the new key cannot produce a valid signature, the removal cannot proceed and the original key remains available for recovery.
NEAR also allows AddKey and DeleteKey to be batched in one transaction. That transaction can succeed with the original Ed25519 signature without the new key ever demonstrating control. If the replacement key were registered successfully but the signing system could not use it, the account could be left with no usable signing key.
Splitting the rotation into two transactions, and having the new key sign the removal, costs one extra transaction and prevents that failure mode. Never retire an authority until its replacement has demonstrated control.
After step 4, the account holds exactly one access key, and it is post-quantum:
ml-dsa-65-hash:39RCq4kfAifXhUNxv8Tj8FvDaUAU8cX6WAJA2NDtTwYt FullAccess
The original Ed25519 key, ed25519:J6WHpBTJbvhA14C3ZtJcUFTtyJfe2ugX3cpze5Yr3gV2, can no longer authorize spending from this account, even though its hexadecimal representation still forms the address. DeleteKey revokes that authority; it does not erase private-key copies from the signing system or its backups.
One operational constraint is critical for the Ed25519-derived implicit account used here: preserving the rotation requires keeping the account alive. If the account is deleted, a subsequent qualifying transfer to the same address can recreate it with the original Ed25519 access key, restoring the authority we just revoked. Account-deletion controls therefore form part of the migration procedure.
Steps 1 and 5 demonstrate continuity for incoming payments. Two different outside accounts paid the same address, one before rotation and one after the Ed25519 access key was revoked. The receiving address stayed unchanged, and the later payment succeeded without the sender needing to use the recipient’s new signature scheme.
What It Costs
Steps 2 and 6 compare two transfers from the same account to the same destination, using different signing schemes. The amounts sent differ, but NEAR’s transfer fee does not depend on the value transferred. The amount is also encoded in a fixed-width field, so that difference does not change the transaction size.
| Measurement | Ed25519 (step 2) | ML-DSA-65 (step 6) | Difference |
|---|---|---|---|
| Signature size | 64 B | 3,309 B | +3,245 B |
| Transaction size | 295 B | 5,460 B | +5,165 B |
| Transaction conversion, including signature verification | 824.9 Ggas | 924.9 Ggas | +100 Ggas |
| Charged transfer execution | 7,524.9 Ggas | 7,524.9 Ggas | 0 |
Gas values are rounded to one decimal place in Ggas. The execution row covers the charged transfer receipt; refund receipts with zero token charges are excluded. One TGas equals 1,000 Ggas.
Both transfers consumed identical gas for the charged transfer execution. ML-DSA added 100 Ggas during transaction conversion, matching the protocol’s ml_dsa_65_verification_cost parameter. Under the fee schedule used for this experiment, the additional 5,165 transaction bytes incurred no separate transaction-size fee.
At NEAR’s minimum gas price of 0.0001 NEAR per TGas, that verification premium is 0.00001 NEAR per transaction. The two rotation transactions together cost approximately 0.000093 NEAR.
The completed rotation also leaves access-key storage unchanged. NEAR stores a 32-byte hash of the post-quantum public key in account state instead of the full 1,952-byte key. The complete public key travels in the transaction for verification, without becoming a permanent access-key storage requirement.
Costs will differ on other chains. Where verification must run in contract code, its expense can shape whether post-quantum accounts are practical. Reducing that cost is another strand of our post-quantum work.
Where the Keys Live
A signature scheme is only part of custody. The private key’s location and the controls governing its use matter just as much.
The on-chain rotation sequence above can work with a key held in an HSM or with signing authority distributed through multi-party computation (MPC). The chain validates the resulting signature. What differs is how the signing system produces it and the maturity of that implementation.
For an HSM that supports ML-DSA, the signing model is familiar: generate the key within the module, configure it as non-extractable, and sign through the supported interface. Institutions running Key Link, where key material stays in their own infrastructure, use this custody model. Deploying ML-DSA in that environment depends on the particular HSM and integration supporting it (for example: newer versions of Luna HSM by Thales). The same integration considerations apply to Flexible Deployment setups using an institution’s own HSM or enclave. Our experiment exercised the PKCS#11 interface using a software HSM, and could use a hardware module similarly.
For MPC, signing requires a threshold implementation of ML-DSA. Although research implementations can be found, their suitability for institutional custody must be assessed against requirements beyond producing a valid signature, including robustness, recovery, proactive share refresh, and independently reviewed implementations. Evaluating and addressing those requirements is a substantial part of our research effort. Once a suitable threshold signer is available, it can use the same on-chain rotation flow demonstrated here.
Not Every Chain Works This Way
Where in-place rotation is unavailable, migration may require moving assets to a new account. That introduces additional work: updating deposit instructions and allow-lists, monitoring the old address for incoming funds, and handling positions or permissions tied to it. Custody platforms already manage many of these operations, but their sequencing and controls must be worked out for each chain and account type.
The Scheme Is Only One Part of the Puzzle
Scaling this process across a custody platform requires more than a successful rotation. It requires knowing which accounts hold which key types, on which chains, and which can rotate in place. It requires a process that adds the new authority, demonstrates control, and retires the old one under the institution’s established approvals and controls. The operation must be visible while it runs and auditable afterwards: a half-completed rotation across a large book of accounts is its own kind of incident.
The surrounding infrastructure needs the same scrutiny: transport security, backups, firmware where relevant, and the trust chains used to enrol keys. Adopting a post-quantum signing key is one step in securing that broader system.
These requirements make key management and operational control central to migration. They determine how an institution moves from its existing keys to new signing schemes while preserving accountability and control throughout the process.
No one does that part alone. Chain protocols determine which signing schemes and migration mechanisms are available. Wallet and hardware vendors determine which keys their products can manage. A custodian determines how the operation is governed, sequenced, and evidenced.
What this run demonstrates is deliberately narrow: an ML-DSA key, held behind a PKCS#11 interface, can take over signing authority on an existing NEAR account. The account retains its address, accepts incoming payments, and sends funds using the new key. The quantum readiness of consensus, surrounding infrastructure, and custody controls requires separate assessment. The same on-chain sequence can support MPC-held keys once a suitable threshold ML-DSA implementation is available. Doing this once, on one account, is just a demonstration. Making it repeatable and auditable across chains, account types and custody models is the operational challenge. That is the migration problem we are working to solve.
