{
  "id": "strk20",
  "name": "STRK20",
  "type": "Shielded-token framework",
  "parent": "starknet",
  "reviewed": "2026-06-24",
  "summary": "STRK20 is Starknet's shielded-asset framework (the Starknet Privacy Stack / Privacy Pool; strkBTC was the first asset, shipped with the v0.14.2 \"Privacy Engine\"). As a product it inherits Starknet as its settlement layer (not quantum-safe → fail) and is otherwise scored on what it wields itself. Its standout — the exact opposite of Zcash — is that BOTH its validity proofs (Stwo STARKs) and its note-commitment tree (Poseidon) are post-quantum-safe. But its confidentiality is not: shielded-note encryption uses ECDH over the Stark curve, so harvest-now-decrypt-later retroactively de-anonymizes shielded transfers — and unlike Zcash (Project Tachyon), no post-quantum encryption is deployed or on the roadmap. Deep-research-verified against the OpenZeppelin audit of starkware-libs/starknet-privacy and StarkWare's IACR ePrint 2026/474 (June 2026).",
  "links": {
    "STRK20": "https://www.starknet.io/blog/make-all-erc-20-tokens-private-with-strk20/",
    "Privacy Engine (v0.14.2)": "https://www.starknet.io/blog/starknet-v0-14-2-the-privacy-engine-arrives/",
    "OpenZeppelin audit": "https://www.openzeppelin.com/news/privacy-contracts-audit",
    "Paper (IACR 2026/474)": "https://eprint.iacr.org/2026/474.pdf"
  },
  "assessment": {
    "1.1": { "verdict": "fail", "inherited": true, "scheme": "Starknet accounts (Stark-curve ECDSA)", "why": "Spending a note requires a valid signature from the owner's existing Starknet account — \"existing Starknet accounts, including multisig, hardware wallets, and smart accounts, work out of the box\" — which sign on the Shor-breakable Stark curve by default.", "sources": ["https://www.starknet.io/blog/make-all-erc-20-tokens-private-with-strk20/", "https://eprint.iacr.org/2026/474.pdf"] },
    "1.2": { "verdict": "na", "scheme": "", "why": "Custody is generic Starknet wallet custody, not something the framework defines." },
    "1.3": { "verdict": "na", "scheme": "", "why": "Threshold / MPC signing is not part of the framework." },
    "1.4": { "verdict": "na", "scheme": "", "why": "STRK20 is a shielded-asset framework, not an account-abstraction scheme — it reuses Starknet's accounts." },
    "1.5": { "verdict": "na", "scheme": "", "why": "Passkeys / session keys are not part of the framework." },
    "1.6": { "verdict": "na", "scheme": "", "why": "No naming / identity layer of its own." },
    "1.7": { "verdict": "na", "scheme": "", "why": "No governance mechanism of its own." },
    "2.1": { "verdict": "fail", "scheme": "In-contract Stark-curve ECDSA", "why": "The privacy protocol is deployed as a Starknet account contract that performs on-chain assert_valid_signature (Stark-curve ECDSA) in __execute__ — a Shor-breakable signature check the product ships itself.", "sources": ["https://www.openzeppelin.com/news/privacy-contracts-audit"] },
    "2.2": { "verdict": "na", "scheme": "", "why": "Shielded proofs are verified natively by Starknet consensus (the proof / proof_facts fields), not via a separate pairing/EC verifier contract." },
    "2.3": { "verdict": "na", "scheme": "", "why": "The framework consumes no oracle feeds." },
    "2.4": { "verdict": "na", "scheme": "", "why": "Note-blinding randomness is internal to client-side proving, not an on-chain VRF." },
    "2.5": { "verdict": "na", "scheme": "", "why": "No verifiable delay function." },
    "3.1": { "verdict": "na", "scheme": "", "why": "Block ordering is Starknet's sequencer — captured by Settlement." },
    "3.2": { "verdict": "pass", "inherited": true, "scheme": "Stwo STARK (Circle STARKs / FRI)", "why": "Shielded validity proofs are STARKs generated client-side with the Stwo prover and verified natively by Starknet consensus; STARK/FRI is hash-based, transparent and post-quantum-plausible — the product's central quantum strength, and the direct opposite of Zcash's Groth16 / Halo 2.", "sources": ["https://www.starknet.io/blog/starknet-v0-14-2-the-privacy-engine-arrives/", "https://github.com/starkware-libs/stwo-cairo"] },
    "3.3": { "verdict": "pass", "inherited": true, "scheme": "Transparent (Stwo)", "why": "Stwo is fully transparent — \"no toxic waste, no MPC ceremony\" — so there is no trusted-setup secret for a quantum computer to recover.", "sources": ["https://github.com/starkware-libs/stwo-cairo"] },
    "3.4": { "verdict": "na", "scheme": "", "why": "Data availability is Starknet's (to Ethereum) — captured by Settlement." },
    "3.5": { "verdict": "pass", "scheme": "Poseidon commitment tree", "why": "STRK20's own shielded note-commitment tree uses Poseidon — Poseidon(Poseidon(secret, nullifier), amount) — a hash-based commitment that is post-quantum-safe (Grover-only). The EC-based Pedersen trie belongs to Starknet's protocol state (captured by Settlement), not the product's tree.", "sources": ["https://www.openzeppelin.com/news/privacy-contracts-audit"] },
    "3.6": { "verdict": "na", "scheme": "", "why": "The Cairo VM — captured by Settlement." },
    "4.1": { "verdict": "na", "scheme": "", "why": "Starknet consensus — captured by Settlement." },
    "4.2": { "verdict": "na", "scheme": "", "why": "Starknet light clients — captured by Settlement." },
    "4.3": { "verdict": "fail", "inherited": true, "scheme": "Settlement = Starknet", "why": "STRK20 is a framework built on Starknet (shipped with v0.14.2; strkBTC was the first asset), so it inherits Starknet as its settlement layer. Under the settlement rule this passes only if the host chain is fully (100%) quantum-safe; Starknet is not, so it fails. A product can be no safer than the chain beneath it.", "sources": ["https://www.starknet.io/blog/starknet-v0-14-2-the-privacy-engine-arrives/"] },
    "4.4": { "verdict": "na", "scheme": "", "why": "No canonical bridge of its own." },
    "4.5": { "verdict": "na", "scheme": "", "why": "No restaking / AVS." },
    "4.6": { "verdict": "na", "scheme": "", "why": "No payment channels." },
    "4.7": { "verdict": "na", "scheme": "", "why": "No builder-relay / PBS market." },
    "5.1": { "verdict": "na", "scheme": "", "why": "Node-to-node transport is Starknet's — captured by Settlement." },
    "5.2": { "verdict": "na", "scheme": "", "why": "Node identity is the chain's — captured by Settlement." },
    "5.3": { "verdict": "na", "scheme": "", "why": "RPC / wallet transport is the chain's — captured by Settlement." },
    "5.4": { "verdict": "fail", "scheme": "ECDH over the Stark curve", "why": "Shielded-note encryption derives a shared channel_key via ECDH over the Stark curve (the Poseidon amount-keystream is downstream of it, so it doesn't help). Shor breaks the EC step, and harvest-now-decrypt-later retroactively de-anonymizes shielded transfers — the headline risk.", "sources": ["https://www.openzeppelin.com/news/privacy-contracts-audit", "https://eprint.iacr.org/2026/474.pdf"] },
    "5.5": { "verdict": "fail", "scheme": "ECDH / EC-ElGamal (Tongo/SHE)", "why": "Confidential amounts rest on EC discrete-log: the in-protocol Privacy Pool uses ECDH note encryption and Starkzap's flow uses EC-ElGamal over the Stark curve (Tongo/SHE). Neither is post-quantum, and no PQ encryption is deployed by default or on the roadmap (contrast Zcash's Project Tachyon).", "sources": ["https://www.openzeppelin.com/news/privacy-contracts-audit", "https://docs.tongo.cash/she/elgamal.html"] }
  }
}