# **Request for Proposal (RFP): Compliance Transport & Institutional Interop Layer**

## **1. Background**

Privacy protocols on Ethereum (e.g. Railgun, Privacy Pools, zkBob, Blanksquare) all address the same challenge of making privacy compliant, yet each has rebuilt the full stack for handling compliance proofs and attestations. This fragmentation has led to:

* **Repeated engineering** effort reinventing proof transport mechanisms
* **Poor composability** between privacy systems, wallets, and off-ramps
* **High integration** friction for regulated institutions
* **Limited interoperability** and shared compliance infrastructure

To enable institutional adoption and cross-protocol composability, we need a **universal transport layer** for compliance proofs and attestations that works across any privacy protocol, wallet, or verifier.

## **2. Objectives**

The goal is to design and implement a **protocol-agnostic compliance transport standard** that allows privacy systems to interoperate seamlessly with institutional frameworks.

### Core Objectives

1. **Universal Proof Transport**
* Define a standardized method to attach attestations or compliance credentials to Ethereum transactions (e.g. calldata trailers or structured metadata).
* Ensure any wallet or dApp can transport and verify compliance proofs without altering core contract logic.
2. **Protocol-Agnostic Design**
* Support multiple attestation formats (EAS, VCs, JWTs, custom proofs) through a unified interface.
* Allow each protocol to retain its internal proof system while exposing a standardized external interface.
3. **Institutional Compatibility**
* Provide standardized, interpretable proof payloads for regulated institutions.
* Maintain alignment with existing compliance and regulatory frameworks.
4. **Developer Accessibility**
* Deliver easy-to-integrate libraries and SDKs.
* Ensure minimal gas overhead and full compatibility with ERC-4337 and bundler infrastructure.

## **3. Scope of Work**

The scope includes designing and implementing a standard that:

* Defines a **universal trailer or metadata format** for proofs and attestations, including validation rules and extension mechanisms.
* Provides **reference tooling** for both on-chain and off-chain use, such as Solidity parsers, verifier interfaces, and wallet SDKs.
* Includes **integration patterns** for privacy protocols and dApps, ensuring backward compatibility.
* Covers **testing, benchmarking, and security validation**, including signature and AA/bundler compatibility.
* Develops an **adoption and governance framework** to promote and maintain the standard.

Out of scope: protocol-specific compliance layers, centralized or permissioned systems, or any approach requiring changes to Ethereum’s core protocol.

## **4. Deliverables**

* **Draft EIP or ERC Specification** defining the compliance transport format and validation process.
* **Reference Implementation:**
* Solidity libraries for parsing and verifying trailers
* SDK for attaching and verifying metadata
* Example verifier contracts for dApps and DEXs
* **Integration Demo:**
End-to-end flow demonstrating wallet → transaction → verifier → institutional interface.
* **Gas & Security Report:**
Benchmarking gas overhead, analyzing trade-offs, and summarizing security review results.
* **Adoption Partnerships:**
At least one privacy protocol and one institutional design partner integrated in a pilot.
* **Open-Source Publication:**
Code, documentation, and test suites released under a permissive license (MIT or Apache 2.0).

## **5. Success Criteria**

#### Technical Viability
* Maintains signature validity across all transaction types.
* Fully compatible with ERC-4337 and bundlers.
* Minimal gas overhead vs. baseline transactions.
* Independent security review completed.

#### Interoperability
* Works with multiple attestation formats (EAS, VCs, custom proofs).
* Demonstrated integration with two or more privacy protocols.
* Verifiable by institutional compliance systems.

#### Adoption
* Expressed integration interest from three or more privacy or compliance projects.
* One production deployment or pilot program completed.
* SDK adopted by at least one design partner.

#### Openness & Governance
* Specification and reference code open-sourced under permissive license.
* Transparent, neutral governance process for standard evolution.
* Public documentation and developer resources maintained.

## **6. Proposal Requirements**

Proposals should include:

1. **Team Profile**
* Experience with Ethereum standards (EIPs/ERCs), privacy, and compliance infrastructure.
* Track record of shipping production-grade systems.
2. **Technical Approach**
* Architecture and design of the proposed proof transport mechanism.
* Compatibility analysis with ERC-4337, EAS, and other relevant standards.
* Trade-off discussion (calldata trailers vs. metadata vs. hooks).
* Security model and threat analysis.
3. **Ecosystem Validation**
* Letters of support or commitments from privacy protocols and/or institutions.
* Assessment of integration feasibility with existing wallets/dApps.
4. **Adoption Strategy**
* Developer onboarding plan (docs, tutorials, SDKs).
* Engagement plan for privacy protocols and institutional partners.
* Metrics to track adoption and ecosystem traction.
5. **Roadmap & Timeline**
* **Phase 1:** Specification and reference implementation
* **Phase 2:** Integrations and pilot deployments
* **Phase 3:** Production hardening and community adoption
* Milestones with clear deliverables per phase.
6. **Budget & Funding Structure**
* Phase-by-phase budget breakdown.
* Milestone-based disbursement, tied to measurable outcomes (e.g. spec completion, integrations, adoption).
7. **Risks & Mitigations**
* Technical (gas costs, security, AA compatibility).
* Ecosystem (adoption barriers, competing standards).
* Regulatory (jurisdictional differences).
* Mitigation strategies for each.

## **7. Governance & Open Source Commitment**

* All code, documentation, and specifications must be open-sourced under a permissive license (MIT, Apache 2.0, or equivalent).
* Governance should be neutral, extensible, and community-driven.
* Proposal should outline a clear plan for maintaining and evolving the standard post-grant.

## **8. Funding**

Funding will follow a **milestone-based structure**, with significant payments tied to:

* Completion of specification and reference implementation.
* Verified integrations with privacy protocols and wallets.
* Pilot or production deployment demonstrating institutional interoperability.

Estimated total funding range: **[TBC]**

## **9. Open Questions for Community Input**

We welcome community feedback on:

* Which components should be standardized first (trailer format, hook ABI, registry interface)?
* What governance model best ensures neutrality and extensibility?
* How should the standard interact with account abstraction (ERC-4337)?
* Should the design natively support multiple proof formats or use an adapter model?
* What level of backward compatibility is essential for adoption?