Watchlist 0
ALEO · PRIVACY-FOCUSED CHAIN · STAGE 1 ACKNOWLEDGED · QRI 23 v3.1.0 methodology
In plain terms

What it is. Aleo is a blockchain built to keep payments private, hiding who sent what to whom and how much.

What we found. The privacy is the soft spot: a future quantum computer could unlock every hidden transaction ever recorded, and there is no plan in place to prevent it.

Why it matters. Anyone can copy this data today and read it later, so private payroll and business transfers, including company stablecoin flows that went live in January 2026, would all be exposed at once.

Aleo is a privacy-first L1 with every signing, encryption, and proof-system primitive sitting on Edwards-BLS12 / BLS12-377 / Varuna, all Shor-vulnerable. Note ciphertext payloads (including USDCx institutional flows since 2026-01-27) use ECIES on Edwards-BLS12 with AES-128-GCM; an adversary harvesting today decrypts every shielded record once Shor lands. The Confidentiality subtotal is 1/40.

inLinkedIn Audit access Compare Verified 2026-05-01

Summary

Aleo scores QRI 23, Band 3 Planning, Migration Stage 1. Mainnet (live since 2024-09-18) runs Schnorr signatures over Edwards-BLS12, Varuna (Marlin-derived zk-SNARK) with KZG-style polynomial commitments over BLS12-377, ECIES on Edwards-BLS12 + Poseidon for record encryption, and Coinbase Puzzle / PoSW SNARKs. AleoBFT (Narwhal + Bullshark) over a 25-validator committee uses Schnorr-on-Edwards-BLS12 BatchSignatures (no BLS aggregation deployed). Every public-key surface is Shor-vulnerable. The dominant exposure is Dim 2 sub-score 2e (Note Ciphertext Payload, score 0/30): every shielded record is sealed by ECDH on Edwards-BLS12, which Shor breaks in polynomial time. Combined with on-chain pubkey publication (the address IS the public key), this gives an adversary a one-shot mass de-anonymization of every transaction since mainnet launch, including USDCx payroll and vendor flows. There is no PQ KEM testnet, no foundation announcement, no plan. mainnet-traffic cap binds at 5a=0%, Gate 1a-Sig FAIL caps QRI ≤60. Burn-vs-rescue undeclared. Strong v4.x hard-fork cadence (validator-set expansion, three v4.x forks Q3 2025) demonstrates coordination capacity, but no PQ working group exists.

What the gates say

  • Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition; account signing and consensus signing are pure Schnorr-on-Edwards-BLS12
  • Gate 1a, Hybrid KEM: FAIL , record encryption uses pure ECIES on Edwards-BLS12 with no hybrid PQ KEM; validator-mesh transport uses classical TLS without published hybrid composition
  • Gate 1b, Commit-to-hash: COND , no OR-composition exists
  • Gate 2, Evidence reconstruction: PASS , every sub-score above carries ≥3 public artifacts
  • Gate 3, Primitive naming: PASS , every sub-score names exact primitives

Burn-vs-rescue policy on file

Declared option f, Undeclared. Aleo has not published a policy on what happens to legacy private records once Shor enables retroactive decryption. The Bitcoin freeze/rescue framing is a poor fit for a privacy chain because the analogue is not freeze QV addresses but rather what do we do about every historical encrypted record that becomes publicly readable on Q-day. Foundation has issued no statement on this question.

Seven dimensions

Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.

1 Cryptographic Exposure weight 12% 28 / 100
1a · primitive inventory 18 / 20

Foundation docs explicitly name every primitive used at protocol level. Minor deduction: TLS/transport layer for validator gossip is not separately specified in public foundation docs.

Primitives: BLS12-377 (pairing-friendly Short Weierstrass curve, embedding degree 12) for SNARK proofs and polynomial commitments · Edwards-BLS12 (twisted Edwards, a=−1, d=3021, cofactor 4) for account addresses, key derivation, and signatures · Schnorr signatures (with sk_sig derived via BLAKE2s) for transaction authorization · ECIES on Edwards-BLS12 for record encryption (symmetric layer instantiated with Poseidon, not AES) · Poseidon (rates 2/4/8) as the core ZK-friendly hash · SHA-256, SHA3-256, Keccak-256, BLAKE2s for general hashing/derivation · Varuna (Marlin-derived zk-SNARK) as the proof system · Coinbase Puzzle / PoSW SNARK · BatchSignature on Edwards-BLS12 (Narwhal/Bullshark consensus signing)
1b · shor grover pq tag 4 / 20

Every signing, encryption, proof-system, and consensus primitive in active use depends on hardness of discrete logarithm or pairing problems on BLS12-377 / Edwards-BLS12. No PQ-safe primitive is in mainnet use.

