{
  "id": "near",
  "name": "NEAR",
  "type": "Sharded PoS L1",
  "reviewed": "2026-07-03",
  "summary": "NEAR is a sharded proof-of-stake L1, and its deployed mainnet default is not quantum-resistant: account and access keys (Ed25519 / secp256k1), Chain Signatures MPC (threshold ECDSA + FROST EdDSA + BLS12-381), validator, consensus and light-client signatures, on-chain VRF randomness, and P2P transport are all Shor-breakable. Widely mis-reported point, verified first-hand: the post-quantum scheme NEAR added is FIPS 204 ML-DSA-65 (a NIST lattice signature) — NOT Falcon — and it is an opt-in THIRD transaction/access-key scheme alongside Ed25519/secp256k1 (gated behind the PostQuantumSignatures feature, stabilizing at protocol v85, ~July 2026), scoped to signing and access keys only (not validators, consensus, or networking). Because it is live on testnet only with no wallet support, it does not yet meet the framework's election-route pass conditions (fails E3/E4), so accounts still score fail — the framework does credit freely electable PQ options once they are audited, on mainnet, and wallet-accessible. Only the hash-based state trie and the crypto-free Wasm VM pass. Verified against nearcore PR #15731, the 2.13.0 release candidates, and the NEAR protocol spec (July 2026).",
  "links": {
    "nearcore 2.13.0-rc.2": "https://github.com/near/nearcore/releases/tag/2.13.0-rc.2",
    "ML-DSA-65 PR (#15731)": "https://github.com/near/nearcore/pull/15731",
    "PQ signatures design doc": "https://github.com/near/nearcore/blob/2.13.0-rc.1/docs/architecture/how/post_quantum_signatures.md",
    "Account spec (Nomicon)": "https://nomicon.io/DataStructures/Account",
    "Chain Signatures (MPC)": "https://github.com/near/mpc"
  },
  "assessment": {
    "1.1": { "verdict": "fail", "scheme": "Ed25519 / secp256k1 access keys", "why": "NEAR accounts sign with Ed25519 (implicit accounts) or secp256k1 (ETH-implicit), both Shor-breakable. NEAR added FIPS 204 ML-DSA-65 (not Falcon) as an opt-in THIRD scheme in release candidate 2.13.0-rc.1/rc.2, gated behind the PostQuantumSignatures feature (stabilizing at protocol v85, ~July 2026); it does not replace the default, so mainnet accounts remain classical. Fails the election route at E3: ML-DSA-65 (FIPS 204) clears the finalized-standard bar, but nearcore 2.13 is live on testnet only, not mainnet, and no generally available or hardware wallet supports the key type (E4).", "sources": ["https://nomicon.io/DataStructures/Account", "https://github.com/near/nearcore/pull/15731"] },
    "1.2": { "verdict": "fail", "scheme": "Ed25519 / secp256k1 keys", "why": "Wallets store the same Shor-breakable Ed25519 / secp256k1 private keys; PQ custody only follows if an account opts into ML-DSA-65, which is not the default.", "sources": ["https://nomicon.io/DataStructures/Account"] },
    "1.3": { "verdict": "fail", "scheme": "Threshold ECDSA (secp256k1) + FROST EdDSA + BLS12-381", "why": "NEAR Chain Signatures — a live mainnet MPC threshold-signing network (contract v1.signer) — signs with classical threshold ECDSA over secp256k1, FROST threshold EdDSA over Ed25519, and uses BLS12-381 for confidential key derivation; all are elliptic-curve / pairing based and Shor-breakable.", "sources": ["https://github.com/near/mpc", "https://github.com/near/threshold-signatures", "https://docs.near.org/chain-abstraction/chain-signatures"] },
    "1.4": { "verdict": "fail", "scheme": "Native accounts + access keys (classical verifier)", "why": "NEAR's contract-account model, function-call access keys, and meta-transactions (NEP-366) verify Ed25519 / secp256k1 signatures by default. An ML-DSA-65 on-chain verifier exists only behind the opt-in PostQuantumSignatures feature, not yet activated on mainnet — so it fails the election route at E3 (testnet only) and E4 (no wallet tooling exposes it). Once ML-DSA-65 keys are live on mainnet in audited form and electable through ordinary wallets with full coverage and no loss of function, this passes by election.", "sources": ["https://nomicon.io/DataStructures/Account", "https://github.com/near/nearcore/pull/15731"] },
    "1.5": { "verdict": "fail", "scheme": "Ed25519 function-call access keys", "why": "NEAR's scoped, session-like FunctionCall access keys use Ed25519 — Shor-breakable.", "sources": ["https://nomicon.io/DataStructures/Account"] },
    "1.6": { "verdict": "fail", "scheme": "Named accounts (inherit account key)", "why": "NEAR's native human-readable named accounts (e.g. alice.near) inherit the controlling account's Ed25519 / secp256k1 signature, breakable until accounts move to PQ.", "sources": ["https://nomicon.io/DataStructures/Account"] },
    "1.7": { "verdict": "na", "scheme": "", "why": "Governance is handled off-chain (validators / foundation / community), with no on-chain coin-holder-vote signature protocol to break." },
    "2.1": { "verdict": "fail", "scheme": "ed25519_verify / ecrecover host functions", "why": "Contracts verify signatures via the runtime's ed25519_verify and ecrecover (secp256k1) host functions — both Shor-breakable.", "sources": ["https://nomicon.io/RuntimeSpec/Components/BindingsSpec/MathsAPI"] },
    "2.2": { "verdict": "fail", "scheme": "alt_bn128 (BN254) pairing host functions", "why": "nearcore exposes alt_bn128 (BN254) pairing host functions (g1_multiexp, g1_sum, pairing_check) used by bridge and ZK apps — pairing-based and Shor-breakable.", "sources": ["https://nomicon.io/RuntimeSpec/Components/BindingsSpec/MathsAPI"] },
    "2.3": { "verdict": "fail", "scheme": "Operator-signed oracle feeds", "why": "On-chain oracle feeds (e.g. Pyth on NEAR) authenticate updates with classical ECDSA / Ed25519 signatures.", "sources": ["https://docs.near.org"] },
    "2.4": { "verdict": "fail", "scheme": "EC VRF (Ed25519 / Curve25519)", "why": "NEAR's on-chain randomness (the random_seed exposed to contracts) derives from the block producer's elliptic-curve VRF tied to the Ed25519 validator key — Shor-breakable.", "sources": ["https://nomicon.io/ChainSpec/Consensus"] },
    "2.5": { "verdict": "na", "scheme": "", "why": "NEAR uses no verifiable delay function." },
    "3.1": { "verdict": "fail", "scheme": "Ed25519 block/chunk producer signatures", "why": "NEAR is proof-of-stake: block and chunk producers order transactions and sign the blocks/chunks with Ed25519 — a Shor-breakable signing key, not hash-based PoW. The PQ design doc explicitly excludes block/chunk signatures from the ML-DSA-65 scope.", "sources": ["https://github.com/near/nearcore/blob/2.13.0-rc.1/docs/architecture/how/post_quantum_signatures.md", "https://nomicon.io/ChainSpec/Consensus"] },
    "3.2": { "verdict": "na", "scheme": "", "why": "NEAR validates state transitions by validator re-execution and stateless chunk validation, not by ZK validity proofs, so there is no proof system to score.", "sources": ["https://near.github.io/nearcore/architecture/"] },
    "3.3": { "verdict": "na", "scheme": "", "why": "NEAR uses no trusted setup." },
    "3.4": { "verdict": "na", "scheme": "", "why": "NEAR is a monolithic sharded (Nightshade) L1; data availability is internal to the protocol, not a commitment posted to a separate base layer. (NEAR-DA for external rollups is a service NEAR offers to others, not NEAR's own component.)", "sources": ["https://near.github.io/nearcore/architecture/"] },
    "3.5": { "verdict": "pass", "scheme": "Merkle-Patricia trie (hash-based)", "why": "NEAR's state is a Merkle-Patricia trie committed by hash digests (SHA-256 family); hashing is only Grover-weakened, so 256-bit state roots stay quantum-safe.", "sources": ["https://near.github.io/nearcore/architecture/"] },
    "3.6": { "verdict": "pass", "scheme": "NEAR Wasm VM", "why": "The NEAR Wasm virtual machine carries no cryptography of its own; signing and verification live in the signature and host-function layers.", "sources": ["https://near.github.io/nearcore/architecture/"] },
    "4.1": { "verdict": "fail", "scheme": "Ed25519 validator signatures (Nightshade + Doomslug)", "why": "Nightshade sharding with Doomslug finality: validators sign approvals and endorsements with Ed25519 — Shor-breakable. The PQ addition explicitly excludes validator and consensus keys.", "sources": ["https://github.com/near/nearcore/blob/2.13.0-rc.1/docs/architecture/how/post_quantum_signatures.md", "https://nomicon.io/ChainSpec/Consensus"] },
    "4.2": { "verdict": "fail", "scheme": "Ed25519 validator-signature light client", "why": "NEAR light clients establish trust by verifying block-producer / next-epoch validator Ed25519 signatures — Shor-breakable.", "sources": ["https://nomicon.io/ChainSpec/LightClient"] },
    "4.3": { "verdict": "na", "scheme": "", "why": "NEAR is a base L1; it does not anchor its state to another chain." },
    "4.4": { "verdict": "na", "scheme": "", "why": "NEAR has no in-protocol canonical bridge; the Rainbow Bridge and third-party bridges are operator-run app-layer contracts (scored against their operators, not the chain). NEAR's Chain Signatures cross-chain capability is scored under 1.3." },
    "4.5": { "verdict": "na", "scheme": "", "why": "NEAR has no restaking / AVS attestation layer in its core protocol." },
    "4.6": { "verdict": "na", "scheme": "", "why": "Payment channels / conditional transfers are not part of the core protocol." },
    "4.7": { "verdict": "na", "scheme": "", "why": "NEAR has no MEV-Boost-style proposer-builder-separation relay market." },
    "5.1": { "verdict": "fail", "scheme": "Ed25519 handshake / classical key exchange", "why": "NEAR node-to-node transport uses classical key exchange with Ed25519-based peer handshakes; the PQ design doc confirms network keys are out of scope, so there is no PQ / hybrid transport.", "sources": ["https://github.com/near/nearcore/blob/2.13.0-rc.1/docs/architecture/how/post_quantum_signatures.md"] },
    "5.2": { "verdict": "fail", "scheme": "Ed25519 node identity keys", "why": "NEAR peer / node identity keys are Ed25519 — Shor-breakable (network keys are explicitly excluded from the PQ addition).", "sources": ["https://github.com/near/nearcore/blob/2.13.0-rc.1/docs/architecture/how/post_quantum_signatures.md"] },
    "5.3": { "verdict": "fail", "scheme": "Classical TLS", "why": "Wallet / dapp and RPC connections use classical TLS with elliptic-curve key exchange.", "sources": ["https://docs.near.org"] },
    "5.4": { "verdict": "na", "scheme": "", "why": "NEAR has no deployed protocol-level stealth-address / on-chain key-agreement standard." },
    "5.5": { "verdict": "na", "scheme": "", "why": "NEAR has no default protocol-level encrypted mempool or privacy layer." }
  }
}