{
  "schema_version": "initiative-changes.v1",
  "registry_version": "2026.06.10-8752c9d",
  "initiative_id": "encryption-tech-readiness",
  "change_count": 7,
  "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"
    }
  ]
}