# Encryption Tech Readiness

> Evidence-backed guidance for agents and builders choosing FHE, MPC, ZK, threshold, and private-state technologies.

- Status: active
- Review status: reviewed
- Last verified: 2026-06-09

## Why it matters

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.

## Candidate change areas

### encryption fhe surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- 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.
- 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.

### encryption mpc surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- 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.
- 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.

### encryption privacy pool surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- Summary: Privacy pools and shielding systems can support private token-flow research, but maturity and compliance assumptions must be stated precisely.
- 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.

### encryption private state surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- 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.
- 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.

### encryption threshold key surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- 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.
- 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.

### encryption wallet privacy surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Wallet privacy requires user-flow and metadata analysis, not only an encryption primitive or private-address feature.
- 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.

### encryption zk proof surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- 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.
- 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.

## Initiative intents

- **Choose the right encryption or privacy primitive** (choose-encryption-primitive) — Map a privacy goal to FHE, MPC, ZK, private-state, threshold, or wallet privacy options with caveats and citations.
- **Plan a ZK privacy app** (plan-zk-privacy-app) — Choose between proof systems, anonymous membership, private voting, privacy pools, or private smart contracts for one app goal.
- **Assess whether FHE fits my app** (assess-fhe-fit) — Decide whether fully homomorphic encryption is useful for the app, or whether ZK, MPC, or private-state tooling is a better near-term path.
- **Assess whether MPC fits my app** (assess-mpc-fit) — Decide whether multiparty computation or threshold key management fits a privacy, custody, signing, or data-collaboration workflow.

## Official sources

- [Ethereum privacy overview](https://ethereum.org/en/privacy/)
- [Aztec documentation](https://docs.aztec.network/)
- [Noir documentation](https://noir-lang.org/docs)
- [Semaphore documentation](https://docs.semaphore.pse.dev/)
- [MACI documentation](https://maci.pse.dev/docs/introduction)
- [Kohaku Privacy Pools documentation](https://ethereum.github.io/kohaku/privacy-pools/intro)
- [Zama documentation](https://docs.zama.ai/)
- [Zama fhEVM documentation](https://docs.zama.ai/fhevm)
- [Fhenix documentation](https://docs.fhenix.zone/)
- [Nillion documentation](https://docs.nillion.com/)
- [Lit Protocol documentation](https://developer.litprotocol.com/)

## What the agent receives

```json
{
  "initiative": "encryption-tech-readiness",
  "name": "Encryption Tech Readiness",
  "status": "active",
  "registry_version": "2026.06.10-8752c9d",
  "supported_intents": [
    {
      "id": "choose-encryption-primitive",
      "title": "Choose the right encryption or privacy primitive",
      "related_changes": [
        "encryption-zk-proof-surface",
        "encryption-fhe-surface",
        "encryption-mpc-surface",
        "encryption-private-state-surface",
        "encryption-threshold-key-surface",
        "encryption-wallet-privacy-surface"
      ]
    },
    {
      "id": "plan-zk-privacy-app",
      "title": "Plan a ZK privacy app",
      "related_changes": [
        "encryption-zk-proof-surface",
        "encryption-private-state-surface",
        "encryption-privacy-pool-surface"
      ]
    },
    {
      "id": "assess-fhe-fit",
      "title": "Assess whether FHE fits my app",
      "related_changes": [
        "encryption-fhe-surface"
      ]
    },
    {
      "id": "assess-mpc-fit",
      "title": "Assess whether MPC fits my app",
      "related_changes": [
        "encryption-mpc-surface",
        "encryption-threshold-key-surface"
      ]
    }
  ],
  "changes": [
    {
      "id": "encryption-fhe-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "privacy_builders",
        "app_builders",
        "ai_agents"
      ],
      "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."
      ],
      "evidence_refs": [
        "official:zama-docs",
        "official:fhevm-docs",
        "official:fhenix-docs"
      ]
    },
    {
      "id": "encryption-mpc-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "wallet_teams",
        "app_builders",
        "security_reviewers",
        "ai_agents"
      ],
      "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."
      ],
      "evidence_refs": [
        "official:nillion-docs"
      ]
    },
    {
      "id": "encryption-privacy-pool-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "privacy_builders",
        "wallet_teams",
        "ai_agents"
      ],
      "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."
      ],
      "evidence_refs": [
        "official:privacy-pools-docs",
        "official:ethereum-privacy"
      ]
    },
    {
      "id": "encryption-private-state-surface",
      "type": "protocol_architecture",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "privacy_builders",
        "app_builders",
        "ai_agents"
      ],
      "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."
      ],
      "evidence_refs": [
        "official:aztec-docs",
        "official:ethereum-privacy"
      ]
    },
    {
      "id": "encryption-threshold-key-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "wallet_teams",
        "app_builders",
        "security_reviewers",
        "ai_agents"
      ],
      "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."
      ],
      "evidence_refs": [
        "official:lit-docs"
      ]
    },
    {
      "id": "encryption-wallet-privacy-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "wallet_teams",
        "privacy_builders",
        "hackathon_builders",
        "ai_agents"
      ],
      "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."
      ],
      "evidence_refs": [
        "official:ethereum-privacy"
      ]
    },
    {
      "id": "encryption-zk-proof-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "privacy_builders",
        "smart_contract_developers",
        "ai_agents"
      ],
      "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."
      ],
      "evidence_refs": [
        "official:noir-docs",
        "official:semaphore-docs",
        "official:maci-docs",
        "official:aztec-docs"
      ]
    }
  ]
}
```

---
Canonical: https://composewith.eth/initiatives/encryption-tech-readiness · JSON: https://composewith.eth/initiatives/encryption-tech-readiness/index.json