# Privacy Protocol Funding: Coordination and Infrastructure

## Executive Summary

**All protocols deliver privacy. None deliver interoperability.** That's my read of the current state. The failure mode isn't cryptography; it's incompatibility.

Privacy works technically. Railgun, Privacy Pools, zkBob, and Blanksquare are live on mainnet. Users can transact privately today. But two critical failures prevent adoption: protocols can't talk to each other (coordination failure), and the user experience is broken (infrastructure failure).

If permissionless privacy ignores enterprise needs, the future won't be private; it will be privatized. Enterprises are already choosing permissioned infra over fragmented permissionless protocols. Every quarter this continues, the ecosystem bifurcates further into centralized privacy for institutions and fragmented privacy for retail.

We need to fund infrastructure that benefits all protocols equally. This document proposes two funding tracks:

1. **Research-based funding** for coordination questions (relayer adapters, auditable privacy standards, proof aggregation)
2. **Application-based funding** for practical tooling (wallet modules, viewing key management, proving benchmarks)

Coordination may be impossible. Tooling is definitely solvable. We should fund both.

## Document Structure

1. **Current State:** What exists and why it's fragmented
2. **Coordination Failure:** Why protocols can't interoperate (architectural incompatibility)
3. **Infrastructure Failure:** Why UX is broken (practical gaps we can fix)
4. **Funding Tracks:** Research (high risk) vs Tooling (guaranteed value)
5. **Recommendations:** What to fund first

## Current State of Privacy

