--- title: "ECDSA on secp256r1: which blockchains use it" url: "https://hardyindex.com/algorithms/ecdsa-secp256r1" --- # ECDSA on secp256r1 The Elliptic Curve Digital Signature Algorithm over the NIST P-256 curve, also named secp256r1. It is the curve in most passkeys, secure enclaves and hardware security modules, which is why chains offer it as an account option. Broken by Shor's algorithm on a cryptographically relevant quantum computer, which recovers the private key from the public key. - **Quantum status:** Broken by Shor's algorithm on a cryptographically relevant quantum computer. - **Standard:** FIPS 186-5 (P-256) (NIST, final). - **Family:** elliptic curve. - **Also known as:** secp256r1, P-256, prime256v1. ## Rated chains using it - [Aptos](https://hardyindex.com/chains/aptos.md): account signatures, mainnet, opt-in. WebAuthn (passkey) accounts sign with Secp256r1 ECDSA under the generalised scheme. Keyless accounts, which authenticate through an OpenID login and a zero-knowledge proof, are a further option the registry has no entry for; none of these options is post-quantum. Source (specification or proposal): https://aptos.dev/network/blockchain/accounts - [Chiliz Chain](https://hardyindex.com/chains/chiliz.md): contract level, mainnet, opt-in. P-256 verification precompile in the Prague precompile set, active on mainnet since the Pectra hard fork of 30 June 2026. Source (source code or release): https://github.com/chiliz-chain/v2/blob/v2.9.5/core/vm/contracts.go - [Conflux](https://hardyindex.com/chains/conflux.md): contract level, mainnet, opt-in. P-256 verification precompile under CIP-167, following EIP-7951, activated in the v3.1 hard fork. Source (specification or proposal): https://doc.confluxnetwork.org/docs/general/hardforks/v3.1/ - [Flare](https://hardyindex.com/chains/flare.md): validator consensus, mainnet, default. New staking certificates are generated with ECDSA on P-256, and proposervm signs each proposed block with the staking key. The signature identifies the proposer the stake-weighted windower picked for that slot; Snowman finalises blocks by repeated sub-sampled voting among validators, not by collecting signatures. Signature checks also accept RSA certificates, which the registry does not yet list. Source (source code or release): https://github.com/flare-foundation/go-flare/blob/main/avalanchego/staking/tls.go - [Gnosis Chain](https://hardyindex.com/chains/gnosis.md): contract level, mainnet, opt-in. EIP-7951 P-256 precompile, activated unmodified in the Fusaka upgrade on 14 April 2026. Source (specification or proposal): https://github.com/gnosischain/specs/blob/master/network-upgrades/fusaka.md - [IOTA](https://hardyindex.com/chains/iota.md): account signatures, mainnet, opt-in. Chosen account by account; Ed25519 stays the default. Source (specification or proposal): https://docs.iota.org/developer/cryptography/transaction-auth/signatures - [Monad](https://hardyindex.com/chains/monad.md): contract level, mainnet, opt-in. P-256 precompile at 0x0100 (EIP-7951), used by smart accounts for passkeys. Source (specification or proposal): https://docs.monad.xyz/developer-essentials/precompiles - [Neo](https://hardyindex.com/chains/neo.md): account signatures, mainnet, default. Standard accounts verify through System.Crypto.CheckSig and CheckMultisig on secp256r1. An account is a script hash, so a contract account can verify differently. Source (source code or release): https://github.com/neo-project/neo/blob/master/src/Neo/SmartContract/ApplicationEngine.Crypto.cs - [Neo](https://hardyindex.com/chains/neo.md): validator consensus, mainnet, mandatory. dBFT committee and validator keys are secp256r1 points. Source (source code or release): https://github.com/neo-project/neo/blob/master/src/Neo/ProtocolSettings.cs - [Polygon PoS](https://hardyindex.com/chains/polygon-pos.md): contract level, mainnet, opt-in. P-256 verification precompile following RIP-7212, used by smart accounts for passkeys. Final, shipped in the Napoli hard fork. Source (specification or proposal): https://github.com/0xPolygon/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-27.md - [Tezos](https://hardyindex.com/chains/tezos.md): account signatures, mainnet, opt-in. tz3 addresses, P-256. Source (specification or proposal): https://octez.tezos.com/docs/active/accounts.html - [Tezos](https://hardyindex.com/chains/tezos.md): validator consensus, mainnet, opt-in. A baker's consensus key may be a tz3 key, P-256. Source (specification or proposal): https://octez.tezos.com/docs/user/key-management.html - [Vaulta](https://hardyindex.com/chains/vaulta.md): account signatures, mainnet, opt-in, R1. 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 - [Vaulta](https://hardyindex.com/chains/vaulta.md): account signatures, mainnet, opt-in, WebAuthn (WA). 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 ## Sources - [FIPS 186-5: Digital Signature Standard (DSS)](https://csrc.nist.gov/pubs/fips/186-5/final), NIST. Accessed 21 October 2026.