chore: fix 18 terminology inconsistencies

CHANGELOG.md

@@ -6,7 +6,8 @@ All notable changes to the EthSystems Map are documented here.
 
 - docs: add Espalier preprint reference to [ZK Proof Systems](patterns/pattern-zk-proof-systems.md), [Post-Quantum Threats](domains/post-quantum.md), and [Safe Proof Delegation](patterns/pattern-safe-proof-delegation.md) `## See also` sections
 - feat(jurisdiction): [EU / EUDR (Deforestation Regulation)](jurisdictions/eu-EUDR.md) -- Article 9 plot-level geolocation and the DDS reference-number model, ahead of the 30 December 2026 application date ([#181](https://github.com/ethsystems/map/pull/181))
-- fix(vendor): [Zama](vendors/zama.md) — mainnet maturity, symbolic-execution architecture, TFHE-rs, ERC-7984; sync fhEVM status and docs link in [Private Shared State (FHE)](patterns/pattern-private-shared-state-fhe.md) ([#180](https://github.com/ethsystems/map/pull/180))
+- fix(vendor): [Zama](vendors/zama.md) -- mainnet maturity, symbolic-execution architecture, TFHE-rs, ERC-7984; sync fhEVM status and docs link in [Private Shared State (FHE)](patterns/pattern-private-shared-state-fhe.md) ([#180](https://github.com/ethsystems/map/pull/180))
+- chore: fix 18 terminology inconsistencies across 11 files -- ZK proof, zk-SNARK, Data Availability, FHE encryption, ERC-3643 ([#67](https://github.com/ethsystems/map/issues/67))
 
 ## [0.4.0] - 2026-07-02
 

patterns/pattern-relay-mediated-proving.md

@@ -57,7 +57,7 @@ open_source_implementations:
 
 ## Intent
 
-Split a typical ZK proof flow into two roles. The client signs a portable signed message offline. A relay generates the SNARK over that message and submits it on-chain. To prevent a front-runner from lifting the proof off the mempool and re-submitting it from their own address, the proof binds to the relay's submitter address as a public input that the application contract checks against `msg.sender`.
+Split a typical zero-knowledge proof flow into two roles. The client signs a portable signed message offline. A relay generates the SNARK over that message and submits it on-chain. To prevent a front-runner from lifting the proof off the mempool and re-submitting it from their own address, the proof binds to the relay's submitter address as a public input that the application contract checks against `msg.sender`.
 
 The pattern is distinct from `pattern-safe-proof-delegation.md`, which addresses intent-based delegation in a wallet UX context (the client *could* prove locally but chooses to delegate). Relay-mediated proving is for clients that cannot prove locally at all.
 

use-cases/private-registry.md

@@ -79,7 +79,7 @@ Approach TBD. Key architectural considerations:
 - How do privacy-preserving registries interact with existing registry legal frameworks (e.g., eWpG crypto-registry requirements)?
 - What is the minimum viable cross-border registry query protocol that satisfies both privacy and sovereignty requirements?
 - How to handle registry corrections (errors, court orders) in an append-only privacy-preserving system?
-- What trust assumptions must registered entities make about the registry operator (liveness, censorship resistance, data availability, honest state transitions), and how can these be minimized or made verifiable?
+- What trust assumptions must registered entities make about the registry operator (liveness, censorship resistance, Data Availability, honest state transitions), and how can these be minimized or made verifiable?
 
 ## 7) Notes And Links
 

use-cases/resilient-identity-continuity.md

@@ -67,7 +67,7 @@ Key loss in issuer-independent systems is permanent unless recovery mechanisms e
 
 ### Problem 4: Universal Verification Without Registry or Issuer Contact
 
-Verification in existing private identity systems often requires contacting a registry operator or issuer for revocation checks or credential status. In an issuer-hostile setting, verification must work with the on-chain trust anchor and a ZK proof, without external service calls.
+Verification in existing private identity systems often requires contacting a registry operator or issuer for revocation checks or credential status. In an issuer-hostile setting, verification must work with the on-chain trust anchor and a zero-knowledge proof, without external service calls.
 
 **Requirements:**
 
@@ -83,7 +83,7 @@ Verification in existing private identity systems often requires contacting a re
 | Credential anchoring | On-chain commitment via distributed enrollment | No issuer dependency after enrollment |
 | Sybil resistance | Layered (cryptographic + economic + social) | Degrades gracefully when credential sources are compromised |
 | Recovery | Threshold (Shamir) + social (guardian-based) | No issuer participation required |
-| Verification | Universal (on-chain trust anchor + ZK proof) | Any verifier, no registry contact |
+| Verification | Universal (on-chain trust anchor + zero-knowledge proof) | Any verifier, no registry contact |
 
 See the [**Issuer-Independent Enrollment approach**](../approaches/approach-private-identity.md#issuer-independent-enrollment-via-distributed-oprf) for detailed architecture and trade-offs.
 

vendors/fairblock.md

@@ -10,11 +10,11 @@ maturity: testnet
 
 Fairblock provides confidential balances and transfers for assets (e.g., stablecoins) that remain issued and liquid on an originating chain (e.g., EVM networks), while confidentiality logic executes on **FairyRing**, a purpose-built confidentiality execution layer.
 
-The core idea is a cross-chain confidential layer: users lock tokens into a minimal smart contract on the originating chain, receive an encrypted balance maintained by FairyRing, and execute confidential transfers backed by ZK proofs and homomorphic balance updates, then optionally withdraw back to the originating chain.
+The core idea is a cross-chain confidential layer: users lock tokens into a minimal smart contract on the originating chain, receive an encrypted balance maintained by FairyRing, and execute confidential transfers backed by zero-knowledge proofs and homomorphic balance updates, then optionally withdraw back to the originating chain.
 
 ## Fits with patterns
 
-- [Selective disclosure (viewing keys + ZK proofs)](../patterns/pattern-regulatory-disclosure-keys-proofs.md): scoped disclosure for audit and compliance workflows
+- [Selective disclosure (viewing keys + zero-knowledge proofs)](../patterns/pattern-regulatory-disclosure-keys-proofs.md): scoped disclosure for audit and compliance workflows
 
 ## Not a substitute for
 
@@ -31,7 +31,7 @@ High-level components:
    - User-facing interface for deposit/transfer/withdraw flows
 2. FairyRing: confidentiality execution layer
    - CosmWasm contracts maintain an encrypted chain
-   - Verifies ZK proofs for valid encrypted state transitions
+   - Verifies zero-knowledge proofs for valid encrypted state transitions
    - Performs lightweight homomorphic add/subtract for balance updates
 3. Cross-chain messaging (IBC-style)
    - Relays packets between the origin chain and FairyRing
@@ -61,7 +61,7 @@ FairyRing supports selective disclosure for audits and investigations via scoped
 ## Technical details
 
 - Cross-chain design connecting an origin chain locking contract with FairyRing as confidentiality layer
-- Encrypted layer and ZK proof verification for valid state transitions
+- Encrypted layer and zero-knowledge proof verification for valid state transitions
 - Lightweight homomorphic operations for balance updates
 - Threshold IBE for scoped selective disclosure
 

vendors/fhenix.md

@@ -15,7 +15,7 @@ Fhenix builds a CoProcessor that brings Fully Homomorphic Encryption (FHE) to EV
 - [Private Stablecoin Shielded Payments](https://github.com/ethsystems/map/blob/master/patterns/pattern-private-stablecoin-shielded-payments.md) - FHE enables encrypted balances and amounts, supporting fully confidential stablecoin transfers.
 - [Private Intent-Based Vaults](https://github.com/ethsystems/map/blob/master/patterns/pattern-private-vaults.md) - FHE-powered execution allows vault strategies to run privately while preserving on-chain auditability of assets.
 - [Shielded ERC-20 Transfers](https://github.com/ethsystems/map/blob/master/patterns/pattern-shielding.md) - Native FHE support provides encrypted ERC-20 transfer flows for end-to-end confidentiality.
-- [Confidential ERC3643](https://github.com/ethsystems/map/blob/master/patterns/pattern-erc3643-rwa.md) - FHE makes it possible to extend ERC3643 into a confidential standard with private, enforceable compliance logic.
+- [Confidential ERC-3643](https://github.com/ethsystems/map/blob/master/patterns/pattern-erc3643-rwa.md) - FHE makes it possible to extend ERC-3643 into a confidential standard with private, enforceable compliance logic.
 - [Private L2s](https://github.com/ethsystems/map/blob/master/patterns/pattern-privacy-l2s.md) - Fhenix’s CoFHE serves as an FHE coprocessor enabling privacy-preserving rollups and encrypted execution environments.
 
 ## Not a substitute for
@@ -29,7 +29,7 @@ CoFHE, Fhenix’s encrypted-computation coprocessor, enables smart contracts to
 
 ## Privacy domains
 
-- FHE encryption at the contract and variable level.
+- Fully Homomorphic Encryption at the contract and variable level.
 - Supports hybrid models (FHE + ZK for verification).
 
 ## Enterprise demand and use cases

vendors/miden.md

@@ -10,7 +10,7 @@ maturity: PoC
 
 Polygon Miden is a privacy focused Ethereum rollup (zk-zk-rollup) that prioritizes throughput and privacy over full EVM compatibility. It uses the Miden VM, a STARK-based virtual machine designed for client-side proving.
 
-Unlike Ethereum (where the network executes everything), Miden pushes execution to the user (the "Edge"). Users execute their own transactions locally, generate a ZK proof, and the network simply verifies the proof and updates the state.
+Unlike Ethereum (where the network executes everything), Miden pushes execution to the user (the "Edge"). Users execute their own transactions locally, generate a zero-knowledge proof, and the network simply verifies the proof and updates the state.
 
 ## Fits with patterns
 

vendors/paladin.md

@@ -40,12 +40,12 @@ A strong design principle of the project is that existing privacy preserving tok
   - UTXO-based privacy preserving tokens
   - FHE based confidential tokens (future plans)
   - Private EVM contracts in privacy groups
-- Key management integrates with enterprise HSM/SSM; supports native Ethereum signing, EIP-712 endorsements, ZKP proof generation, as well as FHE wallet-side cryptography in future plans.
+- Key management integrates with enterprise HSM/SSM; supports native Ethereum signing, EIP-712 endorsements, zero-knowledge proof generation, as well as FHE wallet-side cryptography in future plans.
 - Programming model includes plug points for:
   - Wallet functions (coin/state indexing and selection for submission)
   - Endorsement coordination and signature collection with flexible endorsement policies
   - Distributed sequencer for transaction coordination
-  - Proof generation (ZK proofs, notary certificates, and others)
+  - Proof generation (zero-knowledge proofs, notary certificates, and others)
   - High-performance code modules in Java and WebAssembly
 
 Privacy domains are implementations of a plug-point for the on-chain logic (pure on-chain EVM), and the app-layer logic (proof systems, merkle tree management, private EVM execution, endorsement/attestation coordination), that are the common components of every privacy-preserving smart contract in the EVM ecosystem.
@@ -56,7 +56,7 @@ Hardened reference implementations are provided out of the box as follows:
 
 - Zeto (ZK UTXO tokens)
   - Onchain commitments hide ownership/amounts/history of the UTXOs.
-  - Enforces mass conservation and other spending policies (KYC, auditability, etc.) via ZK proofs.
+  - Enforces mass conservation and other spending policies (KYC, auditability, etc.) via zero-knowledge proofs.
   - Currently implemented with zkSNARKs in Circom based circuits, using groth16 by default.
   - Paladin runtime includes a token indexer, UTXO selector, and proof generator.
   - Optional ERC20 bridge via deposit/withdraw.
@@ -85,7 +85,7 @@ Hardened reference implementations are provided out of the box as follows:
   - Transport principles: asynchronous message transfer, idempotent requests with retries, end-to-end encryption even via hubs/buses.
 - Approval-based atomic transactions (DvP/PvP)
   - Pre-approval/setup: parties reach a private state root; prepare token transfers.
-  - Approval/prepare: swap contract deployed; each domain pre-approves (privacy group endorsement, notary approval, ZK proof).
+  - Approval/prepare: swap contract deployed; each domain pre-approves (privacy group endorsement, notary approval, zero-knowledge proof).
   - Execution/commit: call execute() on the swap contract; all sub-transactions commit or revert atomically.
   - Post-execution: domains remain independent; provenance is hidden except to entitled parties.
 

vendors/railgun.md

@@ -9,7 +9,7 @@ maturity: production
 ## What it is
 
 Railgun is a set of smart contracts providing **shielded transfers and private DeFi interactions** on Ethereum and other EVM-compatible chains.  
-It uses zkSNARKs to maintain a UTXO-like note system (commitments and nullifiers) that allows users to send, receive, and interact with DeFi protocols while hiding wallet balances and transaction details.
+It uses zk-SNARKs to maintain a UTXO-like note system (commitments and nullifiers) that allows users to send, receive, and interact with DeFi protocols while hiding wallet balances and transaction details.
 
 ## Fits with patterns
 
@@ -27,7 +27,7 @@ It uses zkSNARKs to maintain a UTXO-like note system (commitments and nullifiers
 ## Architecture
 
 - **Execution model**: UTXO-style commitments (`note commitments`, `nullifiers`) stored in smart contracts.
-- **Proof system**: zkSNARKs (Groth16) validate note creation and spending.
+- **Proof system**: zk-SNARKs (Groth16) validate note creation and spending.
 - **Settlement**: ERC-20/ERC-721/ERC-1155 tokens are deposited into Railgun contracts, converted to private notes, then spent/withdrawn.
 - **Integration**: Railgun “Adapt Modules” allow private interactions with existing DeFi protocols by wrapping function calls.
 - **Data availability**: all commitments stored publicly on-chain; privacy relies on zk proofs, not off-chain DA.
@@ -46,7 +46,7 @@ It uses zkSNARKs to maintain a UTXO-like note system (commitments and nullifiers
 
 ## Technical details
 
-- zkSNARK proving via Groth16, circuit for note validity and nullifier uniqueness.
+- zk-SNARK proving via Groth16, circuit for note validity and nullifier uniqueness.
 - Smart contract architecture deployed on Ethereum mainnet, BNB Chain, Polygon, and others.
 - UTXO model: each note represents a claim on deposited tokens; nullifiers prevent double spends.
 - Adapt Modules: special contracts that wrap DeFi calls (e.g. swaps, lending) to preserve privacy of user identity.
@@ -63,7 +63,7 @@ It uses zkSNARKs to maintain a UTXO-like note system (commitments and nullifiers
 - **No regulator-oriented audit path**: may limit institutional adoption.
 - **Prover costs & UX**: Groth16 proofs are relatively heavy for end-users, requiring wallet integration, high gas operations (~2m).
 - **On-chain DA**: all commitments are public; long-term scalability may be constrained.
-- **Trust assumptions**: requires careful ceremony setup for zkSNARK parameters (trusted setup).
+- **Trust assumptions**: requires careful ceremony setup for zk-SNARK parameters (trusted setup).
 
 ## Links
 

vendors/renegade.md

@@ -9,7 +9,7 @@ maturity: production
 ## What it is
 
 Renegade is a decentralized dark pool protocol for trading digital assets.  
-It combines **maliciously-secure MPC** (for private order matching) with **zkSNARK proofs** (for verifiable settlement), ensuring balances, orders, and trade history remain confidential while still settling on-chain.
+It combines **maliciously-secure MPC** (for private order matching) with **zk-SNARK proofs** (for verifiable settlement), ensuring balances, orders, and trade history remain confidential while still settling on-chain.
 
 ## Fits with patterns
 
@@ -28,7 +28,7 @@ It combines **maliciously-secure MPC** (for private order matching) with **zkSNA
 - **Wallet model**: Each trader has a private wallet committed on-chain (`C(W) = H(B||O||F||K||r)`), with balances and orders hidden.
 - **Key hierarchy**: Separate keys for root control, order matching, settlement, and viewing. Enables delegation without loss of custody.
 - **Order matching**: Performed in MPC clusters (SPDZ-style protocols), ensuring neither relayers nor counterparties learn each other’s hidden state.
-- **Settlement**: MPC outputs are wrapped in a collaborative zkSNARK that proves correct matching. Settlement notes are encrypted under counterparties’ keys and appended to the global commitment tree.
+- **Settlement**: MPC outputs are wrapped in a collaborative zk-SNARK that proves correct matching. Settlement notes are encrypted under counterparties’ keys and appended to the global commitment tree.
 - **Relayers**: Traders typically delegate matching to relayer clusters; relayers coordinate MPC handshakes but never see balances or order flow.
 
 ## Privacy domains
@@ -47,7 +47,7 @@ It combines **maliciously-secure MPC** (for private order matching) with **zkSNA
 
 ## Technical details
 
-- Proof system: zkSNARKs (Groth16-style collaborative proofs).
+- Proof system: zk-SNARKs (Groth16-style collaborative proofs).
 - MPC protocols: maliciously-secure SPDZ variants for order matching.
 - Commitment scheme: Merkle trees for wallets and nullifiers.
 - Encrypted settlement notes bound to on-chain commitments.
@@ -57,7 +57,7 @@ It combines **maliciously-secure MPC** (for private order matching) with **zkSNA
 
 - Eliminates MEV: no pre-trade or post-trade transparency.
 - Fully private balances and orders, unlike lit AMMs.
-- On-chain verifiability via zkSNARK proofs.
+- On-chain verifiability via zk-SNARK proofs.
 - Delegation model allows separation of custody, matching, and settlement.
 
 ## Risks and open questions