| Solution | Privacy Model | Cryptography | Compliance Approach | Status |
|----------|--------------|--------------|---------------------|--------|
| **Privacy Pools** | Mixer with ASP | Poseidon + Groth16 | ASP exclusion proofs | [Live](https://privacypools.com/) |
| **Railgun** | Shielded pool | Baby Jubjub + Poseidon | Viewing keys + POI | [Live](https://railgun.org/) |
| **zkBob** | Shielded pool | Baby Jubjub + Poseidon | Optional KYC + limits | [Live](https://zkbob.com/) |
| **Blanksquare** | Shielded pool | Poseidon + Groth16 | TEE involuntary reveal | [Live](https://app.blanksquare.io/) |
| **Hinkal** | Shielded pool | Baby Jubjub + Poseidon + Groth16 | Optional KYC + limits | [Live](https://hinkal.pro/) |
| **Plasma** | Stealth addresses + encrypted memos | EVM-native Solidity | Selective disclosure | [Research](https://docs.plasma.to/docs/plasma-chain/stablecoin-native-contracts/confidential-payments) |
| **Umbra Cash** | Stealth addresses | Baby Jubjub + ECDH | None (stealth only) | [Live](https://app.umbra.cash/) |
| **Fluidkey** | Stealth addresses | ECDH | None (stealth only) | [Live](https://fluidkey.com/) |
| **WORM (EIP-7503)** | zkWormhole (burn/mint) | ZK proofs | Built-in anonymity set | [Proposal](https://eips.ethereum.org/EIPS/eip-7503) |
| **Scroll Cloak** | Validium | Optimized ZK circuits | Permissioned sequencer | [Live](https://scroll.io/blog/introducing-cloak) |
| **zkSync Prividium** | Validium | Optimized ZK circuits | Permissioned sequencer | [Live](https://zksync.mirror.xyz/-22Hu5ugeOtchnp1ut44Zehfh5yolKlu9nubFdJLMD0) |
| **Payy** | Validium wallet | Optimized ZK circuits | Permissioned sequencer | [Live](https://docs.payy.network/) |
| **Aztec** | Encrypted execution | Noir circuits + Honk | Programmable compliance | [Testnet](https://aztec.network/) |

**Note:** Not exhaustive. PSE maintains a comprehensive [Private Writes Overview](https://pse-team.notion.site/Private-Writes-Overview-261d57e8dd7e8021aa90cd690d1e517c) covering more: encrypted tokens (FHE/HE), statistical obfuscators, private L2s, etc.

**Quick primer on categories:**
- **Mixers** (Privacy Pools): Deposit, mix with others, withdraw later. No internal transfers.
- **Shielded pools** (Railgun, zkBob, Blanksquare, Hinkal): Deposit into encrypted state where you can make internal transfers between shielded addresses before withdrawing.
- **Stealth addresses** (Umbra, Fluidkey, Plasma): Generate one-time destination addresses so recipient's main address never appears on-chain. Plasma adds encrypted memos and selective disclosure for their stablecoin. Solves unlinkability, not amount hiding.
- **Validiums** (Cloak, Prividium, Payy): Enterprises run their own sequencer. Different branding (Cloak for payments, Prividium for tokenization, Payy for wallet+card) but similar architecture. Better than alt-L1s since they stay in EVM/Ethereum, but centralized.
- **Aztec**: Encrypted execution environment. Apps define compliance through programmable circuits. Different beast entirely.
- **Private computation**: Research on private smart contract execution. [zkzkEVM approach](https://ethresear.ch/t/zkzkevm-private-evm/21854) uses pstore/pload opcodes for private storage while maintaining EVM compatibility.

The key limitation is **fragmented liquidity**. Users can't move between protocols privately. Each operates as an isolated island.

## Why Fragmentation Matters

The problem is privacy fragmentation creates deep uncertainty for developers. The core issue isn't whether users can bridge between pools, it's **which privacy protocol applications will integrate with**. Because users follow applications, each app's choice can lock users into separate silos.

A DeFi protocol choosing Railgun means users need Railgun wallets. A dApp choosing Privacy Pools means users need Privacy Pools wallets. Without interoperability, users end up managing multiple privacy identities just to use different applications.

This uncertainty makes it difficult for developers to decide where to invest. Every integration with Railgun, Privacy Pools, or zkBob requires unique work. Without a clear standard, each one is a gamble.

**My view on funding:** Support tools that benefit all protocols equally. Grants that improve only one privacy system reinforce its dominance and worsen fragmentation. True progress depends on neutral tooling that promotes ecosystem-wide adoption.

### The Enterprise Alternative

Scroll Cloak and zkSync Prividium are the same thing: zk-validium infrastructure where enterprises run their own private instance. Each business gets its own sequencer, prover, and bridge contracts. Transactions stay off-chain in a private ledger. Only ZK proofs post to L1/L2.

**Why enterprises choose this**
- Control sequencer and compliance
- Sub-2 second proving, near-zero fees
- Full EVM compatibility
- Selective disclosure for regulators

**The tradeoff** is speed and compliance but centralized. Enterprise sees everything. Users trust the business, not cryptographic guarantees.

**This matters** because if permissionless protocols don't serve enterprise needs, businesses choose this. Two-tier ecosystem. Enterprise gets fast, compliant, centralized privacy. Retail gets decentralized but fragmented privacy. The opportunity is auditable privacy standards that work on permissionless infrastructure without requiring enterprises to control user data.

### The Regulatory Case for Privacy

Traditional AML surveillance is [expensive and ineffective](https://www.coincenter.org/comment-of-coin-center-on-treasurys-request-for-comment-on-innovative-methods-to-detect-illicit-activity-involving-digital-assets/). UN estimates less than 0.2% of criminal proceeds are intercepted. US financial institutions spend $26B annually on compliance. Meanwhile, naive AML implementation on public blockchains creates perfect surveillance: real-world identity linked to complete on-chain transaction history. Unlike fragmented banking where data is dispersed, blockchain ledgers are singular, global, immutable.

Coin Center argues privacy-preserving blockchains are "regulatory upgrade, not loophole." You can verify compliance through cryptographic assurance rather than bulk data collection. Treasury should encourage stablecoin issuance on privacy chains and support privacy tools like Privacy Pools. The alternative is transparent chains that link identities to transactions that creates irreversible surveillance infrastructure.

The view key debate matters here. Universal view keys (where issuers or government can decrypt all transactions) are constitutional problem. Fourth Amendment issue in the states means you shouldn't surveil non-customers who never provided information to the issuer. Also cybersecurity nightmare as any key compromise exposes everyone. Effectively creating the same risks as CBDC.

The path forward could be to verify compliance without exposing private data. This is why privacy-preserving infrastructure isn't optional but necessary for both user rights and institutional adoption.

## The Coordination Problem: Why Protocols Can't Interoperate

**Compliance models don't compose.** At least not easily. Different protocols made different choices about who controls privacy and when compliance happens. These design decisions create compatibility barriers.

| Approach | How it Works | User Control | Effectiveness | Key Weakness |
|----------|-------------|--------------|---------------|--------------|
| **Railgun** | 1hr deposit delay blocks sanctioned addresses; optional viewing keys required by compliant counterparties | Full | Moderate | You can launder inside the pool, but compliant services (CEXs, DeFi, institutions) won't accept funds without viewing keys proving clean origin. Only works if ALL counterparties enforce. |
| **Privacy Pools** | Prove NOT from blacklist at exit | Full | Moderate (timing attacks) | Bad actors withdraw before updates |
| **zkBob** | Optional KYC + compliance history export | Full (opt-in) | Weak (gameable) | Voluntary disclosure, limits bypassable |
| **Blanksquare** | TEE + DAO retroactive reveal | None (DAO decides) | Strong (catches after exit) | Users lose control, TEE risk |
| **Cloak/Prividium** | Enterprise controls sequencer | None (enterprise decides) | Strong (real-time monitoring) | Centralized, ransom risk |
| **Aztec** | Programmable privacy circuits | User-defined | Flexible | Requires protocol-level support |

These aren't flaws but design choices. *Railgun* uses a 1-hour deposit delay to screen for sanctioned/illicit activity before funds enter the pool, then relies on voluntary viewing keys (which show internal transfers and balances) for ongoing compliance. *Privacy Pools* uses exclusion proofs to check compliance at exit. *zkBob* offers optional KYC for unlimited deposits and compliance exports. *Blanksquare, Cloak, Prividium* use involuntary reveal as deterrent but users lose control. *Aztec* lets apps implement their own compliance logic.

The challenge is these models don't easily compose. Bridging "prove you're not on a blacklist" with "share viewing keys voluntarily" or "export compliance history" is hard. Different things checked at different times with different trust assumptions. Stealth addresses don't have compliance built in at all.

That said, this might be solvable with complex cryptographic statements. Client-side zkVMs, abstractions like PODs, and other emerging tech could let us prove arbitrary compliance properties across systems (thanks Andy). PSE's [Client-Side Proving team](https://pse.dev/blog/efficient-client-side-proving-for-zkid) is working on this. Maybe the coordination problem has a technical solution but we just don't have it yet.

### Circuit Design Incompatibility

All protocols use similar primitives: [BN254](https://hackmd.io/@jpw/bn254) for Groth16, [Baby Jubjub](https://eips.ethereum.org/EIPS/eip-2494) for in-circuit ops, [Poseidon](https://eprint.iacr.org/2019/458.pdf) hashing. But **compatible curves don't solve interoperability**.

Most production protocols use Circom and Groth16 (aging tech stack). Groth16 needs trusted setup per circuit, Circom makes modifications hard. Newer systems (Plonk, Halo2, Honk) have better properties like universal setup, more flexibility, easier upgrades. My take is to work with what's deployed while planning migration paths. Standards should focus on **data formats and APIs**, not lock in specific implementations.

**Note on client-side proving:** PSE's [Client-Side Proving team](https://pse.dev/projects/client-side-proving) is tackling some of this, exploring efficient mobile proving with systems like Binius and Ligero. This work could enable more flexible cross-protocol proofs.

| Protocol | Commitment Model | Proof Statement | Circuit Approach | Proof System |
|----------|-----------------|----------------|------------------|--------------|
| **Railgun** | [UTXO-based](https://docs.railgun.org/developer-guide/wallet/private-balances) | "I can spend these UTXOs" | [54 specialized circuits](https://docs.railgun.org/wiki/learn/privacy-system/zero-knowledge-cryptography) for different transaction types | Groth16 (Circom) |
| **Privacy Pools** | [Commitment-based](https://docs.privacypools.com/layers/zk) | "My withdrawal is from approved set" | [3 main circuits](https://docs.privacypools.com/layers/zk) (hasher, membership, withdrawal) | Groth16 (Circom) |
| **zkBob** | UTXO-based | "I can spend these UTXOs" | Similar to Railgun | Groth16 (Circom) |
| **Blanksquare** | Commitment-based | "My transaction is valid" | Similar to Privacy Pools | Groth16 (Circom) |
| **Cloak/Prividium** | Account-based | "Batch of transactions is valid" | EVM-compatible circuits | Optimized ZK |
| **Aztec** | Note-based | "Transaction satisfies app constraints" | [Noir circuits](https://noir-lang.org/) | Honk (UltraPlonk) |

**Each protocol proves a different statement.** Railgun proves UTXO ownership. Privacy Pools proves membership in approved set. Aztec proves arbitrary constraints. Same primitives underneath, but you can't verify a Railgun proof in a Privacy Pools contract. Different questions about the transaction.

**What to standardize.**
1. **Data formats** - How commitments, nullifiers, metadata are represented
2. **APIs** - How wallets, relayers, apps interact with protocols
3. **Compliance attestations** - Common formats for proving compliance across proof systems

This lets protocols evolve implementations while maintaining interoperability at interfaces.

### Why Cross-Chain Movement Fails

Even for a single protocol on multiple chains, movement is broken. The infrastructure is there e.g. Railgun on Ethereum, Polygon, BSC, Arbitrum. zkBob supports multiple chains; but the **economics don't work**.

**The relayer problem:** Moving Railgun-Ethereum to Railgun-Polygon:
1. User deposits on Ethereum, gets shielded commitment
2. Relayer locks equivalent funds on Polygon
3. User proves ownership, withdraws on Polygon
4. Relayer claims deposit on Ethereum

Works technically. [Liquidity providers built it](https://github.com/Railgun-Community/liquidity-providers) but the economics collapsed:
- Capital locked on both chains
- Bridge timing creates inefficiency
- Yield doesn't cover costs
- Gas fees eat margins

**Ground zero for coordination failure.** Even when protocols share circuits and proving systems, bridging fails because no one profits running infrastructure. Solutions need economic incentives, not just technical mechanics.

## The Infrastructure Problem: Why UX is Broken

Coordination problems are hard, maybe unsolvable. But UX failures have clear technical solutions; they need funding. These improvements benefit all protocols regardless of interoperability.

### Wallet Fragmentation

Every protocol needs its own wallet. Railgun needs UTXO management. Privacy Pools needs commitment tracking. zkBob needs different key derivation. Users juggle multiple privacy identities.

An [ERC-7579](https://erc7579.com/) privacy module could handle keys, proofs, and state for all protocols. Apps install the module, users get unified privacy. A protocol-agnostic wallet like EVM wallets across chains.

This removes the biggest adoption barrier. No separate setups per protocol. Developers don't rebuild integrations. One module everywhere.

All the primitives exist. ERC-7579 defines modular wallet architecture. Circuit compilation is solved (Circom, Noir). Proof generation libraries are mature. Key management patterns are well-understood.

Engineering challenge is abstraction, not invention. Build module wrapping protocol circuits, expose clean API. Fund teams delivering production implementations.

### Viewing Key Management Chaos

Railgun supports viewing keys but UX is broken. Viewing keys let auditors see internal transfers and balances within the shielded pool. But users can't:
- See active keys
- Generate scoped keys (viewing only, time-limited)
- Rotate or revoke keys
- Track who has access

**The result** is a binary choice: Share root keys (unsafe, irrevocable) or skip viewing keys (defeats compliance).

We need wallet dashboards showing active keys with metadata (who, when, scope):
- Scoped key generation: keys limited to transactions, time ranges, balance queries.
- Key rotation tools: new keys without losing history.
- Revocation mechanisms: invalidate keys, signal to relayers.

This is pure UX work. Crypto for scoped keys exists (derive from root, include scope in circuit). Hard part is interfaces users understand.

### Revocation Without Infrastructure

Generating viewing key is cryptographic because revocation needs coordination. User revokes key but how do auditors know with on-chain records / messaging / enforcement?

Revocation infrastructure needs to work across protocols. On-chain registry where users publish revocation proofs to contracts. Off-chain indexing where relayers track revocation state. TEE attestation network where auditors run attestation in trusted environments, can't use revoked keys.

Without revocation, keys are forever so they can't recover from compromise and enterprises can't enforce access policies. Protocols must adopt standards and relayers must honor them. However, TEE infrastructure (enforceable revocation) needs trust assumptions but tech is mature (SGX, TDX, Nitro).

### Threshold Attestation Oracles

Private DeFi needs provable statements without revealing details:
- Prove creditworthiness without exact balance
- Demonstrate trading history without positions
- Verify income without amounts

Current options:
1. Share viewing keys (reveals everything)
2. Per-query ZK proofs (expensive, circuit per use case)
3. No private verification

Oracle network where attesters verify in threshold-encrypted environments could solve this. User encrypts query to N attesters ("balance > $X"). Attesters decrypt in TEEs, verify against viewing key. K/N threshold signature attests on-chain and user gets attestation without revealing details.

This could unlock private DeFi since apps verify state without compromising privacy and no per-use-case circuits. This also works with viewing keys.

The tech exists as TEEs can verify private data but threshold crypto for N/M attestation is mature. Oracle networks have been proven (Chainlink, Pyth) but challenges are around TEE trust (hardware + operator), attestation costs, and standardizing queries.

The economics are also unclear, since you likely need a fee model covering costs that are cheaper than ZK proofs. It may need bootstrap subsidies.

## Two Funding Tracks

### Track 1: Research-Based Funding (Coordination)

Open research questions. High risk, high reward. May not be solvable.

| Research Area | What's Needed | Risk Level | Type |
|---------------|---------------|-----------|------|
| **Same-protocol cross-chain** | Economic models for Railgun ETH to OP relayers (technology works, economics don't) | Low | Engineering |
| **Official protocol bridges** | Deep integrations between specific pairs (Railgun to Privacy Pools) with shared compliance formats | Medium | Engineering |
| **Universal relayer adapters** | Adapter framework that handles protocol-specific compliance requirements | Medium | Engineering + Research |
| **Auditable privacy standards** | Universal format for compliance attestations that works across protocols and serves both enterprise/retail | Medium | Research |
| **Universal proof aggregation** | System that wraps heterogeneous proofs (Railgun UTXO proofs, Privacy Pools membership proofs) into single verifiable statement | High | Research |
| **Intermediate representation layers** | Shared IR that protocols compile to, enabling cross-protocol verification (like LLVM for circuits) | High | Research |
| **Meta-protocol design** | New protocol above existing layers that provides unified interfaces, routes internally | High | Research |

**Assessment criteria for research proposals:**
- Does it preserve both privacy AND compliance guarantees across protocols?
- Does it scale beyond 2 protocols (avoids n² integration problem)?
- Is it technically feasible given current circuit designs, or does it require protocol rebuilds?
- What's the adoption path? Do protocols need to opt-in?
- **Does it standardize at the right level?** (APIs and data formats, not circuit implementations)

### Track 2: Application-Based Funding (Tooling)

Practical improvements. Lower risk, guaranteed value. Benefits all protocols regardless of coordination success.

| Tooling | What's Needed | Impact | Feasibility | Type |
|---------|---------------|--------|-------------|------|
| **ERC-7579 privacy module** | Wallet module managing keys/proofs for all protocols | High (solves user fragmentation) | High (all primitives exist) | Engineering |
| **Viewing key wallet UI** | Dashboard showing active keys, scoped generation, rotation tools | Medium (makes feature usable) | High (just UX layer) | Engineering |
| **TEE revocation network** | Infrastructure for enforceable viewing key revocation | High (enables institutional use) | Medium (requires coordination) | Engineering |
| **Threshold attestation oracles** | General-purpose infrastructure for programmable private verification | High (unlocks private DeFi) | Medium-High (expensive, trust assumptions) | Engineering |
| **ZK view key proofs** | Circuits for specific predicates without sharing keys | Highest (ideal long-term) | Medium-High (per use case) | Research + Engineering |

**Assessment criteria for tooling proposals:**
- **Protocol-agnostic:** Does it work for multiple privacy protocols, or just one?
- **Backward compatible:** Can existing protocols integrate without major changes?
- **Trust assumptions:** What new trust requirements does it introduce?
- **Economic sustainability.** Will it keep running without perpetual subsidies?
- **Adoption path:** How do you get from zero users to critical mass?
- **Standards-focused:** Does it operate at the API/data format level rather than locking in specific implementations?

## Recommendations

### Fund both tracks

**Track 1 (Research)** addresses the coordination problem (high risk but necessary). Someone might solve proof aggregation or find a clever IR. Universal relayer adapters are more practical than full protocol bridges. Auditable privacy standards could help permissionless protocols serve enterprise needs without centralization. Might be worth exploring even if success is uncertian.

**Track 2 (Tooling)** improves UX regardless of coordination outcomes (lower risk, guaranteed value). Users benefit immediately. Wallet modules and viewing key management are low-hanging fruit.

### Prioritize within tracks

**Research track priorities:**
1. Same-protocol cross-chain (low risk, works today)
2. Universal relayer adapters (medium risk, practical approach)
3. Auditable privacy standards (medium risk, serves enterprise needs)
4. Official protocol bridges (medium risk, requires coordination)
5. Universal proof aggregation (high risk, explore)
6. IR layers and meta-protocols (high risk, long-term)

**Tooling track priorities:**
1. ERC-7579 privacy module (high impact, high feasibility)
2. Viewing key wallet UI (quick win, enables other work)
3. TEE revocation network (high impact if built)
4. Threshold attestation oracles (enables private DeFi)
5. ZK view key proofs (ideal long-term, develop incrementally)

### Standards Focus

**My view on standards:** Focus on **data formats and APIs**, not implementations. This would let protocols:
- Upgrade from Circom/Groth16 without breaking compatibility
- Evolve circuits while maintaining interoperability
- Compete on performance while sharing infrastructure

What I think could make sense to standardize are commitment/nullifier formats, viewing key specs, compliance attestation structures, wallet-protocol APIs, relayer protocols.

What I'd avoid entirely are "All protocols use Groth16" (locks outdated tech), "Standardize on Circom" (prevents evolution), and "Universal circuit IR" (probably impossible, definitely high risk).

But this is just my take. Others might disagree, especially protocol teams who've invested heavily in specific stacks.

## Conclusion

**The coordination problem might be unsolvable** but the tooling problem isn't. We can fund both with research on interoperability (uncertain payoff) and infrastructure improvements (guaranteed value). Prioritize protocol-agnostic tooling that works regardless of coordination outcomes.

We can **standardize APIs and data formats**, not implementations. Let protocols evolve their cryptography while maintaining compatibility. Avoid locking the ecosystem into aging tech stacks.

**Without action, privacy bifurcates**: centralized for enterprises, fragmented for retail. EF should fund neutral infrastructure that prevents lock-in and preserves user sovereignty across the entire ecosystem.