$NEAR supports post-quantum account signatures, but that does not mean the entire chain has completed its post-quantum migration. The topic currently ranked sixth on the Plaza is worth examining more closely, but the technical milestones it refers to date from July and September and should not be presented as a brand-new feature launched today.
The first layer is how accounts authorize transactions. nearcore 2.13.0 was released on July 9 and introduced ML-DSA-65 as a third transaction-signature and access-key type, alongside the two existing types. This gives accounts a new signature-verification option, but it does not automatically rotate the keys of every existing account, nor does it confirm that all accounts have adopted the new algorithm.
The second layer is whether contracts can verify a message. The September 16 testnet release candidate, 2.14.0-rc.1, added the ml_dsa_verify interface for contracts to verify messages. This is a different entry point from native account transaction authorization: a contract's ability to verify a signature does not in itself prove that all the operations it controls, external assets, or cross-chain messages have completed a secure migration. Nor should a testnet candidate be described as already deployed on mainnet.
Only the third layer concerns the migration scope of the system as a whole. Account signatures are just one part of it. Which protocol version nodes are running, how existing keys are updated, and how other dependencies are handled all require separate evidence. The adoption of a new algorithm by one module does not mean every layer of the system has the same level of protection.
The timeline also needs to be kept clear. The July 2 developer notes show a demo of adding a key and transferring funds in a sandbox environment; July 9 was the release of a version intended for mainnet; and that release separately listed plans to start a protocol vote on July 20. A successful demo, a software release, a vote plan, and activation on the live network are not the same state of completion. We have not verified the outcome of the network-wide upgrade in this round, so we are not treating the planned date as proof of deployment.
For ordinary users, the more specific questions are whether their account is actually configured with this kind of access key, whether their wallet can correctly generate, store, and use it to sign, and whether their application supports the relevant workflow. A news headline alone cannot tell you whether the account you hold is already protected by the new signature scheme. After adding a new key, you should also check the account's actual settings to understand how the old key's permissions are handled.
For developers, it is important to distinguish native account transactions from contract-based message verification. The former concerns who can authorize account operations; the latter concerns how a program determines whether a message is valid. A successful signature check does not mean the message's content, permission scope, or business logic is automatically correct. The security boundary must be defined by the actual authorization workflow.
The milestones I am watching next are records of the final release and protocol activation, wallet support, and clear migration guidance. What can be confirmed now is that NEAR is advancing different capabilities at the account and contract signature-verification layers. What cannot be confirmed is that all legacy accounts, applications, and external dependencies have migrated together. This is an observation about the technical scope, not a prediction of price direction based on the algorithm's name.
The first layer is how accounts authorize transactions. nearcore 2.13.0 was released on July 9 and introduced ML-DSA-65 as a third transaction-signature and access-key type, alongside the two existing types. This gives accounts a new signature-verification option, but it does not automatically rotate the keys of every existing account, nor does it confirm that all accounts have adopted the new algorithm.
The second layer is whether contracts can verify a message. The September 16 testnet release candidate, 2.14.0-rc.1, added the ml_dsa_verify interface for contracts to verify messages. This is a different entry point from native account transaction authorization: a contract's ability to verify a signature does not in itself prove that all the operations it controls, external assets, or cross-chain messages have completed a secure migration. Nor should a testnet candidate be described as already deployed on mainnet.
Only the third layer concerns the migration scope of the system as a whole. Account signatures are just one part of it. Which protocol version nodes are running, how existing keys are updated, and how other dependencies are handled all require separate evidence. The adoption of a new algorithm by one module does not mean every layer of the system has the same level of protection.
The timeline also needs to be kept clear. The July 2 developer notes show a demo of adding a key and transferring funds in a sandbox environment; July 9 was the release of a version intended for mainnet; and that release separately listed plans to start a protocol vote on July 20. A successful demo, a software release, a vote plan, and activation on the live network are not the same state of completion. We have not verified the outcome of the network-wide upgrade in this round, so we are not treating the planned date as proof of deployment.
For ordinary users, the more specific questions are whether their account is actually configured with this kind of access key, whether their wallet can correctly generate, store, and use it to sign, and whether their application supports the relevant workflow. A news headline alone cannot tell you whether the account you hold is already protected by the new signature scheme. After adding a new key, you should also check the account's actual settings to understand how the old key's permissions are handled.
For developers, it is important to distinguish native account transactions from contract-based message verification. The former concerns who can authorize account operations; the latter concerns how a program determines whether a message is valid. A successful signature check does not mean the message's content, permission scope, or business logic is automatically correct. The security boundary must be defined by the actual authorization workflow.
The milestones I am watching next are records of the final release and protocol activation, wallet support, and clear migration guidance. What can be confirmed now is that NEAR is advancing different capabilities at the account and contract signature-verification layers. What cannot be confirmed is that all legacy accounts, applications, and external dependencies have migrated together. This is an observation about the technical scope, not a prediction of price direction based on the algorithm's name.