Short answer
The answer in plain English
NEAR can now authorize transactions with ML-DSA-65, a post-quantum signature standard designed to resist attacks from large quantum computers. That gives accounts a migration path away from vulnerable classical keys. It does not automatically protect every wallet: software must support the new key type, users must add it correctly, and any old full-access key must be removed or it can remain the weakest route into the account.
Why it matters
What to understand
NEAR’s 2.13 upgrade added optional ML-DSA-65 transaction signatures. NEAR accounts can hold and rotate multiple access keys, so a user can add a post-quantum key without moving assets to a new address. The network stores a compact identifier on-chain and verifies the larger public key and signature when a transaction arrives. The design is a real migration tool, not proof that quantum theft is imminent or that wallets and custodians have already adopted it.
Visual guide
How the pieces fit together
The upgrade changes the lock, not the whole building
A wallet does not prove ownership by showing the network a secret. It uses a private key to create a digital signature, and the network checks that signature against a public key. The private key stays with the signer; the signature proves that an authorized key approved this specific transaction.
Most major blockchains use signature systems built on mathematical problems that conventional computers cannot solve efficiently. A sufficiently large, fault-tolerant quantum computer could change that assumption through Shor’s algorithm. The concern is not that a quantum machine rewrites a blockchain’s history. It is that the machine derives a private key from exposed public information and forges a valid-looking transaction.
NEAR’s 2.13 upgrade addresses that authorization path. It lets an account use ML-DSA-65, part of the signature family standardized by the U.S. National Institute of Standards and Technology in FIPS 204. NIST describes ML-DSA as a digital-signature standard believed to remain secure against an adversary with a large-scale quantum computer.
This does not mean such a computer exists today. If you want the underlying distinction between ordinary and quantum computation, start with how qubits and interference work. The reason to add a migration path early is that changing authentication across wallets, exchanges, custodians, and applications takes time.
Why NEAR can rotate an account’s keys
On many blockchains, an address is closely derived from one public key. Replacing the key can therefore mean creating a new address and moving assets and application permissions.
NEAR separates the named account from its access keys. An account can have multiple keys with different permissions, and those keys can be added or removed. That lets a user attach an ML-DSA key to an existing account rather than abandon the account’s identity.
A careful migration looks like changing a lock while you still possess the old key. The user first generates the post-quantum key pair in supported software. A currently authorized key signs the transaction that adds the new public key. The user then verifies that the new key can sign correctly before removing the old full-access key.
How NEAR handles much larger keys
Post-quantum signatures are substantially larger than common classical blockchain signatures. The video’s example gives an ML-DSA-65 public key as 1,952 bytes and a signature as 3,309 bytes. Repeating the full key in an account’s ordinary on-chain access-key list would increase storage costs.
NEAR therefore uses a compact identifier for the on-chain record. When a signed transaction arrives, it carries the larger public key and signature needed for verification. The network can hash the supplied key, match it with the account’s registered identifier, and then verify the ML-DSA signature.
That design reduces persistent storage, but it does not make the larger cryptography free. Transactions still carry more data. Nodes perform different verification work. Wallets, hardware devices, exchanges, browser extensions, and custody systems all need compatible implementations and recovery procedures.
Standards define an algorithm; they do not guarantee that every integration uses it safely.
The old key can remain the weak door
Adding an ML-DSA key does not cancel other keys. If an old Ed25519 full-access key remains attached, anyone who can forge that older signature may still authorize transfers or change the account’s keys.
Removing the old key is therefore part of the security transition, not a cleanup detail. It also creates a recovery question. A user who deletes a familiar recovery route before confirming support for the new one can lock themselves out. Custodians may require multi-party authorization, audits, backups, and tested incident procedures before they can migrate.
The same logic applies to limited-access keys. Their risk depends on what they are allowed to do. A key that can call only one contract method is not equivalent to a key that can replace every key and transfer every asset.
What ML-DSA does not protect
ML-DSA-65 protects signatures made with that key type. It does not automatically make every component of NEAR post-quantum secure. Bridges, websites, smart-contract logic, exchange accounts, recovery services, endpoint devices, and social-engineering processes can fail without breaking any signature algorithm.
It also does not retroactively protect an account whose classical key remains active. Nor does it prevent a person from approving a malicious transaction with the new key. Cryptographic strength cannot tell whether the instruction itself is wise.
The 2.13 release also introduced dynamic resharding, which changes how the network can split work as demand grows. That scalability feature arrived in the same upgrade but solves a different problem. More shards do not make a signature quantum-resistant; ML-DSA does not remove cross-shard coordination costs.
A migration advantage, not a finished migration
NEAR now has a network-level path for post-quantum transaction signing. Its rotatable account keys make that path unusually direct: users can change authorization without necessarily changing the account they use.
The remaining work is adoption. Wallet interfaces must make key creation, verification, removal, and backup understandable. Exchanges and custodians need operational support. Developers need to test size and fee consequences. Users need a safe sequence that does not leave the old door open or close every door at once.
So the answer is conditional. NEAR can protect an account’s transaction authorization with a post-quantum key. A wallet becomes meaningfully protected only when the whole key lifecycle—not just the algorithm name—has migrated.