Tags:
  • BLS12-377 Shor-break-via-pairings
  • Edwards-BLS12 Shor-break-via-DL
  • Schnorr-on-Edwards-BLS12 (account sigs) Shor-break-via-DL
  • ECIES-on-Edwards-BLS12 (record encryption) Shor-break-via-DL
  • Varuna (Marlin variant) with KZG-style polynomial commitment over BLS12-377 Shor-break-via-pairings
  • Coinbase Puzzle PoSW SNARK Shor-break-via-pairings
  • Poseidon research-grade ZK hash, Grover-weakened
  • SHA-256 / SHA3-256 / Keccak-256 / BLAKE2s Grover-weakened (256→128-bit)
1c · family diversity 0 / 20

0 PQ families on mainnet (all primitives are pre-quantum DL/pairing-based). No lattice, hash-based, code-based, or isogeny PQ primitive deployed. Diversity Cap is not yet triggered (it fires on lattice-monoculture); Aleo is in a pre-cap state of zero PQ families.

1d · nist security category 0 / 20

No primitive in active use maps to NIST PQC categories 1-5. BLS12-377 targets ~128-bit classical security; Edwards-BLS12 targets ~125-bit classical; Poseidon parameter sets target 128-bit classical.

1e · implementation quality 9 / 20

snarkVM and snarkOS underwent three independent audits (Trail of Bits, NCC Group, zkSecurity) covering Varuna and surrounding protocols; Varuna has a SageMath reference implementation. Constant-time engineering and formal verification are NOT documented for Aleo's core crypto. Library provenance: pure-Rust internal arkworks-derived stack. Cryptanalytic-maturity tier mixed: SHA-2/3 / Keccak / BLAKE2s tier 2, Schnorr/ECDH on Edwards curves tier 1, Poseidon and Varuna tier 4 (research-grade).

2 Quantum Recovery Exposure weight 10% 15 / 100
Forge subtotal: 13/75 Decrypt subtotal: 2/25
2a · active key exposure 4 / 20

Every Aleo account address is an Edwards-BLS12 public-key point published on-chain at first transaction. Schnorr signatures over Edwards-BLS12 reveal the public key implicitly through the signature equation. With ~25 validators each holding a stake-weighted Edwards-BLS12 keypair signing every block, validator compromise is also a Forge surface.

2b · cold key exposure 5 / 20

Cold/dormant Aleo holdings sit at known Edwards-BLS12 addresses on-chain; the address IS the public key (Bech32-encoded). Unlike Bitcoin P2PKH where the pubkey is hashed and only revealed at spend, Aleo addresses publish the curve point at account creation. Cold funds are fully Forge-vulnerable today via passive on-chain harvesting.

2c · sig long term validity 4 / 20

Every transaction-authorizing Schnorr signature and every consensus BatchSignature on the chain since 2024-09-18 is verifiable post-Shor against a forged version. Combined with on-chain pubkey publication, historical authorization records lose non-repudiation once Shor lands.

2d · encryption confidentiality hndl 2 / 10

Validator-to-validator gossip in AleoBFT runs over the snarkOS P2P network; the foundation has not published the transport-layer cipher suite. RPC endpoints typically run TLS at infrastructure provider level. By inference, the entire validator-mesh and RPC layer uses classical TLS with X25519/secp256r1 KEM, which is HNDL-vulnerable.

2e · note ciphertext payload 0 / 30

