--- title: Is Vaulta quantum-safe? chain: Vaulta ticker: A hardy_score: 10 rank: 48 of 80 tier: "5: Exposed" url: "https://hardyindex.com/chains/vaulta" updated: 2026-10-22 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is Vaulta quantum-safe? **Hardy Score 10.0 / 100. Rank 48 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.** No. Vaulta is the network previously called EOS: in 2025 it took a new name and a new native token, A, swapped one for one with EOS, and in the Vaulta Foundation's own words it "operates using the same mainnet that was previously called the EOS Network". Its node software is Spring, from the Antelope codebase. Every Vaulta account is a short name, and what controls it is a set of permissions holding public keys of three types: K1 (ECDSA on secp256k1), R1 (ECDSA on P-256) and WA (WebAuthn, also P-256). Block producers sign blocks with secp256k1 keys, and since the Savanna consensus upgrade of 25 September 2024 finality comes from finalizers voting with BLS12-381 keys. A sufficiently large quantum computer running Shor's algorithm would break all of these. Vaulta does have a real key-replacement mechanism: an account's keys can be changed in place with the updateauth action, keeping the account name and its funds, and the network has added a key type before, activating WebAuthn keys as a protocol feature in July 2021. But no post-quantum key type has been proposed, and no post-quantum plan, proposal or research programme was found from the Vaulta Foundation, in the Spring or Vaulta Foundation repositories, or in the network's documentation, which is why Vaulta sits in Tier 5. > This is a security-readiness assessment, not investment advice. ## Summary Named accounts on Vaulta, the network formerly called EOS, are controlled by secp256k1, P-256 or WebAuthn keys published in on-chain permission tables, finality rests on BLS12-381 votes, and no post-quantum plan, proposal or research programme was found. ## Where we are making a judgement call Three judgement calls carry this profile. The first is migration. The updateauth action and the 2021 WebAuthn activation are credited above the floor because a working route already exists for replacing an account's keys without moving its funds, and the network has shown it can add a key type by protocol feature; a reader who credits nothing short of a post-quantum key type would score 2 and take 1.5 points off, and a reader who weighs the precedent more heavily would score 4 and add 1.5. The second is exposure. Vaulta's keys are published in permission tables rather than hidden behind hashes, which places it with the address-is-key chains; a reader who scores that structure at 3 rather than reading it as exposure of effectively all accounts would add 1 point. The third concerns control rather than score. The privileged eosio system account, and the vaulta account that owns the core.vaulta token contract, are both controlled on-chain by eosio.prods, the active block producers acting by a 15-of-21 multisig, so the producers can replace system contracts and change any account's permissions. That is how Antelope chains are governed by design and it is not scored, but it means the same producer supermajority that could ship a post-quantum key type could also rewrite any account's keys. The tier is not a judgement call: no post-quantum work on Vaulta's signatures was found from anyone with authority over the chain, so no reading of the record lifts it to Tier 4. ## Score breakdown | # | Dimension | Score | Weight | Contribution | |---:|---|---:|---:|---:| | 1 | Signature scheme | 0/10 | 30% | 0.0 | | 2 | Deployment stage | 1/10 | 25% | 2.5 | | 3 | NIST alignment | 0/10 | 15% | 0.0 | | 4 | Migration path | 3/10 | 15% | 4.5 | | 5 | Exposure | 2/10 | 10% | 2.0 | | 6 | Verification | 2/10 | 5% | 1.0 | | | **Hardy Score** | | | **10.0** | ### 1. Signature scheme: 0/10 Anchor band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on. Spring defines exactly three public key and signature types, K1 (secp256k1), R1 (P-256) and WebAuthn (P-256), and every account permission is satisfied by one of them. Block producers sign with secp256k1 keys and finalizers vote with BLS12-381 keys. Nothing post-quantum protects A or any asset on Vaulta today. Source: https://github.com/AntelopeIO/spring/blob/main/libraries/libfc/include/fc/crypto/public_key.hpp ### 2. Deployment stage: 1/10 Anchor band 1: Tier 5: Exposed. Tier 5: Exposed. The signatures that authorise spends and finalise blocks are quantum-vulnerable, and no post-quantum roadmap, improvement proposal or research programme was found from the Vaulta Foundation, in the Spring repository or in the Vaulta Foundation's repositories. Source: https://github.com/AntelopeIO/spring ### 3. NIST alignment: 0/10 Anchor band 0 to 2: No post-quantum scheme named for the chain’s fund-protecting signatures, or a proprietary scheme with no public cryptanalysis. No post-quantum scheme has been named for Vaulta's account keys, producer signatures or finalizer votes. The Spring repository and the Vaulta Foundation's repositories contain no post-quantum signature work, and the network's documentation does not mention one. Placement in the band: The floor of the band rather than a 1 or a 2: no one with authority over Vaulta has named a post-quantum scheme for any of its signatures, so there is nothing to place against a standard. Source: https://github.com/AntelopeIO/spring/blob/main/libraries/libfc/include/fc/crypto/signature.hpp ### 4. Migration path: 3/10 Anchor band 3 to 5: Migration is acknowledged as a problem with no agreed mechanism, or the mechanism is contested. Vaulta accounts are names, not hashes of keys, and the updateauth action replaces the keys behind any permission in place, so a holder can move to a new key without moving funds or changing the account. The network has also added a key type before: WebAuthn keys were activated as a protocol feature on 21 July 2021. But every key type accepted today is classical, a post-quantum one would need a new protocol feature, and none has been proposed. Placement in the band: The floor of the band rather than a 4 or a 5: the rotation mechanism is live and keeps the account, and adding a key type has a precedent, but no post-quantum key type has been proposed and no published plan or discussion of one was found. Above a 2, because the mechanism a migration would need already exists on mainnet. Source: https://github.com/AntelopeIO/spring/blob/main/libraries/chain/eosio_contract.cpp ### 5. Exposure: 2/10 Anchor band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses. A Vaulta account is a name, and the public keys that control it are stored in the account's permissions on-chain, readable by anyone through any API node before the account has ever signed. Every account controlled by a key has that key published from the moment it is set, so there is no unexposed share for hashing to protect. Placement in the band: The top of the band rather than a 0 or a 1: Vaulta meets the band on its structural limb, with keys readable from account permissions, but no measured share of exposed supply has been published. Not a 3, because the exposure covers effectively every key-controlled account, not only those that have signed. Source: https://vaulta.gitbook.io/vaulta-guides/accounts/vaulta-native-accounts/account-permissions ### 6. Verification: 2/10 Anchor band 0 to 2: No post-quantum component exists, or the claims rest on marketing. No post-quantum component exists for Vaulta's signatures: no code, specification or testnet implementation was found in Spring or the Vaulta Foundation's repositories. Spring is open source, but under v1.8 the openness of classical code earns nothing here. Placement in the band: The top of the band rather than a 0 or a 1: there is no post-quantum component to verify, but nothing about Vaulta is marketed as quantum-safe, so its position does not rest on marketing. Source: https://github.com/AntelopeIO/spring ## Nearest chains in the ranking The chains Vaulta sits among, out of 80 rated. The last column is the gap in Hardy points from Vaulta. | Rank | Chain | Tier | Hardy | vs A | |---:|---|---|---:|---:| | 44 | [Litecoin](https://hardyindex.com/chains/litecoin) | 5: Exposed | 10.5 | +0.5 | | 45 | [Midnight](https://hardyindex.com/chains/midnight) | 5: Exposed | 10.5 | +0.5 | | 46 | [Qtum](https://hardyindex.com/chains/qtum) | 5: Exposed | 10.5 | +0.5 | | 47 | [Kaia](https://hardyindex.com/chains/kaia) | 5: Exposed | 10.0 | level | | 48 | **Vaulta** | 5: Exposed | 10.0 | this chain | | 49 | [Dogecoin](https://hardyindex.com/chains/dogecoin) | 5: Exposed | 9.0 | -1.0 | | 50 | [0G](https://hardyindex.com/chains/0g) | 5: Exposed | 8.5 | -1.5 | | 51 | [AIOZ Network](https://hardyindex.com/chains/aioz) | 5: Exposed | 8.5 | -1.5 | | 52 | [Akash Network](https://hardyindex.com/chains/akash) | 5: Exposed | 8.5 | -1.5 | ## Signature scheme - **On mainnet today:** ECDSA on secp256k1 (K1), ECDSA on P-256 (R1) or WebAuthn P-256 (WA) for account permissions; secp256k1 for block producer signatures; BLS12-381 for Savanna finalizer votes - **Post-quantum scheme:** None selected or proposed. - **NIST standard:** None adopted. - **Readiness tier:** Tier 5: Exposed. The signatures securing funds on mainnet today are quantum-vulnerable, and no public post-quantum plan, proposal or research programme addressing them could be found. ## Cryptography in use - **Account signatures:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md) (K1). Mainnet, default. K1 keys, written with the legacy EOS prefix or PUB_K1_, are what wallets create by default and what controls almost every account. Source (source code or release): https://github.com/AntelopeIO/spring/blob/main/libraries/libfc/include/fc/crypto/public_key.hpp - **Account signatures:** [ECDSA on secp256r1](https://hardyindex.com/algorithms/ecdsa-secp256r1.md) (R1). Mainnet, opt-in. R1 keys on the P-256 curve, chosen permission by permission. Source (source code or release): https://github.com/AntelopeIO/spring/blob/main/libraries/libfc/include/fc/crypto/public_key.hpp - **Account signatures:** [ECDSA on secp256r1](https://hardyindex.com/algorithms/ecdsa-secp256r1.md) (WebAuthn (WA)). Mainnet, opt-in. WebAuthn keys over P-256, activated as the WEBAUTHN_KEY protocol feature at block 195,440,162 on 21 July 2021. Source (read on-chain): https://eos.greymass.com/v1/chain/get_activated_protocol_features - **Validator consensus:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, mandatory. The 21 active block producers' block signing authorities in the producer schedule are secp256k1 keys. Source (read on-chain): https://eos.greymass.com/v1/chain/get_producer_schedule - **Validator consensus:** [BLS signatures on BLS12-381](https://hardyindex.com/algorithms/bls12-381.md). Mainnet, mandatory. Savanna finality: the active finalizer policy lists 21 finalizers with BLS12-381 public keys and a threshold of 15. Activated with the SAVANNA protocol feature at block 396,090,329 on 25 September 2024. Source (read on-chain): https://eos.greymass.com/v1/chain/get_finalizer_info A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **21 July 2021** (shipped): The WEBAUTHN_KEY protocol feature activates on mainnet at block 195,440,162, adding WebAuthn keys over P-256 as a third account key type. It shows that a new key type can be added by protocol feature; the type added was classical. Source: https://eos.greymass.com/v1/chain/get_activated_protocol_features - **25 September 2024** (shipped): The SAVANNA protocol feature activates on mainnet at block 396,090,329, moving finality to votes from finalizers signing with BLS12-381 keys. Source: https://eos.greymass.com/v1/chain/get_activated_protocol_features - **14 May 2025** (shipped): The core.vaulta contract, through which the new A token is swapped one for one with EOS, is set to the Vaulta system contract v1.0.0, which the Vaulta Foundation released on 2 May 2025: the chain records the setcode action on 14 May 2025, and the account's code hash matches the release's published checksum. The Vaulta Foundation states that Vaulta is the same mainnet with all state history intact; account keys are unchanged. Source: https://eos.hyperion.eosrio.io/v2/history/get_actions?account=core.vaulta&filter=eosio:setcode&sort=asc&limit=5 - **No date published** (proposed): No post-quantum key type, improvement proposal, research programme, implementation or testnet for Vaulta's account, producer or finalizer signatures was found at the time of writing. Source: https://github.com/AntelopeIO/spring ## If holders never migrate **No stated policy.** Neither the Vaulta Foundation nor the network's block producers have said anything about accounts that never move to post-quantum keys, because no post-quantum key type has been proposed. As of 22 October 2026. ## Exposure Vaulta does not hash keys into addresses. An account is a name of up to twelve characters, and its owner, active and custom permissions each list the public keys or other accounts that control it. Those keys sit in chain state and any API node returns them on request, so every key-controlled account has its public key published from the moment the key is set, whether or not it has ever signed. Permissions delegated to other accounts resolve in the end to keys that are just as visible. Block producer signing keys and finalizer BLS keys are public by design. Vaulta is the EOS mainnet under a new name rather than a fork, so its history is its own and the exposure inheritance rule does not apply. No measurement of exposed supply has been published, and none is needed to see that it is effectively all of it. ## Frequently asked questions ### Is Vaulta quantum-safe? No. Vaulta is the network previously called EOS: in 2025 it took a new name and a new native token, A, swapped one for one with EOS, and in the Vaulta Foundation's own words it "operates using the same mainnet that was previously called the EOS Network". Its node software is Spring, from the Antelope codebase. Every Vaulta account is a short name, and what controls it is a set of permissions holding public keys of three types: K1 (ECDSA on secp256k1), R1 (ECDSA on P-256) and WA (WebAuthn, also P-256). Block producers sign blocks with secp256k1 keys, and since the Savanna consensus upgrade of 25 September 2024 finality comes from finalizers voting with BLS12-381 keys. A sufficiently large quantum computer running Shor's algorithm would break all of these. Vaulta does have a real key-replacement mechanism: an account's keys can be changed in place with the updateauth action, keeping the account name and its funds, and the network has added a key type before, activating WebAuthn keys as a protocol feature in July 2021. But no post-quantum key type has been proposed, and no post-quantum plan, proposal or research programme was found from the Vaulta Foundation, in the Spring or Vaulta Foundation repositories, or in the network's documentation, which is why Vaulta sits in Tier 5. ### Is Vaulta quantum-safe? No. Vaulta accounts are controlled by secp256k1, P-256 or WebAuthn keys, block producers sign with secp256k1 keys, and finalizers vote with BLS12-381 keys. A sufficiently large quantum computer would break all of them. Nothing post-quantum protects A on mainnet today. ### Is Vaulta the same chain as EOS? Yes. The Vaulta Foundation says Vaulta operates on the same mainnet previously called the EOS Network, with all state history intact. What changed in 2025 was the name and the native token: A replaced EOS one for one through the core.vaulta contract. Account names and keys did not change, so the quantum position is the one EOS had. ### Can Vaulta accounts change their keys without moving funds? Yes, for the key types the chain accepts today. The updateauth action replaces the keys behind any permission while the account name and balance stay where they are. That is the mechanism a post-quantum migration would need, but all three accepted key types are classical, so a post-quantum key type would first have to be added by a protocol feature, as WebAuthn keys were in 2021. ### Why does Vaulta score badly on exposure? Because its accounts are names and their public keys are stored openly in the account's permissions. On chains where an address is a hash of a key, an account that has never signed keeps its key private. On Vaulta every key-controlled account's public key is readable from chain state from the moment it is set, so classical balances are exposed to harvest-now-decrypt-later collection today. ### What would move Vaulta up the index? A formal proposal or a public research programme by the Vaulta Foundation or the Spring developers on post-quantum keys for Vaulta would meet the Tier 4 floor. A published plan naming the post-quantum scheme Vaulta will add as an account key type would meet Tier 3, and with updateauth already live, holders could then move across without changing accounts. ## What this rating means if you hold Vaulta Plain-language guidance from the same publication, with no product recommendation attached. - [Is my crypto safe from quantum computers?](https://hardyindex.com/guides/is-my-crypto-safe-from-quantum-computers.md) - [How to protect your crypto from quantum computers](https://hardyindex.com/guides/how-to-protect-crypto-from-quantum-computers.md) - [All guides](https://hardyindex.com/guides.md) ## Sources 1. [Spring node software](https://github.com/AntelopeIO/spring): AntelopeIO (GitHub) (primary, checked 22 October 2026) 2. [Public key types (libraries/libfc/include/fc/crypto/public_key.hpp)](https://github.com/AntelopeIO/spring/blob/main/libraries/libfc/include/fc/crypto/public_key.hpp): AntelopeIO (GitHub) (primary, checked 22 October 2026) 3. [Signature types (libraries/libfc/include/fc/crypto/signature.hpp)](https://github.com/AntelopeIO/spring/blob/main/libraries/libfc/include/fc/crypto/signature.hpp): AntelopeIO (GitHub) (primary, checked 22 October 2026) 4. [BLS public keys (libraries/libfc/include/fc/crypto/bls_public_key.hpp)](https://github.com/AntelopeIO/spring/blob/main/libraries/libfc/include/fc/crypto/bls_public_key.hpp): AntelopeIO (GitHub) (primary, checked 22 October 2026) 5. [Native actions including updateauth (libraries/chain/eosio_contract.cpp)](https://github.com/AntelopeIO/spring/blob/main/libraries/chain/eosio_contract.cpp): AntelopeIO (GitHub) (primary, checked 22 October 2026) 6. [Protocol features (libraries/chain/include/eosio/chain/protocol_feature_manager.hpp)](https://github.com/AntelopeIO/spring/blob/main/libraries/chain/include/eosio/chain/protocol_feature_manager.hpp): AntelopeIO (GitHub) (primary, checked 22 October 2026) 7. [Activated protocol features (mainnet API)](https://eos.greymass.com/v1/chain/get_activated_protocol_features): Greymass API node, Vaulta mainnet (primary, checked 22 October 2026) 8. [Active finalizer policy (mainnet API)](https://eos.greymass.com/v1/chain/get_finalizer_info): Greymass API node, Vaulta mainnet (primary, checked 22 October 2026) 9. [Active producer schedule (mainnet API)](https://eos.greymass.com/v1/chain/get_producer_schedule): Greymass API node, Vaulta mainnet (primary, checked 22 October 2026) 10. [Chain info (mainnet API)](https://eos.greymass.com/v1/chain/get_info): Greymass API node, Vaulta mainnet (primary, checked 22 October 2026) 11. [Vaulta FAQ](https://vaulta.gitbook.io/vaulta-guides/user-guides/support/faqs/vaulta): Vaulta Foundation (primary, checked 22 October 2026) 12. [Account Permissions](https://vaulta.gitbook.io/vaulta-guides/accounts/vaulta-native-accounts/account-permissions): Vaulta Foundation (primary, checked 22 October 2026) 13. [Savanna Consensus](https://vaulta.gitbook.io/vaulta-guides/networks/vaulta-native/savanna-consensus): Vaulta Foundation (primary, checked 22 October 2026) 14. [DPoS Consensus](https://vaulta.gitbook.io/vaulta-guides/node-operators/dpos-consensus): Vaulta Foundation (primary, checked 22 October 2026) 15. [Accounts](https://docs.vaulta.com/docs/latest/core-concepts/accounts/): Vaulta Foundation (primary, checked 22 October 2026) 16. [Vaulta token and system contract](https://github.com/VaultaFoundation/vaulta-system-contract): Vaulta Foundation (GitHub) (primary, checked 22 October 2026) 17. [Vaulta System Contract 1.0.0 release](https://github.com/VaultaFoundation/vaulta-system-contract/releases/tag/v1.0.0): Vaulta Foundation (GitHub) (primary, checked 22 October 2026) 18. [core.vaulta setcode actions (mainnet history API)](https://eos.hyperion.eosrio.io/v2/history/get_actions?account=core.vaulta&filter=eosio:setcode&sort=asc&limit=5): EOS Rio Hyperion API node, Vaulta mainnet (primary, checked 22 October 2026) ## How to cite this rating A rating is only true as of the day it was reviewed, so both forms carry the review date and the methodology version. If you are quoting the score, quote those too. The Hardy Index (2026). Vaulta: quantum readiness assessment. Hardy Score 10.0 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/vaulta ```bibtex @misc{hardyindex_vaulta_2026, author = {{The Hardy Index}}, title = {Vaulta: quantum readiness assessment}, year = {2026}, howpublished = {\url{https://hardyindex.com/chains/vaulta}}, note = {Hardy Score 10.0 of 100, Tier 5: Exposed. Methodology v1.8}, urldate = {2026-11-13} } ``` --- Methodology: https://hardyindex.com/methodology (v1.8). Cite as: The Hardy Index, "Vaulta", https://hardyindex.com/chains/vaulta, as of 13 November 2026.