{
  "schema_version": "initiative.v1",
  "id": "encryption-tech-readiness",
  "name": "Encryption Tech Readiness",
  "status": "active",
  "summary": "Evidence-backed guidance for agents and builders choosing FHE, MPC, ZK, threshold, and private-state technologies.",
  "problem": "Builders often describe privacy, encryption, confidentiality, and zero knowledge as interchangeable. Agents need a structured way to distinguish FHE, MPC, ZK proofs, private smart contracts, threshold/key-management systems, and privacy UX primitives before recommending a stack or writing claims.",
  "audiences": [
    "app_builders",
    "privacy_builders",
    "ai_agents",
    "hackathon_builders",
    "protocol_teams",
    "security_reviewers"
  ],
  "tags": [
    "encryption",
    "privacy",
    "fhe",
    "mpc",
    "zero-knowledge",
    "private-state",
    "threshold-cryptography",
    "hackathon"
  ],
  "homepage_url": "https://ethereum.org/en/privacy/",
  "official_sources": [
    {
      "id": "ethereum-privacy",
      "title": "Ethereum privacy overview",
      "url": "https://ethereum.org/en/privacy/"
    },
    {
      "id": "aztec-docs",
      "title": "Aztec documentation",
      "url": "https://docs.aztec.network/"
    },
    {
      "id": "noir-docs",
      "title": "Noir documentation",
      "url": "https://noir-lang.org/docs"
    },
    {
      "id": "semaphore-docs",
      "title": "Semaphore documentation",
      "url": "https://docs.semaphore.pse.dev/"
    },
    {
      "id": "maci-docs",
      "title": "MACI documentation",
      "url": "https://maci.pse.dev/docs/introduction"
    },
    {
      "id": "privacy-pools-docs",
      "title": "Kohaku Privacy Pools documentation",
      "url": "https://ethereum.github.io/kohaku/privacy-pools/intro"
    },
    {
      "id": "zama-docs",
      "title": "Zama documentation",
      "url": "https://docs.zama.ai/"
    },
    {
      "id": "fhevm-docs",
      "title": "Zama fhEVM documentation",
      "url": "https://docs.zama.ai/fhevm"
    },
    {
      "id": "fhenix-docs",
      "title": "Fhenix documentation",
      "url": "https://docs.fhenix.zone/"
    },
    {
      "id": "nillion-docs",
      "title": "Nillion documentation",
      "url": "https://docs.nillion.com/"
    },
    {
      "id": "lit-docs",
      "title": "Lit Protocol documentation",
      "url": "https://developer.litprotocol.com/"
    }
  ],
  "related_chains": [
    "ethereum",
    "arbitrum-one",
    "arbitrum-sepolia",
    "base",
    "optimism",
    "polygon"
  ],
  "related_protocols": [
    "aztec",
    "semaphore",
    "maci",
    "privacy-pools",
    "railgun",
    "kohaku",
    "helios",
    "fluidkey"
  ],
  "related_intents": [
    "build-private-smart-contract-app",
    "build-private-onchain-voting",
    "build-privacy-first-ethereum-wallet"
  ],
  "initiative_intents": [
    {
      "id": "choose-encryption-primitive",
      "title": "Choose the right encryption or privacy primitive",
      "description": "Map a privacy goal to FHE, MPC, ZK, private-state, threshold, or wallet privacy options with caveats and citations.",
      "audience": [
        "privacy_builders",
        "hackathon_builders",
        "ai_agents"
      ],
      "input_requirements": [
        "privacy goal",
        "data that must remain hidden",
        "who computes on the data",
        "who verifies the result",
        "chain or offchain constraints",
        "timebox and production expectations"
      ],
      "recommended_outputs": [
        "recommended primitive family",
        "candidate protocols/dApps",
        "registry coverage gaps",
        "integration difficulty",
        "do-not-claim guidance",
        "citations"
      ],
      "related_changes": [
        "encryption-zk-proof-surface",
        "encryption-fhe-surface",
        "encryption-mpc-surface",
        "encryption-private-state-surface",
        "encryption-threshold-key-surface",
        "encryption-wallet-privacy-surface"
      ],
      "default_priority": "high",
      "evidence_refs": [
        "official:ethereum-privacy",
        "official:aztec-docs",
        "official:zama-docs",
        "official:nillion-docs"
      ]
    },
    {
      "id": "plan-zk-privacy-app",
      "title": "Plan a ZK privacy app",
      "description": "Choose between proof systems, anonymous membership, private voting, privacy pools, or private smart contracts for one app goal.",
      "audience": [
        "privacy_builders",
        "ai_agents"
      ],
      "input_requirements": [
        "proof statement",
        "group or credential model",
        "need for private tally or nullifiers",
        "smart contract requirements",
        "verifier chain"
      ],
      "recommended_outputs": [
        "ZK primitive fit",
        "recommended protocol/dApp stack",
        "verifier and circuit checklist",
        "limitations and do-not-claim guidance"
      ],
      "related_changes": [
        "encryption-zk-proof-surface",
        "encryption-private-state-surface",
        "encryption-privacy-pool-surface"
      ],
      "default_priority": "high",
      "evidence_refs": [
        "official:noir-docs",
        "official:semaphore-docs",
        "official:maci-docs",
        "official:privacy-pools-docs"
      ]
    },
    {
      "id": "assess-fhe-fit",
      "title": "Assess whether FHE fits my app",
      "description": "Decide whether fully homomorphic encryption is useful for the app, or whether ZK, MPC, or private-state tooling is a better near-term path.",
      "audience": [
        "app_builders",
        "privacy_builders",
        "ai_agents"
      ],
      "input_requirements": [
        "computation to run on encrypted data",
        "latency tolerance",
        "ciphertext data model",
        "chain/runtime target",
        "hackathon versus production timeline"
      ],
      "recommended_outputs": [
        "FHE fit assessment",
        "alternative primitive recommendation",
        "registry coverage gap notes",
        "performance and claims caveats"
      ],
      "related_changes": [
        "encryption-fhe-surface"
      ],
      "default_priority": "medium",
      "evidence_refs": [
        "official:zama-docs",
        "official:fhevm-docs",
        "official:fhenix-docs"
      ]
    },
    {
      "id": "assess-mpc-fit",
      "title": "Assess whether MPC fits my app",
      "description": "Decide whether multiparty computation or threshold key management fits a privacy, custody, signing, or data-collaboration workflow.",
      "audience": [
        "app_builders",
        "wallet_teams",
        "ai_agents"
      ],
      "input_requirements": [
        "parties involved",
        "data or key material to split",
        "trust and liveness assumptions",
        "custody or computation goal",
        "online/offline requirements"
      ],
      "recommended_outputs": [
        "MPC fit assessment",
        "threshold/key-management caveats",
        "alternative primitive recommendation",
        "evidence refs"
      ],
      "related_changes": [
        "encryption-mpc-surface",
        "encryption-threshold-key-surface"
      ],
      "default_priority": "medium",
      "evidence_refs": [
        "official:nillion-docs",
        "official:lit-docs"
      ]
    }
  ],
  "assessment_modes": [
    "primitive_selection",
    "zk_privacy_planning",
    "fhe_fit_assessment",
    "mpc_fit_assessment",
    "private_state_fit",
    "privacy_claim_checking"
  ],
  "evidence_refs": [
    "official:ethereum-privacy",
    "official:aztec-docs",
    "official:noir-docs",
    "official:semaphore-docs",
    "official:maci-docs",
    "official:privacy-pools-docs",
    "official:zama-docs",
    "official:fhevm-docs",
    "official:fhenix-docs",
    "official:nillion-docs",
    "official:lit-docs"
  ],
  "last_verified_at": "2026-06-09",
  "review_status": "reviewed",
  "changes": [
    {
      "schema_version": "initiative-change.v1",
      "id": "encryption-fhe-surface",
      "initiative_id": "encryption-tech-readiness",
      "type": "external_reference",
      "status": "reviewed",
      "summary": "FHE is the right family when the app must compute over encrypted data, but it usually carries heavier performance, tooling, and maturity constraints than ordinary EVM or ZK flows.",
      "affected_roles": [
        "privacy_builders",
        "app_builders",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "confidential_compute_builders",
        "encrypted_data_app_teams",
        "hackathon_builders"
      ],
      "affected_protocols": [],
      "affected_chains": [
        "ethereum"
      ],
      "affected_intents": [
        "build-private-smart-contract-app"
      ],
      "possible_consequences": [
        "Agents should recommend FHE only when computation on encrypted values is central to the product.",
        "For hackathons, FHE may be better as a focused demo of one encrypted operation than as a broad production claim.",
        "Zama, fhEVM, and Fhenix should be added as first-class registry records before Composewith makes detailed readiness scores for them."
      ],
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:zama-docs",
        "official:fhevm-docs",
        "official:fhenix-docs"
      ],
      "last_verified_at": "2026-06-09"
    },
    {
      "schema_version": "initiative-change.v1",
      "id": "encryption-mpc-surface",
      "initiative_id": "encryption-tech-readiness",
      "type": "external_reference",
      "status": "reviewed",
      "summary": "MPC fits workflows where multiple parties compute or manage secrets without centralizing the full secret, but trust, liveness, and operational assumptions must be explicit.",
      "affected_roles": [
        "wallet_teams",
        "app_builders",
        "security_reviewers",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "collaborative_compute_builders",
        "custody_builders",
        "key_management_teams",
        "data_collaboration_teams"
      ],
      "affected_protocols": [],
      "affected_chains": [
        "ethereum"
      ],
      "affected_intents": [
        "build-privacy-first-ethereum-wallet",
        "build-private-smart-contract-app"
      ],
      "possible_consequences": [
        "Agents should identify the parties, threat model, and liveness assumptions before recommending MPC.",
        "MPC should not be described as the same thing as ZK proofs or FHE.",
        "Nillion and other MPC/private-compute systems should be added as first-class registry records before detailed readiness scoring."
      ],
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:nillion-docs"
      ],
      "last_verified_at": "2026-06-09"
    },
    {
      "schema_version": "initiative-change.v1",
      "id": "encryption-privacy-pool-surface",
      "initiative_id": "encryption-tech-readiness",
      "type": "external_reference",
      "status": "reviewed",
      "summary": "Privacy pools and shielding systems can support private token-flow research, but maturity and compliance assumptions must be stated precisely.",
      "affected_roles": [
        "privacy_builders",
        "wallet_teams",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "token_privacy_builders",
        "wallet_privacy_teams",
        "compliance_privacy_researchers"
      ],
      "affected_protocols": [
        "privacy-pools",
        "kohaku",
        "railgun"
      ],
      "affected_chains": [
        "ethereum"
      ],
      "affected_intents": [
        "build-privacy-first-ethereum-wallet"
      ],
      "possible_consequences": [
        "Agents should distinguish mature wallet-integrated token privacy from WIP privacy pool research packages.",
        "Association-set or proof-of-innocence concepts should not be overclaimed as generic compliance guarantees.",
        "Builders should cite protocol-specific docs for supported assets, chains, and maturity before implementation."
      ],
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:privacy-pools-docs",
        "official:ethereum-privacy"
      ],
      "last_verified_at": "2026-06-09"
    },
    {
      "schema_version": "initiative-change.v1",
      "id": "encryption-private-state-surface",
      "initiative_id": "encryption-tech-readiness",
      "type": "protocol_architecture",
      "status": "reviewed",
      "summary": "Private-state applications need explicit design for what is private, what is public, and what metadata still leaks through execution, messaging, timing, and user behavior.",
      "affected_roles": [
        "privacy_builders",
        "app_builders",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "private_smart_contract_builders",
        "private_l2_builders",
        "wallet_builders"
      ],
      "affected_protocols": [
        "aztec",
        "helios"
      ],
      "affected_chains": [
        "ethereum"
      ],
      "affected_intents": [
        "build-private-smart-contract-app",
        "build-privacy-first-ethereum-wallet"
      ],
      "possible_consequences": [
        "Agents should force builders to write a privacy model before choosing implementation dependencies.",
        "Private smart contracts are not drop-in EVM contracts; Aztec-specific tooling and public/private state boundaries matter.",
        "Local verification and RPC/data-access choices may affect privacy-sensitive reads even when the app uses a privacy-preserving protocol."
      ],
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:aztec-docs",
        "official:ethereum-privacy"
      ],
      "last_verified_at": "2026-06-09"
    },
    {
      "schema_version": "initiative-change.v1",
      "id": "encryption-threshold-key-surface",
      "initiative_id": "encryption-tech-readiness",
      "type": "external_reference",
      "status": "reviewed",
      "summary": "Threshold and key-management systems are useful for access control, signing, and secret handling, but they are not a substitute for application-level privacy design.",
      "affected_roles": [
        "wallet_teams",
        "app_builders",
        "security_reviewers",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "wallet_builders",
        "agent_key_management_builders",
        "access_control_builders",
        "custody_teams"
      ],
      "affected_protocols": [],
      "affected_chains": [
        "ethereum"
      ],
      "affected_intents": [
        "build-privacy-first-ethereum-wallet",
        "build-agentic-commerce-with-x402"
      ],
      "possible_consequences": [
        "Agents should distinguish threshold signing, access control, secret release, and private computation.",
        "Key-management systems can reduce custody risk while still leaking app-level metadata if the user flow is public.",
        "Lit and similar systems should be added as first-class registry records before detailed readiness scoring."
      ],
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:lit-docs"
      ],
      "last_verified_at": "2026-06-09"
    },
    {
      "schema_version": "initiative-change.v1",
      "id": "encryption-wallet-privacy-surface",
      "initiative_id": "encryption-tech-readiness",
      "type": "external_reference",
      "status": "reviewed",
      "summary": "Wallet privacy requires user-flow and metadata analysis, not only an encryption primitive or private-address feature.",
      "affected_roles": [
        "wallet_teams",
        "privacy_builders",
        "hackathon_builders",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "wallet_builders",
        "private_receiving_builders",
        "token_privacy_builders",
        "demo_teams"
      ],
      "affected_protocols": [
        "fluidkey",
        "railgun",
        "kohaku",
        "privacy-pools",
        "helios"
      ],
      "affected_chains": [
        "ethereum",
        "arbitrum-one"
      ],
      "affected_intents": [
        "build-privacy-first-ethereum-wallet"
      ],
      "possible_consequences": [
        "Agents should separate private receiving, private token transfers, local verification, account recovery, and metadata leakage.",
        "Stealth-address style UX should not be described as full anonymity or full transaction-graph privacy.",
        "Hackathon demos should label mocked privacy components and avoid production security claims."
      ],
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:ethereum-privacy"
      ],
      "last_verified_at": "2026-06-09"
    },
    {
      "schema_version": "initiative-change.v1",
      "id": "encryption-zk-proof-surface",
      "initiative_id": "encryption-tech-readiness",
      "type": "external_reference",
      "status": "reviewed",
      "summary": "ZK proofs are best for proving a statement without revealing private inputs, not for making all app state or user activity private by default.",
      "affected_roles": [
        "privacy_builders",
        "smart_contract_developers",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "anonymous_membership_builders",
        "proof_verification_builders",
        "private_voting_builders",
        "credential_builders"
      ],
      "affected_protocols": [
        "semaphore",
        "maci",
        "aztec",
        "privacy-pools"
      ],
      "affected_chains": [
        "ethereum",
        "arbitrum-one",
        "optimism",
        "polygon"
      ],
      "affected_intents": [
        "build-private-onchain-voting",
        "build-private-smart-contract-app"
      ],
      "possible_consequences": [
        "Agents should ask for the proof statement before recommending a ZK stack.",
        "ZK can prove facts about private inputs, but metadata, public outputs, timing, and application logic may still leak information.",
        "Semaphore, MACI, Aztec, and Privacy Pools fit different ZK use cases and should not be treated as interchangeable."
      ],
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:noir-docs",
        "official:semaphore-docs",
        "official:maci-docs",
        "official:aztec-docs"
      ],
      "last_verified_at": "2026-06-09"
    }
  ]
}