What it is. NEAR is a public blockchain whose accounts are built to let a holder swap the secret key that controls their funds for a new one without rebuilding the account, which is the most flexible setup of its kind among the big base-layer chains, yet the team has not started moving any of it onto quantum-proof protection.
What we found. NEAR is set up better than its peers to switch to quantum-safe keys quickly, but none of that switch has begun: nothing runs on quantum-safe keys today, no code for it exists, no validator uses such a key, and no dated plan has been published.
Why it matters. A future quantum computer could forge the keys guarding every funded NEAR account, and because the same accounts also control money the holder owns on several other chains, one cracked key could drain funds in more than one place, so the easy upgrade path NEAR already has only helps once the team actually uses it.
NEAR has the strongest native account abstraction in the L1 cohort, the access-key model lets a PQ migration be a key-add + key-delete sequence at user level, no account redesign. Architectural readiness scores 73/100; deployment scores 13/100. The 60-point Architecture-Execution Gap is the binding tell: structural readiness without any execution.
Summary
NEAR operates entirely on Ed25519 (validator approvals, default access keys), secp256k1 (alternative access keys, Aurora EVM, Chain Signatures ECDSA), and SHA-256 (chain hash), all Shor-vulnerable or Grover-weakened, no post-quantum primitive in protocol use, no NEP, no working group, no published roadmap. Mainnet PQC traffic 0%. The structural strength is native account abstraction: the access-key model lets a PQ migration be a key-add + key-delete at user level, no account redesign. Dim 4 scored 73/100 on that architectural readiness; Dim 5 scored 13/100, zero deployment, zero client code, zero validator PQ keys. The Architecture-Execution Gap of 60 points triggers the QRI 70 cap; Mainnet-Traffic cap binds tighter at QRI 60. Chain Signatures (8-node MPC service) signs across two threshold protocols (ECDSA secp256k1, EdDSA Ed25519 GA 2025-04-30), both Shor-vulnerable; the cross-chain signing surface exposes NEAR's accounts to compromise of destination-chain keys derived from the NEAR account. Gate 1a-Sig FAIL, Gate 1a-KEM FAIL. The unresolved nearcore#3216 Ed25519 spec gap (closed 2025-06-10) materially complicates any future hybrid composition. QRI 24, Band 3 Planning.
What the gates say
- Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition; access-key model could host OR-composition but no spec declares this as the PQ migration path with security-game documentation
- Gate 1a, Hybrid KEM: FAIL , no documented hybrid KEM for NEAR validator gossip / RPC TLS / MPC-node transport
- Gate 1b, Commit-to-hash: COND , Gate 1a-Sig FAIL, no OR-composition declared
- Gate 2, Evidence reconstruction: PASS , every sub-score has ≥3 public artifacts except 5b/5c, single-source; flagged for evidence-density discount on Dim 5
- Gate 3, Primitive naming: PASS , Ed25519, secp256k1, SHA-256, threshold-ECDSA, threshold-EdDSA, FROST, Cait-Sith named with mechanism
Burn-vs-rescue policy on file
Declared option f, Undeclared. No foundation, NEP, or governance-forum declaration on what happens to legacy Ed25519-controlled accounts at the cryptographic-break horizon. Architecturally, NEAR's access-key model leans toward (e) optional migration (a user replaces their access key voluntarily), but this is not formalized as policy.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 26 / 100
Active primitives well-named in foundation docs and nearcore. Inventory specific and complete; minor deduction for there being no single foundation-published 'all primitives' page.
Ed25519 (EdDSA over Curve25519), account / access-key signing, validator block / chunk approvals · secp256k1 ECDSA, alternative access-key curve, Aurora EVM ecrecover precompile · SHA-256, chain hash · Threshold ECDSA over secp256k1 (Cait-Sith-derived OT-based protocol, Chain Signatures mainnet 2024-08-08) · Threshold EdDSA over Ed25519 (FROST-style, Chain Signatures GA 2025-04-30) · Rainbow Bridge Ed25519 verification on Ethereum (smart-contract verification with optimistic challenge window) Ed25519 (account / access-key / validator approvals)→ Shor-break-via-DL-without-pairingssecp256k1 (alternative access-key, Aurora ecrecover, Chain Signatures ECDSA)→ Shor-break-via-DL-without-pairingsSHA-256 (chain hash)→ Grover-weakenThreshold-ECDSA / Threshold-EdDSA in Chain Signatures MPC→ Shor-break (the threshold protocol composes Shor-vulnerable curves)
Zero PQ families. Ed25519, secp256k1, threshold-ECDSA, threshold-EdDSA all reduce to elliptic-curve discrete log.
Ed25519 → 128-bit classical, 0 NIST-PQC; secp256k1 → ~128-bit classical, 0 NIST-PQC; SHA-256 → ~128-bit post-quantum (Grover-weaken). No NIST PQC scheme mapped at protocol level.
nearcore Ed25519 path uses ed25519-dalek (Rust, constant-time per upstream library convention); JS tooling uses tweetnacl. NEAR's Ed25519 verification rules are non-standard versus generic libraries, nearcore#3216 (closed 2025-06-10) documented this. No machine-checked formal verification of validator-client signing path. Chain Signatures MPC nodes (currently 8) run Cait-Sith-derived ECDSA + FROST-derived EdDSA. Cryptanalytic maturity tier 1.
2 Quantum Recovery Exposure weight 10% 23 / 100
NEAR-implicit accounts use the 64-character hex-encoded Ed25519 public key directly as the account ID. Named accounts (e.g. alice.near) store one or more access keys' public keys on-chain (full-access or function-call); access keys for any account that has ever signed are publicly readable via JSON-RPC view_access_key_list. Every funded NEAR account exposes the public key(s) controlling its balance.
Same architectural exposure as 2a. Implicit accounts cannot exist on-chain without their public key being the address; named accounts cannot have funds without at least one access key being on-chain. Dormant / lost NEAR accounts have the same exposure as active ones. No Bitcoin-style P2PKH wrapper.
NEAR transactions bind to a recent block hash and are not replayable beyond a short validity window. Historical signature material does not create new spend authority on its own. Long-term forgery risk concentrates on key-not-rotated accounts. Access-key model means key rotation is protocol-native, but no industry data on how often it is exercised at scale.
Validator network gossip and client-to-RPC connections rely on standard TLS/QUIC layers using classical X25519 / RSA / ECDH key exchange. No foundation declaration of a hybrid PQ KEM in the validator stack, RPC layer, or MPC node communications. Chain Signatures MPC (8 nodes) coordinates over classical channels.
3 Metadata, Anonymity & Confidentiality weight 13% 35 / 100
Pseudonymous, fully transparent. Every transaction, account, and access-key entry is publicly readable from any RPC node or explorer. Human-readable named accounts (alice.near) further raise observability versus opaque hex addresses, many accounts are linked to off-chain identities through wallet UX or social handles.
RPC layer is concentrated. The near.org and pagoda.co foundation-operated public endpoints were deprecated; the recommended archival-rpc.mainnet.near.org is 'severely rate limited' with 'no paid plan available' per official documentation, pushing usage to FastNEAR, QuickNode, and Ankr as dominant production providers. No foundation-published per-provider request-share percentages.
Rainbow Bridge (NEAR ↔ Ethereum) and Aurora (NEAR's native EVM layer) link tx flows in the clear on both sides. Chain Signatures by design connects NEAR accounts to transactions on Bitcoin, Ethereum, Solana, Sui, Aptos, Stellar, TON, all transparent, making cross-chain linkage explicit and observable.
Because NEAR is already pseudonymous-transparent at protocol level, a future Shor break does not expose meaningfully more than is already on-chain. Retroactive privacy regression is small relative to chains with on-chain encrypted state.
No protocol-level mixnet, shuffle, or commit-reveal at consensus. No application-layer mixing infrastructure documented as live in NEAR ecosystem at audit cutoff.
4 Migration Architecture weight 10% 73 / 100
NEAR's runtime-upgrade history shows coordinated protocol changes (Phase-1 sharding, Nightshade 2.0, stateless validation rollouts). The access-key data structure is curve-pluggable in principle (Ed25519 + secp256k1 already coexist in production), giving an algorithm-switch path without redesigning accounts. However, no NEP-level proposal currently extends PublicKey enum / signing rules to add a PQ scheme.
NEAR's account model is the strongest native-AA in the L1 cohort. Every named account supports multiple access keys per account, with two permission tiers (FullAccess, FunctionCall), keys are added, removed, and rotated by transactions, with no smart-contract wrapper required. A PQ migration is architecturally a key-add: attach a PQ access key alongside legacy Ed25519, then delete the legacy key. Lose 3pts because the PQ scheme is not deployed and there is no published client path or active migration volume.
NEAR mainnet has shipped multi-year coordinated upgrades (Phase 0, Phase 1, Nightshade 2.0 stateless validation) without contested forks. No public chain split. Coordination cadence has been steady across the period.
Architecturally, the access-key model could host hybrid PQ (a full-access PQ key alongside a full-access Ed25519 key, both authorized to spend, equivalent to OR-composition at the account layer). Nothing in the spec or NEPs declares this as the migration path. No commit-to-hash-of-both-pubkeys construction documented (Gate 1b would require it for OR-composition credit).
N/A, NEAR uses no stateful hash-based signature scheme. Default 15 by rubric.
N/A, NEAR validator block / chunk approvals use Ed25519 (non-aggregating) signatures rather than BLS aggregation in consensus. The Doomslug consensus design stores per-validator signatures on approvals (one signature per approving validator). Per v3.1 rubric, 4f is N/A for chains using non-aggregating signatures at consensus.
5 Deployment Execution weight 22% 13 / 100
0%. No NEAR validator approval, account signature, or Aurora EVM signature uses a PQ primitive. No Chain Signatures MPC domain uses a PQ scheme.
0 bytes / 0 LOC of PQ signing or PQ KEM merged in nearcore. No pq- prefix module, no ML-DSA / ML-KEM / SLH-DSA / FN-DSA / Falcon dependency, no XMSS state-management code in the validator path.
0% of validator stake registered with a PQ key. Validator keys are Ed25519 per the node-operator key-management documentation.
VOIDED per v3.1 (5a = 0). Independent of the void, no foundation-published PQ migration milestones exist (no NEP, no roadmap entry, no foundation blog post matching 'post-quantum' / 'quantum-resistant' at the audit cutoff).
Announced PQC count (trailing 12 months, foundation channels) = 0; shipped PQC count = 0. Ratio 0/0 → no washing tag. Score 13/15 (best available given no evidence of shipping; ratio undefined).
Undisclosed. NEAR has not published per-block bytes-under-PQ analysis or chosen a PQ primitive whose footprint can be analyzed.
6 Supply Chain Vendor Readiness weight 22% 6 / 100
Top-3 wallets: MyNearWallet (web, non-custodial; NEAR-native), Meteor Wallet (browser extension), HERE Wallet (mobile). None publish a PQC roadmap. Ledger hardware integration inherits Ledger's general PQ research stance, no NEAR-specific PQ deliverable.
Top-3: Rainbow Bridge (NEAR ↔ Ethereum, optimistic Ed25519 verification on Ethereum), Omni Bridge (NEAR's chain-abstraction bridge built on Chain Signatures MPC), LayerZero (third-party general-purpose). None publish a PQC roadmap. Rainbow Bridge's planned upgrade to zk-SNARK Ed25519 verification (Electron Labs grant) does not change the underlying signature primitive, it makes classical Ed25519 cheaper to verify, not PQ-safe.
Top-3 (NEAR-supporting institutional): Coinbase Custody, BitGo, Fireblocks. None publish a NEAR-specific PQC roadmap. Generic vendor-level MPC-PQ research at Fireblocks / Coinbase is non-deliverable for NEAR custody specifically.
RPC: foundation-operated near.org and pagoda.co endpoints deprecated; production traffic concentrated on FastNEAR, QuickNode, Ankr (no published PQC roadmap). HSM: validator key custody varies by node operator, no foundation-mandated HSM with PQ support. TEE: no protocol-level TEE attestation chain.
7 Governance & Coordination weight 8% 43 / 100
Nakamoto coefficient reported by Chainspect at audit cutoff: 9 (9 validators required to control ≥33% of stake), with ~401 validators total and ~$742M total stake. Single-client implementation (nearcore), no published second-client validator share.
NEAR Foundation coordinates network-wide upgrades on a multi-month cadence; Nightshade rollouts and stateless-validation work shipped without contested forks. No demonstrated under-adversary upgrade.
NEAR Foundation (Switzerland) is the public coordination entity; mandate is published on near.foundation. There is no named PQ-specific coordination lead, working group, or pq.near.org-style portal at the audit cutoff (compare: pq.ethereum.org exists for Ethereum).
NEAR has not faced a live cryptographic-break adversarial scenario; no precedent for crisis-coordination on a crypto change. Foundation-coordinated upgrades have proceeded under business-as-usual conditions.
No published community honeypot, no rate-limited spending rule, no cryptographic tripwire embedded in consensus, no automated PQ-incident response.
X + Y vs Z, when does the math turn against you?
v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?
Verdict
X+Y range 13–24 years (2039–2050), Crisis Zone (vs Z10 2030); Outside risk window (vs Z25 2035)
Z-compliance
Outside compliance window (X+Y > 2035 lower bound)
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
NEAR's Ed25519 verification rules are non-standard versus mainline cryptographic libraries, nearcore#3216 documented the issue and was closed 2025-06-10. This is a chain-internal source disagreement against external Ed25519 implementations (e.g. EIP-665, generic libsodium). Material for any future hybrid composition because a PQ scheme paired with a non-standard Ed25519 inherits the spec ambiguity.
Foundation-operated RPC infrastructure (near.org + pagoda.co endpoints) deprecated; production routing now via FastNEAR, QuickNode, Ankr. Documentation and historical references diverge during the transition window. Material for Dim 3b RPC concentration math.
Chainspect reports 9; Nakaflow does not list NEAR. Single-tracker dependence noted.
Delta-QRI under alternative weighting
Under an architecture-leaning alternative-weighting (Dim 4 raised from 10% to 17%, Dim 5 lowered from 22% to 15%), QRI rises from 24 to ~30, moves NEAR from low-Planning to high-Planning. Native-AA architectural advantage materially improves under that view.
Announcement-to-shipped ratio
Announced: 0. Shipped: 0. Ratio: 0.
Tag: none
Peers in the L1 profile
9 chains closest to NEAR Protocol by Stage then QRI.