# Privacy Ideas – Request for Proposals (RFPs)

## Overview

Solutions to privacy work, but they're monolithic. Railgun, Privacy Pools, zkBob, and Blanksquare all solve the same regulatory problem "how to make privacy compliant", yet each rebuilt the entire stack even though they share core components (e.g. shielded pools, relayers, proofs, and attestations). This has fragmented liquidity, reduced anonymity sets, and made it difficult for developers or institutions to integrate privacy-preserving systems.

These RFPs aims to fund **open and composable infrastructure** that standardizes the interfaces between privacy, compliance, and coordination layers. The goal is not to prescribe a single architecture but to **enable creative, interoperable modules** that protocols and wallets can adopt independently.

1. **Modularity**: Each component should be independently useful but compatible with others.
2. **Interoperability**: Shared standards should lower integration costs and reduce duplication.
3. **Pragmatism**: Deliver practical reference implementations that can be deployed in prod.

> Note: See (ICYI) [Modular Privacy Infrastructure (HackMD)](https://hackmd.io/eW7Ef8-DRmyzIsxed1o3-A), which first outlined the separation between shared infrastructure and differentiated compliance modules.

## RFP #1: Compliance Transport & Institutional Interop Layer

### Intent
Develop a universal way to attach attestations or compliance credentials to Ethereum transactions (e.g. via calldata trailers or structured metadata), so that any wallet or dApp can transport and verify compliance proofs without changing its core contract logic.

### Motivation
Every privacy or compliance protocol currently reinvents how proofs “travel” through transactions. A shared transport layer would let any attestation format plug into any protocol, improving composability between privacy systems, wallets, and off-ramps. This also opens the door for regulated institutions to read standardized proof payloads rather than bespoke integrations.

### Ecosystem Validation
- [Pattern: Atomic DvP via ERC-7573](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-dvp-erc7573.md)
- [Pattern: TEE–ZK Settlement](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-tee-zk-settlement.md)
- **Validated by**: Privacy Pools, Keyring Network

> "Institutions won’t adopt privacy systems they can’t interpret. A universal trailer lets them verify attestations without changing their infrastructure."

### Example Deliverables
- Draft EIP defining a trailer or metadata standard for proofs and attestations
- Solidity parser lib and wallet SDK for attaching/ verifying trailer data
- Example verifier contracts for dApps or DEXs
- Integration demo with regulated or semi-regulated design partner

### Success Signals
- End-to-end demo (wallet --> transaction --> verifier)
- Maintains signature validity and AA/bundler compatibility
- Minimal gas overhead (measured and documentated)
- Expressed adoption interest from privacy or compliance projects

### Open Questions
- Which parts are comparatively low-risk to standardize? (trailer format, hook ABI, registry interface)
- What governance model ensures the standard remains neutral and extensible?
- How does this interact with existing account abstraction standards (ERC-4337)?

## RFP #2: Attestation Registry & Trust Federation

### Intent
Build a trust federation layer on top of EAS that enables privacy protocols to discover trusted issuers, manage cross-chain attestation propagation, and coordinate trust policies across protocols.

### Motivation
As attestations proliferate (KYC, POI, TEE proofs, zkTLS, etc.), developers need reliable discovery and revocation infrastructure. A neutral, multi-issuer registry lowers integration cost while letting issuers retain autonomy and governance.

### Ecosystem Validation
- [Pattern: Crypto-Registry Bridge (eWpG–EAS)](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-crypto-registry-bridge-eWpG-eas.md)
- [HackMD: Modular Privacy Infrastructure](https://hackmd.io/eW7Ef8-DRmyzIsxed1o3-A)
- **Validated by**: Privacy Pools (building hybrid registry for Veil Q4 2025), Railgun (PPOI V2 needs outward API), Blanksquare (dual-mode compliance)

### Key Design Considerations
The registry should serve as a decision layer rather than an execution layer. Protocols can manage proofs locally while verifying metadata globally. A single, centralized registry creates governance and censorship risks, while multiple uncoordinated ones lead to fragmentation.

We’re looking for proposals that explore **federated, EAS-compatible registries** connected through a shared root or Merkle aggregation, with creative approaches to governance and interoperability.

> Note: Some privacy systems (e.g. PPOI V2) already manage internal proof availability, the Trailer Layer enables external systems, such as bridges or cross-domain verifiers, to consume and validate proofs without bespoke integrations.

### Example Deliverables
- Trust coordination contracts that integrate with EAS
- Issuer onboarding API and governance framework
- Typed attestation schema and trust tier definitions
- Revocation mechanism with minimal on-chain footprint
- Protocol adapters for 2-3 major privacy protocols
- Trust tier definitions and allowlsted interfaces

### Success Signals
- Two or more issuers onboarded
- Demonstrated interoperability with the Trailer Layer (RFP #1)
- Published roadmap for open or DAO-based governance
- Propagation of same-protocol cross-chain attestations implemented and working

### Open Questions
- How should governance balance neutrality vs. quality control?
- What economic incentives sustain registry operation and issuer participation?
- How do we ensure the registry doesn’t become a framework for surveillance or control?

## Wishlist #1: Privacy Disclosure Framework

### Intent
Standardize how users, auditors, or regulators can request and verify **scoped visibility** into private transaction data through e.g. view keys, attestations, or selective-proof exports.

### Motivation
Privacy protocols like Railgun, Blanksquare, and Privacy Pools each have different disclosure systems. A unified disclosure interface would simplify auditor workflows, allow compliant users to prove legitimacy, and reduce the burden on wallet developers.

### Ecosystem Validation
- [Pattern: Regulatory Disclosure (Keys–Proofs)](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-regulatory-disclosure-keys-proofs.md)
- [HackMD: Modular Privacy Infrastructure](https://hackmd.io/eW7Ef8-DRmyzIsxed1o3-A)
- **Validated by**: Blanksquare (viewing keys), Railgun (cross-protocol disclosure needs)

### Example Deliverables
- JSON schema for disclosure requests and responses
- Dashboard or SDK for scoped disclosures (time-limited, attribute-specific)
- Protocol adapters translating unique viewing/attestation exports into shared format
- ZK circuits for verifying limited proofs without full reveals
- Auditor toolkit for consuming standardized data
- Design patterns for user consent and scoped selection

### Success Signals
- Demonstrated user-to-auditor disclosure flow across at least two major protocols
- Standard schema adopted by a privacy wallet or compliance partner
- Minimal leakage verified through independent review
- Clear documentation and examples of protocol adapter usage (templates, limitations, etc)

### Open Questions
- How does this operatie within existing regulatory frameworks? (e.g. GDPR, AML)

## Wishlist #2: Relayer & Cross-Protocol Liquidity Layer

### Intent
Develop an open coordination and incentive layer for privacy-preserving relayers that bridge assets and proofs across protocols and chains without relaying on a centralized intermediary.

### Motivation
Because liquidity in privacy protocols remains siloed, users risk linkability when moving between them (i.e. shield --> unshield --> bridge --> shield). A shared relayer coordination can expand anonymity sets and enable trust-minimized liquidity movement without exposing user identities.

While practical semi-custodial or federated designs are acceptable, proposals that explore or enable verifiable, trustless settlement mechanisms (e.g. zk-SPV, TEE attestations or optimistic verification) are strongly encouraged.

### Ecosystem Validation
- [Pattern: Atomic DvP via ERC-7573](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-dvp-erc7573.md)
- [Pattern: TEE–ZK Settlement](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-tee-zk-settlement.md)
- **Validated by**: 5+ privacy protocols confirmed this is needed

### Example Deliverables
- Coordination or discovery protocol for privacy-preserving relayers (P2P, intent-based, or hybrid)
- Prototype demonstrating cross-protocol liquidity transfer between at least two privacy systems
- Show how relayers manage liquidity and inventory risk
- Toolkit or SDK for testing coordination, matching, and incentive models
- Integration with an intent-based bridge or settlement network
- Atomic settlement without intermedaries (optional; may not be applicable)

> Note: Deliverable may range from PoC to reference integration partner or production-ready implementation.

### Success Signals
- Demonstrate liquidity coordination between multiple privacy systems
- No centralized custody or trusted intermediary (or a path to minimize it)
- Future use of the Compliance Transport (RFP #1) and Registry (RFP #2) layers
- Open-source SDK adopted, forked or extended by other teams

### Open Questions
- How do relayers coordinate or discover cross-protocol liquidity without exposing user identities?
- How can relayers manage economic and inventory risk (e.g. through incentives, attestations or registries) without compromising privacy?
- How can this sytem integrate with existing intent or settlement networks?

## TBC: Confidential Analytics Framework (Unconfirmed)

> Note: This RFP is harder because it potentially requires protocol buy-in. This may get killed.

### Intent
Develop a privacy-preserving analytics stack that protocols can optionally deploy to compute and expose aggregate or integrity metrics without leaking user-level data.

### Motivation
Regulators, DAOs and privacy protocols often need visibility into system-level behaviour (e.g. compliance participation, liquidity concentration, etc) without exposing individual user activity.

This RFP seeks to fund an open analytics framework that protocols can deploy independently or connect to existing analytics platforms through adapters. This ensures that privacy-preserving analytics remain flexible and governed by the protocols themselves.

### Ecosystem Validation
- [Pattern: TEE–ZK Settlement](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-tee-zk-settlement.md)
- [HackMD: Modular Privacy Infrastructure](https://hackmd.io/eW7Ef8-DRmyzIsxed1o3-A)

### Example Deliverables
- Open-source framework for secure aggregate computation
- Adapters that allows protocols to connect their private data pipelines to analytics platforms (e.g. Dune Analytics) or to run their own analytics stack
- Deployment tooling and documentation for self-hosted operation
- Defined privacy parameters and security model (e.g. DP epsilon, MPC or TEE)
- APIs for auditors or DAOs to query without raw data access

### Success Signals
- Integration with at least two privacy protocols
- Quantifiable privacy guarantees
- Produce analytics while preserving confidentiality
- Interoperability with other privacy layers (RFP #1 and RFP #2)
- Protocols can enlist/exit or self-host any time

## Evaluation Framework

TBC

## Vision

This program aims to build a coherent modular privacy stack:
- **Trailer Layer** moves proofs
- **Registry Layer** authenticates them
- **Disclosure Layer** provides visibility
- **Relayer Layer** moves liquidity

All RFPs address ecosystem fragmentation abd together they form a foundation for privacy that is **open, compliant and composable**.