Encryption Tech Readiness
Evidence-backed guidance for agents and builders choosing FHE, MPC, ZK, threshold, and private-state technologies.
Choose the stack before you ship.
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.
Composewith separates stack layers, registry coverage gaps, implementation caveats, and official source evidence so agents can recommend a credible path without overclaiming maturity.
Tracked surfaces and consequences.
Each record maps a stack surface to affected roles, likely builder consequences, recommended action, and official evidence refs.
encryption fhe surface actionable
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.
Action: assess · Priority: medium · Status: reviewed
- 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 actionable
MPC fits workflows where multiple parties compute or manage secrets without centralizing the full secret, but trust, liveness, and operational assumptions must be explicit.
Action: assess · Priority: medium · Status: reviewed
- 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 actionable
Privacy pools and shielding systems can support private token-flow research, but maturity and compliance assumptions must be stated precisely.
Action: assess · Priority: medium · Status: reviewed
- 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 actionable
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.
Action: assess · Priority: high · Status: reviewed
- 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 actionable
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.
Action: assess · Priority: medium · Status: reviewed
- 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 actionable
Wallet privacy requires user-flow and metadata analysis, not only an encryption primitive or private-address feature.
Action: assess · Priority: high · Status: reviewed
- 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 actionable
ZK proofs are best for proving a statement without revealing private inputs, not for making all app state or user activity private by default.
Action: assess · Priority: high · Status: reviewed
- 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.
Encryption Tech Readiness intents.
Agents should pick one of these initiative intents before answering or charging for a paid assessment call.
Choose the right encryption or privacy primitive
Map a privacy goal to FHE, MPC, ZK, private-state, threshold, or wallet privacy options with caveats and citations.
Inputs: privacy goal, data that must remain hidden, who computes on the data, who verifies the result, chain or offchain constraints, timebox and production expectations
Plan a ZK privacy app
Choose between proof systems, anonymous membership, private voting, privacy pools, or private smart contracts for one app goal.
Inputs: proof statement, group or credential model, need for private tally or nullifiers, smart contract requirements, verifier chain
Assess whether FHE fits my app
Decide whether fully homomorphic encryption is useful for the app, or whether ZK, MPC, or private-state tooling is a better near-term path.
Inputs: computation to run on encrypted data, latency tolerance, ciphertext data model, chain/runtime target, hackathon versus production timeline
Assess whether MPC fits my app
Decide whether multiparty computation or threshold key management fits a privacy, custody, signing, or data-collaboration workflow.
Inputs: parties involved, data or key material to split, trust and liveness assumptions, custody or computation goal, online/offline requirements
Structured initiative guidance.
{
"initiative": "encryption-tech-readiness",
"name": "Encryption Tech Readiness",
"status": "active",
"review_status": "reviewed",
"registry_version": "2026.06.10-8752c9d",
"instruction": "Fetch this initiative record before answering Encryption Tech Readiness-related stack, architecture, tooling, risk, or implementation questions. Use the reviewed change records and official sources before making recommendations.",
"supported_intents": [
{
"id": "choose-encryption-primitive",
"title": "Choose the right encryption or privacy primitive",
"audience": [
"privacy_builders",
"hackathon_builders",
"ai_agents"
],
"default_priority": "high",
"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",
"audience": [
"privacy_builders",
"ai_agents"
],
"default_priority": "high",
"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",
"audience": [
"app_builders",
"privacy_builders",
"ai_agents"
],
"default_priority": "medium",
"related_changes": [
"encryption-fhe-surface"
]
},
{
"id": "assess-mpc-fit",
"title": "Assess whether MPC fits my app",
"audience": [
"app_builders",
"wallet_teams",
"ai_agents"
],
"default_priority": "medium",
"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"
],
"affected_builder_groups": [
"confidential_compute_builders",
"encrypted_data_app_teams",
"hackathon_builders"
],
"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"
],
"affected_builder_groups": [
"collaborative_compute_builders",
"custody_builders",
"key_management_teams",
"data_collaboration_teams"
],
"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"
],
"affected_builder_groups": [
"token_privacy_builders",
"wallet_privacy_teams",
"compliance_privacy_researchers"
],
"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"
],
"affected_builder_groups": [
"private_smart_contract_builders",
"private_l2_builders",
"wallet_builders"
],
"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"
],
"affected_builder_groups": [
"wallet_builders",
"agent_key_management_builders",
"access_control_builders",
"custody_teams"
],
"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"
],
"affected_builder_groups": [
"wallet_builders",
"private_receiving_builders",
"token_privacy_builders",
"demo_teams"
],
"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"
],
"affected_builder_groups": [
"anonymous_membership_builders",
"proof_verification_builders",
"private_voting_builders",
"credential_builders"
],
"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"
]
}
],
"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/"
}
],
"non_goals": [
"Do not collapse distinct stack layers into a single tooling recommendation.",
"Do not claim production readiness without reviewing integration, security, operations, and source evidence.",
"Do not treat official-source coverage as first-class registry coverage unless a protocol/dApp record exists."
]
}Official sources first.
Composewith summarizes and structures official inputs. It does not replace project documentation, protocol specifications, security reviews, or implementation guides.
Formats: Markdown · JSON · Agent JSON · Changes JSON