Privacy primitives
66 reusable technical primitives — the building blocks that compose into case studies. Each rated against CROPS (Censorship Resistance, Open Source, Privacy, Security).
Atomic DvP via ERC-7573 (cross-network)
Enable atomic Delivery-versus-Payment across two networks so that either the asset is delivered and payment is completed, or the asset returns to the seller. The pattern targets institutions that need cross-network settlement with predictable failure behavior, auditability, and optional privacy extensions layered on top.
Attestation verifiable on-chain
Let smart contracts verify claims about an identity or off-chain fact without the contract or the public learning the underlying data. Trusted issuers sign attestations off-chain; verifiers check issuer signatures and revocation state on-chain and gate access on the result.
Commit-and-Prove Fallback
Coordinate a cross-chain settlement by having both parties post commitments to a shared secret witness `C = Com(w)`. Each leg of the trade references `C`, so auditors can link the two legs after the fact and each chain can verify its side against the same binding commitment. Atomicity is conditional: both legs settle independently, but neither can claim to have settled against a different commitment than the other.
Compliance Monitoring
Enable institutions to screen private transactions for regulatory compliance (AML, sanctions, fraud) without exposing transaction details to unauthorized parties. Balance privacy preservation with auditability through selective screening approaches and tiered disclosure, so settlement can proceed under compliance controls while counterparty identities and amounts remain shielded from public view.
Cross-Chain Privacy Bridge
Move assets between chains while preserving privacy on the destination by minting shielded notes whose ownership is not linkable to the source-domain depositor. Full sender and amount privacy requires privacy primitives on the source chain or pre-bridge anonymization; without these, the source lock transaction reveals the depositor address and amount.
Crypto-register bridge (eWpG) with EAS mirroring
Operate with a licensed crypto-register today while mirroring key legal facts (issuance, transfers, liens) as on-chain attestations. The registrar remains the legal source of truth; the on-chain anchor provides tamper evidence and paves the way for later automation once regulation allows.
Delegated Proving (co-SNARKs)
Offload zero-knowledge proof generation to a distributed prover network without revealing the witness. The user secret-shares their witness across several proving nodes; the nodes jointly run an MPC protocol to compute a single SNARK proof; no individual node ever reconstructs the full witness. The resulting proof is identical to one produced client-side and is verified on-chain or off-chain with no changes on the verifier side.
EIL (Ethereum Interoperability Layer)
Account-based cross-L2 interoperability where users sign once and execute transactions directly on multiple chains. Crosschain Liquidity Providers supply gas and liquidity via optimistic atomic swaps anchored in an L1 staking contract, but never execute calls on the user's behalf. Dispute resolution on L1 ensures funds cannot be lost or stolen.
ERC-3643 Tokenized RWAs
Enable compliant tokenization of real-world assets with built-in identity management, transfer restrictions, and regulatory rules enforced at the smart-contract level. Each transfer is gated by an on-chain identity check and a configurable compliance module before the underlying transfer executes.
FOCIL - Fork-Choice Enforced Inclusion Lists
Prevent censorship of Ethereum transactions by sophisticated block builders. A committee of 16 validators per slot can force-include transactions in the next block; non-compliant blocks fail fork-choice and cannot reach finality. The pattern provides no privacy on its own: transactions remain fully visible in the mempool and on chain. It guarantees only that a transaction cannot be censored once it reaches the public mempool.
Forced Withdrawal (L1 Escape Hatch)
When an L2 sequencer, relayer, or operator becomes unavailable, users need a unilateral path back to L1. Three pillars must hold simultaneously: the user has enough data to reconstruct their position, an L1 contract accepts proof of that position and releases funds, and the user can build the required proof on hardware they control. If any one leg fails, the escape hatch is ineffective.
Forward-Secure Signatures
Evolve a signing key over time so a signature produced under epoch `i`'s key remains verifiable later, but compromise at epoch `i+k` reveals only `epochSecret_{i+k}` and future epoch secrets. Past epoch secrets, and the privacy properties of past signatures (unlinkable nullifiers, addresses), remain protected.
Hybrid Public-Private Modes
Allow institutions to select public or private execution mode on a per-transaction or per-counterparty basis, optimizing for cost, latency, and confidentiality requirements. This enables hybrid workflows where some legs execute transparently on public infrastructure while others use privacy-preserving mechanisms, with atomic cross-mode settlement.
Hybrid TEE + ZK settlement
Coordinate private settlement inside a Trusted Execution Environment while anchoring correctness with a zero-knowledge proof verified on-chain. The enclave acts as a neutral synchronization layer between parties who do not trust each other: it matches orders, manages escrow state, and produces a succinct proof of correct execution. External observers see only commitments, proofs, and stealth-address outputs, while the enclave operator sees plaintext under contractual terms.
ICMA Bond Data Taxonomy (canonical terms/events)
Use the ICMA Bond Data Taxonomy as the canonical schema for bond terms and lifecycle events. A shared data model avoids fragmentation across issuance platforms, registrars, and regulators, and provides a stable foundation for attestations and zero-knowledge proofs over bond data.
L2 Privacy Evaluation Framework
Give institutions a vendor-neutral, sourced methodology for comparing privacy-preserving L2 solutions across performance and cost, privacy and Data Availability, and security and governance. The framework defines a common workload so that self-reported metrics can be placed next to independent benchmarks on the same axes.
Lean Ethereum
Plan a long-range redesign of the Ethereum consensus layer, targeting a single major fork around 2030 that consolidates several research tracks: post-quantum signatures, minimal zkVMs for signature aggregation and proof compression, reduced hardware and stake thresholds for validators, and networking upgrades that support a larger validator set. The goal is a consensus protocol that is stable for decades, resilient against quantum adversaries, and verifiable on minimal devices.
Low-cost L2 + Off-chain Encrypted Audit Log
Run settlement on a low-cost L2, publish only commitments and hashes on chain, and keep the full transaction facts in an append-only encrypted log off chain. Integrity is anchored by periodic Merkle roots submitted on chain. Regulators and auditors receive scoped decryption keys or predicate proofs. Delivery-versus-payment is expressed through an atomic settlement standard.
Mesh Store-and-Forward Submission
Carry encrypted application payloads from an offline or intermittently-connected sender to an online relay over a delay-tolerant mesh network, with end-to-end confidentiality (intermediate peers see only ciphertext) and source-fingerprinting resistance at the radio and network layers.
Mixnet Anonymity
Hide who is sending a transaction or querying state by routing messages through a network of mix nodes that batch, delay, reorder, and pad traffic with cover messages. Mixnets provide stronger sender anonymity than onion routing against global passive adversaries because timing correlation is defeated by design, at the cost of higher latency and bandwidth overhead.
Modular Privacy Stack
Compose a privacy architecture from four distinct layers: Data, Execution, Settlement, and Disclosure. Each layer is addressed by an interchangeable technology so that institutions can select the best-fit primitive per layer, upgrade layers independently, and keep interoperability through standardized interfaces.
MPC Custody and Transaction Control
Provide custody and controlled execution of digital-asset transactions by distributing key shares across a set of signers that jointly produce a valid signature without ever reconstructing the private key. The pattern eliminates single points of key compromise and enforces policy-based approvals before any signature is released.
Native Account Abstraction (EIP-8141)
Make every Ethereum account natively programmable by replacing the hardcoded ECDSA `ecrecover` check with user-defined validation logic at the protocol level. Transactions are processed through the regular mempool using transaction frames that separate validation from execution. The design removes bundler and relayer dependencies, enables native gas sponsorship, and unlocks privacy patterns that currently require trusted off-protocol infrastructure.
Network-Level Anonymity
Hide who is sending transactions or querying state at the network layer. Content-privacy patterns (ZK, FHE, MPC) hide what is in a transaction but not who submitted it: IP addresses, timing, and query patterns still leak sender identity. Network-level anonymity complements content privacy to close the metadata gap.
Noir Private Contracts
Give developers a privacy-focused DSL to write smart contracts that blend public logic with confidential private computation in the same contract. Private functions execute client-side and produce zero-knowledge proofs; public functions execute on the sequencer transparently. Private and public state can be composed in a single application.
Onion Routing
Hide who is sending transactions or querying state by routing traffic through a chain of relay nodes. Each relay peels one layer of encryption, so no single relay sees both the sender's IP and the destination. Onion routing closes the metadata gap left by content-privacy patterns, which hide what is in a transaction but not who submitted it.
Open Intent Framework (OIF)
Enable cross-chain intent-based settlement where users express desired outcomes and permissionless solvers compete to execute them across chains. The framework separates user intent (what) from execution strategy (how) and plugs into external settlement, oracle, and messaging layers.
Origin-Locked Cross-Chain Confidential Ledger
Provide confidential balances and transfers for an existing ERC-20 on an origin EVM chain, while keeping the asset locked and settled on the origin chain. Confidentiality logic runs on a separate execution layer that maintains an encrypted ledger and verifies ZK-proven state transitions. Unlike a privacy bridge or a privacy rollup, funds never leave the origin chain.
Permissioned Ledger Interoperability
Enable atomic transactions and data exchange across distinct permissioned ledgers, so that institutions can interoperate without exposing all contract state or migrating to a single ledger. Each domain keeps its own consensus and governance; a coordination protocol synchronizes commits across domains.
Permissionless Spend Auth
Separate note ownership from spend authorization in a shielded pool, and use a recursive inner-outer circuit architecture so that multiple auth methods can coexist without fragmenting the anonymity set. Users can rotate or add auth methods without moving funds, and observers cannot tell which method authorized a given spend.
Pre-trade Privacy (Encrypted Order Flow)
Prevent front-running and information leakage by routing quotes and orders via encrypted or private submission paths so intent, size, and price stay hidden until inclusion. Settlement then proceeds on a shielded pool or confidential rail so the executed amounts also remain private.
Privacy L2s
Use a privacy-native rollup, either ZK-based or FHE-based, to execute financial logic with private state. This enables confidential value and unlinkable identity flows in a programmable environment, while anchoring security on Ethereum L1 via a bridge.
Private Client Authentication for Institutional EOAs
Authenticate client externally-owned accounts in a way that satisfies regulatory KYC/AML requirements while preserving on-chain privacy. The institution maintains a Merkle tree of approved client EOAs; clients prove inclusion with a zero-knowledge proof plus a nullifier. Observers see neither the client's identity nor links between the client's other EOAs.
Private Intent-Based Vaults
Allow institutional and DeFi actors to express trading or allocation intents that a vault executes privately: strategy parameters, order flow, and risk exposure stay hidden while deposited assets remain transparently custodied and redeemable. Auditors receive scoped disclosure; the public sees only aggregate state.
Private ISO 20022 Messaging & Settlement
Coordinate private ERC-20 settlements between banks using ISO 20022 as the instruction layer. The ISO message binds to the on-chain cash leg, while the cash leg itself settles privately via a shielded mechanism (privacy L2, shielded pool, or confidential token) with regulator-only visibility.
Private PvP (cash to cash) Settlement via ERC-7573
Settle two stablecoin legs against each other atomically while keeping amounts and counterparties visible only to the transacting parties and their auditors. Each leg uses a shielded transfer layer for privacy; the ERC-7573 escrow pattern on both chains conditions release on verified finality of the opposite leg, so neither side settles without the other. The construction avoids the public amounts and timing leakage of plain HTLCs and avoids relying on time-locks for safety.
Private Set Intersection (Circuit-based)
Two parties each hold a private set and want to compute a function over their shared elements without either party learning the raw intersection. Intersection-finding logic is embedded in a Boolean circuit alongside the aggregate function F, so the output is limited to F(intersection). The circuit is evaluated jointly using authenticated garbling or secret-shared circuits, and the raw matches are not revealed to either party.
Private Set Intersection (DH-based)
Two parties each hold a private set of identifiers and want to learn which elements they share without exposing the rest. This variant uses commutative encryption via elliptic-curve Diffie-Hellman: both parties blind their inputs with secret scalars, and the commutativity of scalar multiplication lets them compare double-blinded values without revealing the originals. The protocol runs bilaterally between the two parties.
Private Set Intersection (FHE-based)
Two parties want to learn which elements they share without exposing non-matching entries. This variant uses Fully Homomorphic Encryption: the receiver encrypts their set under an FHE scheme and sends the ciphertexts; the sender homomorphically evaluates a matching polynomial against its own plaintext set and returns masked encrypted results; the receiver decrypts to learn the intersection. The construction suits asymmetric set sizes, minimises round count, and reduces to LWE/RLWE hardness for post-quantum security.
Private Set Intersection (OPRF-based)
Two parties each hold a private set of identifiers and want to learn which elements they share without exposing the rest. This variant uses Oblivious Pseudorandom Functions built on OT extensions: each party acts as the OPRF evaluator for the other's inputs, producing pseudorandom tags that match only when the underlying elements match. Cuckoo hashing compresses communication to O(n + m) with small constants, so the protocol scales to millions of elements where the DH-based variant becomes impractical.
Private Shared State (FHE)
Enable N parties to jointly read and write shared on-chain state (balances, positions, order books, collateral pools) while keeping each party's individual data private from the others and from the infrastructure operator. This variant stores state encrypted on-chain under a shared Fully Homomorphic Encryption key, runs state transitions as homomorphic operations on ciphertexts, and controls reads through a threshold decryption committee.
Private Shared State (MPC + ZK / co-SNARKs)
Enable N parties to jointly read and write shared on-chain state (balances, positions, order books, collateral pools) while keeping each party's individual data private from the others and from the infrastructure operator. This variant secret-shares each party's inputs across a distributed prover network; the nodes jointly run an MPC protocol to compute a single zero-knowledge proof of a correct state transition; the proof is posted on-chain for verification.
Private Shared State (TEE)
Enable N parties to jointly read and write shared on-chain state (balances, positions, order books, collateral pools) while keeping each party's individual data private from the others. This variant stores state encrypted to an enclave public key; a Trusted Execution Environment decrypts inputs, runs the state transition at native speed, and posts updated encrypted state plus a remote-attestation report proving which code ran.
Private Stablecoin Shielded Payments
Provide stakeholder-only stablecoin transfers on an L2 or app-chain, with viewing-key or zero-knowledge-proof-based disclosure to regulators and auditors, and the ability to compose atomically with asset legs (DvP) or other cash legs (PvP). Hide amounts, counterparties, and memos from non-participants while still enforcing any issuer-level or regulatory policy bound to the stablecoin.
Private Transaction Broadcasting
Hide transaction content from the public mempool before inclusion so that front-runners, sandwich bots, and competitors cannot observe or exploit pending trades. Transactions are routed through private relays or published as ciphertexts decrypted only after ordering, so adversaries see the transaction only once it is committed to a block.
Proof of Innocence (Association Set Proofs)
Let users prove their funds are not associated with illicit activity without revealing the deposit, transaction history, or counterparties. Two protocol variants exist: prove at withdrawal against a curated set root, or prove at deposit with proof propagation through subsequent transfers. Both rely on Merkle tree membership or exclusion proofs with zero-knowledge proofs and differ in timing, proof direction, and set management.
Recipient-Derived Receive Addresses
Generate Ethereum receive addresses deterministically from a long-lived recipient secret plus per-event context (e.g., event identifier, contract address, sequence number), such that an observer without the secret cannot predict, recognize, or link the addresses, while the recipient (with their secret) can re-derive the corresponding private key and spend the funds.
Relay-Mediated Proving
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`.
Safe Proof Delegation
Let a user delegate zero-knowledge proof generation to an external prover (a privacy RPC, a hardware accelerator, or a third-party service) without giving that prover the ability to forge, redirect, or overspend. The user signs a canonical intent digest that binds every material parameter; the prover can produce a valid proof that executes exactly that intent and nothing else.
Selective disclosure (viewing keys + zero-knowledge proofs)
Provide on-demand, scoped visibility into confidential trades and positions via threshold-controlled viewing keys or zero-knowledge predicate proofs that answer specific regulator questions. The institution keeps plaintext private by default and releases only the minimum information required to satisfy a specific, logged mandate.
Shielding
Enable confidential transfers by shielding balances, sender, and receiver, while still allowing regulators and auditors to verify via selective disclosure (viewing keys, proofs). The logic generalizes beyond ERC-20 to any transferable asset.
Social Recovery
Let a quorum of guardians authorize rotation of the signing key or enrollment anchor for an account or identity. A holder recovers after key loss or compromise without the original issuer, custodian, or centralized service.
Stateless Plasma Privacy
Use a stateless Plasma architecture to enable private token transfers where transaction data stays with users client-side, only commitments are posted on-chain, and validity is proven via zero-knowledge proofs. This provides strong transaction-graph privacy with L2 scalability, at the cost of moving data-availability responsibility to users.
Stealth Addresses
Enable unlinkable transfers on a transparent chain by deriving a one-time destination address per transaction using a Diffie-Hellman shared secret between sender and receiver keys. Observers see a transfer to a fresh address; only the recipient can detect and spend the funds.
TEE Key Manager
Run an institutional key manager inside an attested hardware-isolated environment. Keys are generated or imported inside the enclave, which enforces a signing policy and produces signatures while keeping private key material isolated from the host and operator. External systems bind the signer public key and policy hash to an approved attested measurement via an attestation verifier; on-chain registries can record this binding for audit.
TEE-Assisted Network Anonymity
Hide who is sending transactions or querying state at the network layer with latency low enough for interactive workloads. Content-privacy patterns hide what is in a transaction but not who submitted it; IP addresses, timing, and query patterns still leak sender identity. A client-side Trusted Execution Environment secret-shares the outbound payload across a set of servers so that no single server sees the cleartext, and the anonymity guarantee survives a compromise of the TEE at the cost of liveness.
TEE-Based Privacy
Use hardware-isolated execution environments to protect sensitive computation from the host operating system, hypervisor, and operator. The pattern provides hardware-enforced confidentiality and integrity for code and data while running, so privacy-preserving operations can be performed without exposing plaintext to infrastructure providers. This is a foundational pattern; specific applications (key management, settlement, matching) compose on top.
Threshold-encrypted mempool
Prevent miner-extractable-value extraction by encrypting transaction content before mempool submission and releasing the decryption key only after block ordering is committed. A distributed committee holds threshold key shares, so no single party can decrypt prematurely. The result is cryptographic protection against front-running, back-running, and sandwich attacks, without handing trust to any one relay.
TLS payment bridge
Enable trust-minimized fiat-to-on-chain swaps by combining instant payment rails with zero-knowledge TLS proofs. A taker pays fiat to a liquidity provider through a standard bank or payment-app rail, runs a zero-knowledge TLS session against the provider's confirmation page, and submits a proof to an on-chain escrow contract. The contract verifies that the payment occurred and releases crypto to the taker. No party custodies funds on behalf of the other, and full bank or account details are never revealed on-chain.
User-controlled viewing keys
In many privacy-preserving systems the institution operating the service holds viewing keys or equivalent decryption capabilities for all user transactions, which gives it surveillance power over users even when on-chain data is encrypted. User-controlled viewing keys invert that model: the user holds the private viewing key and selectively shares derived sub-keys with specific parties (regulators, auditors, counterparties) for scoped, time-limited access. This pattern is the institution-to-user complement to selective disclosure, which covers the workflow once a scoped key has been shared.
vOPRF Nullifiers
Generate deterministic, scope-bound nullifiers using a verifiable oblivious pseudorandom function (vOPRF) whose secret key is held by a threshold committee. The client blinds its input, the committee jointly evaluates the OPRF, and the client unblinds the response to derive a nullifier. The server key prevents offline reconstruction from a leaked client secret; verifiability lets the client detect a malicious committee response.
ZK Proof Systems
Give designers a decision framework for choosing a zero-knowledge proof system on Ethereum. A zero-knowledge proof lets one party prove a statement is true without revealing the inputs. The system's commitment scheme (elliptic-curve pairings, discrete log over curves, collision-resistant hashes, or lattices) drives its post-quantum posture; the setup model drives its trust assumption; proof size and prover and verifier cost drive deployment economics.
ZK Wrappers
Verify an off-chain digital signature over an existing credential inside a ZK circuit. The verifier learns that a valid signature exists and that chosen predicates hold over the signed payload, and nothing else.
zk-KYC/ML + ERC-734/735 identity claims
Publish identity claims on-chain that are backed by a zero-knowledge proof of an off-chain KYC or AML check, instead of a flat signature from a whitelisted issuer. The identity contract (ERC-734/735) holds the claims; a verifier contract checks the zero-knowledge proof at claim ingestion or at access time. The on-chain public sees that a qualified check was performed under a specific policy, without learning the subject's personal data.
zk-promises (stateful anonymous credentials)
Let a service enforce mutable compliance, moderation, or rate-limit rules on anonymous users without identifying them. The user holds a zk-object with private mutable state (reputation, compliance flags, ban status) as a commitment on an append-only bulletin board. The provider posts asynchronous callbacks that update the state without knowing which user is affected. On each interaction the user proves predicates over the current state via a zero-knowledge proof.
zk-TLS
Export verifiable data or identity attributes from a TLS-protected website into a form that an on-chain contract or a counterparty can check. The user jointly runs a TLS session with a notary; the notary signs a transcript of the session; the user produces a zero-knowledge proof over the signed transcript that discloses only the fields required downstream.