Every Aleo record payload is sealed by an ECDH key-agreement on Grumpkin between sender and recipient (via the recipient's incoming viewing public key), with AES-128-GCM applied to the note payload. Both halves of the construction are HNDL-broken under Shor: the ECDH key agreement on Edwards-BLS12 is a discrete-log instance broken by Shor; the resulting AES-128 has only 64-bit Grover security. An adversary harvesting all note ciphertexts plus all ivpks now decrypts every shielded payload, sender, recipient, asset type, amount, contract being called, once a CRQC against Edwards-BLS12 DL exists. USDCx institutional-grade private stablecoin transactions (live since 2026-01-27) inherit this vulnerability. There is no hybrid PQ KEM testnet, no announcement, no plan.

3 Metadata, Anonymity & Confidentiality weight 25% 33 / 100
Anonymity subtotal: 32/80 Confidentiality subtotal: 1/40
3a · tx graph visibility 15 / 20

Aleo's record model fully shields transaction inputs/outputs/amounts/programs behind zk-SNARK proofs (Varuna). On-chain visible state for a private transaction is a serial-number nullifier set + record commitment + encrypted record + proof, closer to Zcash shielded than to pseudonymous Bitcoin/Ethereum. Public records also supported. Per-transaction sender-address leakage opt-in via v4.0.0 encrypted-sender field.

3b · rpc mempool concentration 8 / 20

Top-3 RPC concentrated among a small set (Aleoscan, Provable Explorer, Lavender.Five Nodes), partially offset by Leo Wallet and Puzzle Wallet running their own infrastructure. Mempool gossip observable to all 25 validators by AleoBFT design. Validator metadata retention policy undeclared.

3c · cross chain bridge correlation 4 / 20

Bridges into Aleo (Wormhole, LayerZero, custodial xReserve for USDCx) are observable on the source chain. Circle's xReserve is a centralized mint/burn pipeline whose books link USDC↔USDCx 1:1, providing a strong correlation channel for institutional flows.

3d · retroactive de anonymization 1 / 20

Dominant confidentiality risk for Aleo. The privacy guarantee for a record relies on (a) the secrecy of the recipient's view key derived from the Edwards-BLS12 secret, and (b) the secrecy of the random scalar used in the record-encryption ECDH. Both are protected only by the discrete-log problem on Edwards-BLS12. Once Shor lands, every historical Aleo private record encrypted to a published address is decryptable. Combined with on-chain pubkey publication and full chain history availability, this gives an attacker a one-shot mass de-anonymization of every transaction since 2024-09-18, including USDCx payroll, vendor, and institutional transfers since 2026-01-27.

3e · mixnet shuffle 5 / 20

Aleo does not run a mix-network or cryptographic shuffle protocol at the protocol layer. Privacy comes from the SNARK record model itself (hidden inputs/outputs), not from mixing. No on-chain commit-reveal mix, no cMix-class IT-secure shuffle, no precomputation/cover-traffic infrastructure.

3f · content payload encryption shelf life 0 / 20

No Aleo Foundation, Provable, or community-ratified ARC announces post-quantum migration of record encryption. The publicly-visible roadmap and snarkOS v4.x release notes through 2026-05-01 list AleoBFT consensus upgrades, AleoVM developer experience, prover staking, program upgradability, priority fees, encrypted-sender records, and USDCx, but no PQ KEM, no hybrid encryption testnet, no announced sunset of ECIES-on-Edwards-BLS12.

4 Migration Architecture weight 12% 34 / 100
4a · crypto agility 4 / 15

snarkOS has demonstrated coordinated hard-fork upgrades (v3.3 validator-set expansion, v4.0 record-model upgrade, v4.1 program upgradability, v4.2 fee-market) but no algorithm-switch event. The new record versioning system introduced in v4.0.0 is described as enabling adaptation to evolving regulatory requirements but does not specify an algorithm-replacement path.

4b · aa key rotation 3 / 20

Aleo accounts have no key-rotation primitive, the address is the public key, and rotating it requires moving funds to a new address (with sender-side correlation). There is no native account-abstraction path comparable to ERC-4337 / EIP-7702. Compute keys allow third-party transaction generation but not algorithm rotation.

4c · hard fork track record 10 / 15

In ~20 months since mainnet, Aleo executed validator-set expansion (Feb 2025), three coordinated v4.x hard forks (v4.0.0 Jul 2025, v4.1.0, v4.2.0 Sep 2025), and v4.4.0 Nov 2025, all without contested splits. Track record is short but clean.

4d · hybrid deployment readiness 2 / 15

No public hybrid PQ design exists. Architecturally, the SNARK proof system (Varuna over BLS12-377) is the deepest constraint on agility, replacing it with a FRI-based proof system is technically feasible but would require a full re-instantiation of snarkVM. Record encryption could in principle be migrated to a hybrid KEM (ML-KEM concatenated with current ECIES) more cheaply, but no ARC proposal exists.

4e · stateful hash state management 15 / 15

Aleo does not use stateful hash signature schemes anywhere in the stack. Schnorr-on-Edwards-BLS12 is stateless. Per rubric, stateless-by-default chains score full 15.

4f · bft aggregation path 0 / 20

AleoBFT signs BatchProposes/BatchCertificates with Schnorr signatures on Edwards-BLS12 from each of the 25 validators (no BLS aggregation). 2f+1 BatchSignatures are aggregated into a BatchCertificate. The consensus signing primitive itself is Shor-vulnerable Schnorr-on-EC. No PQ-replacement path is declared for consensus signing.

5 Deployment Execution weight 18% 15 / 100
5a · mainnet pqc traffic pct 0 / 25

0% of consensus signing, transaction signing, record encryption, or proof generation runs on a PQC primitive as of 2026-05-01.

5b · pqc code in consensus client 0 / 15

snarkOS contains no merged PQC primitive (no ML-DSA, no SLH-DSA, no ML-KEM, no FRI proof system) as of 2026-05-01.

5c · validator pqc key adoption 0 / 15

0 of 25 validators run PQC consensus keys.

5d · published dated milestones 0 / 10

VOIDED to 0 per v3.1 rule (5a = 0). No dated, enforcement-mechanism-backed PQ milestone exists in any ARC, snarkOS release plan, or roadmap publication.

5e · pqc washing delta 15 / 15

Announced PQC = 0 in trailing 12 months (no foundation blog post, ARC, social post, or press claim). Shipped PQC = 0. Ratio = 0/0 (undefined; treating as not-deduction-eligible because there is no announcement to falsify). Aleo is honest about its current posture by silence.

5f · signature footprint multiplier 0 / 20

Undisclosed. With no announced PQ scheme, the bytes-per-block footprint under PQ is unknown. If Aleo were to migrate consensus to ML-DSA-65 (~3,300 byte sigs vs ~64 byte Schnorr), the multiplier across 25 BatchSignatures per round would be ~50×, beyond the rubric's >38× threshold.

6 Supply Chain Vendor Readiness weight 18% 16 / 100
6a · wallet 4 / 25

Top wallets are Leo Wallet (Provable-acquired in 2025) and Puzzle Wallet. Neither has published a PQC roadmap. WalletConnect support for Aleo is partial. No top-3 wallet ships PQ key derivation.

6b · bridge 3 / 25

USDCx uses Circle's centralized xReserve mint/burn pipeline (not a trustless bridge, no PQC roadmap from Circle for the xReserve back-end). General cross-chain messaging via Wormhole / LayerZero is at design discussion stage.

6c · custodian 5 / 25

Launch partners include Blockdaemon (node operator/custody-adjacent), Chainalysis (compliance), Toku (payroll), Request Finance (invoicing). Top-tier institutional custody (Coinbase Custody, BitGo, Fireblocks, Anchorage) does not yet support Aleo native asset custody at scale. None of the named partners has a published PQC roadmap that covers Aleo keys.

6d · rpc hsm tee infra 4 / 25

RPC/explorer providers include Aleoscan, Provable Explorer, Lavender.Five Nodes, with broader provider support limited (no Infura/Alchemy/QuickNode mainstream support documented for Aleo). HSMs: no documented Ledger / Thales / YubiHSM integration for Aleo Edwards-BLS12 / Schnorr keys (Aleo curves are not on Ledger's supported list as of 2026-05-01). TEEs not used in core consensus path.

7 Governance & Coordination weight 5% 38 / 100
7a · validator stake distribution 8 / 20

25 validators on mainnet (expanded from 16 in Feb 2025), max 200 by protocol rule. Minimum 10M ALEO stake to validate. Client diversity is effectively single-client (snarkOS reference implementation). Stake distribution skewed by foundation/Provable holdings at genesis.

7b · upgrade cadence under pressure 12 / 20

Validator-set expansion, three v4.x hard forks within Q3 2025, v4.4 in Nov 2025, all coordinated cleanly. No demonstrated coordinated upgrade under live attacker pressure.

7c · named coordination lead 14 / 20

Aleo Network Foundation (non-profit, oversees core development) and Provable Inc. (for-profit, core dev shop). Public governance via vote.aleo.org and ARC process. No named PQ migration WG or PQ-lead role.

7d · adversarial coordination precedent 4 / 20

Aleo's mainnet launch in Sep 2024 had launch-day issues (community criticism re token distribution / inflation), resolved without fork. No major adversarial-attack coordination precedent.

7e · canary tripwire mechanism 0 / 20

No community honeypot, no rate-limited spending rule, no cryptographic tripwire, no automated-response mechanism for Shor / record-encryption breakage published.

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?

X, signature shelf life
8–12 years
Y, migration time
8–15 years to Stage 5
Z10 (10% CRQC year)
2030
Z25 (25% CRQC year)
2035

Verdict

X+Y ≈ 2034–2041, Outside risk window vs Z25 2035 (upper bound); Crisis Zone vs Z10 2030

Z-compliance

Outside compliance window, Schnorr-on-Edwards-BLS12 and ECIES become non-compliant under NIST 2035 disallowance

Source-disagreement disclosure

v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.

Confidentiality bucket weighting

Alternative-weighting view that places greater weight on the privacy chain's HNDL-decrypt surface (boosting Dim 2 sub-score 2e and Dim 3 sub-scores 3d / 3f) yields a measurably lower QRI.

Mainstream coverage gap

Mainstream public-blockchain analyst coverage does not yet treat post-quantum risk as a material chain-rating factor for Aleo; the gap between LayerQu's PQ-focused posture and mainstream coverage is the primary source-disagreement axis.

Delta-QRI under alternative weighting

Under alternative weighting that increases the 3-Confidentiality bucket from 10% to 15% and reduces Dim 6 from 18% to 13%, QRI drops from 23 to ~20, delta of -3, reinforcing the Stage-1 / Acknowledged-borderline read.

Announcement-to-shipped ratio

Announced: 0. Shipped: 0. Ratio: 0.

Tag: none

Peers in the privacy-focused chain profile

9 chains closest to Aleo by Stage then QRI.

S3 55
S2 29
S1 24
S1 22
S1 19
S1 28
S0 27