# Request for Proposal (RFP): Attestation Registry & Trust Federation

## **1. Background**

As privacy protocols mature, attestations (KYC, proof-of-innocence, TEE proofs, zkTLS outputs, etc.) are becoming essential building blocks for compliant, interoperable systems. However, today's attestation landscape is fragmented:

* **No unified discovery mechanism** for trusted issuers across protocols
* **Inconsistent revocation infrastructure**, forcing each protocol to rebuild trust management
* **Poor cross-chain coordination**, making it difficult to propagate or verify attestations across networks
* **High integration costs** for developers who must build bespoke integrations for each issuer or protocol

A **federated attestation registry** that extends existing primitives (like EAS) can solve these issues by providing a neutral coordination layer. This will allow privacy protocols to discover trusted issuers, manage revocations, and coordinate trust policies without centralizing control or creating vendor lock-in.

## **2. Objectives**

The goal is to design and implement a **trust federation layer** that enables attestation-based interoperability across privacy protocols, chains, and institutional partners.

### Core Objectives

1. **Issuer Discovery & Trust Coordination**
* Enable protocols to discover and verify trusted attestation issuers without protocol-specific integrations.
* Support multi-issuer environments where trust tiers and policies can be customized by each protocol.
2. **Cross-Chain Attestation Propagation**
* Provide mechanisms to relay or verify attestations across chains (e.g., via bridges, Merkle proofs, or cross-chain messaging).
* Ensure attestation metadata remains available and verifiable regardless of origination chain.
3. **Decentralized Governance & Neutrality**
* Avoid single points of control by exploring federated architectures (e.g., shared root, Merkle aggregation).
* Support transparent, community-driven governance models that balance neutrality with quality assurance.
4. **Privacy Protocol Integration**
* Act as a decision layer (not execution layer). Protocols manage proofs locally while verifying issuer metadata globally.
* Provide standardized adapters so privacy protocols can plug into the registry without custom integrations.

## **3. Scope of Work**

The scope includes designing and implementing a federated registry system that:

* **Integrates with EAS** (Ethereum Attestation Service) or demonstrates clear interoperability pathways with existing attestation primitives.
* **Defines trust coordination interfaces** for issuer onboarding, attestation schemas, trust tiers, and revocation.
* **Implements cross-chain propagation mechanisms** to ensure attestations are discoverable and verifiable across multiple networks.
* **Provides protocol adapters** that allow at least 2–3 major privacy protocols to integrate seamlessly.
* **Addresses governance and sustainability**, including economic models for registry operation and issuer participation.

**Out of scope**: centralized registries, protocol-specific solutions, systems storing PII/NPI on-chain, or closed revocation mechanisms without public APIs.

## **4. Deliverables**

* **Federated Registry Architecture:**
* Smart contracts for trust coordination, issuer registration, and attestation metadata management.
* Design documentation outlining federated structure (e.g., shared root, Merkle aggregation, or multi-registry coordination).
* **EAS Compatibility & Interoperability:**
* Demonstrated integration with EAS or clear specification for interoperability with existing attestation systems.
* Cross-chain relay or verification mechanism (e.g., via bridges, oracles, or ZK proofs).
* **Issuer Onboarding & Governance Framework:**
* API for issuer registration, trust tier assignment, and metadata updates.
* Decentralized governance model (e.g. DAO, multisig, or federated) with transparent decision-making processes.
* **Attestation Schemas & Trust Tiers:**
* Typed schema definitions for common attestation types (KYC, POI, compliance, etc.).
* Trust tier system allowing protocols to define custom allowlists or risk categories.
* **Revocation Mechanism:**
* Efficient on-chain or off-chain revocation system with minimal gas costs.
* Public API for querying revocation status.
* **Protocol Adapters:**
* Reference integrations with 2–3 major privacy protocols (e.g., Railgun, Privacy Pools, Blanksquare).
* Documentation and SDKs for additional and future protocol integration.
* **Pilot Deployment:**
* At least two issuers onboarded in a testnet or pilot environment.
* Demonstrated cross-chain attestation propagation (e.g., Ethereum <--> Optimism or Arbitrum).
* **Open-Source Publication:**
* All code, specifications, and documentation released under permissive license (MIT or Apache 2.0).

## **5. Success Criteria**

**Technical Viability**

* EAS compatibility or demonstrated interoperability with existing attestation systems.
* Cross-chain attestation propagation functional and tested.
* Revocation mechanism efficient and publicly queryable.
* Independent security review completed.

**Interoperability**

* Integration with 2–3 privacy protocols demonstrated.
* Coordination with [RFP #1 (Compliance Transport Layer)](https://hackmd.io/4IDbGbilRi6eEiUyPnJm6Q) shown in design or implementation.
* Supports multiple attestation types (KYC, POI, TEE proofs, zkTLS, etc.).

**Adoption**

* Two or more issuers onboarded in pilot.
* Expressed integration interest from additional protocols or institutional partners.
* Published roadmap for DAO-based or federated governance (if applicable)

**Openness & Governance**

* All specifications and code open-sourced under permissive license.
* Transparent governance model designed to prevent surveillance or centralized control.
* Clear plan for long-term maintenance and community stewardship.

## **6. Proposal Requirements**

Proposals should include:

1. **Team Profile**
* Experience with attestation systems, EAS, privacy protocols, or cross-chain infrastructure.
* Track record of shipping decentralized governance or registry systems.
2. **Technical Approach**
* Detailed architecture for federated registry design (e.g., shared root, Merkle aggregation, multi-registry coordination).
* EAS compatibility strategy and cross-chain propagation mechanism.
* Trust tier definitions, issuer onboarding process, and revocation design.
* Security model and threat analysis (e.g. how to prevent Sybil attacks, registry capture, or surveillance risks).
3. **Ecosystem Validation**
* Letters of support or commitments from privacy protocols (e.g. Railgun, Privacy Pools, Blanksquare).
* Preliminary engagement with institutional issuers (KYC providers, compliance services, etc.).
4. **Governance & Sustainability**
* Proposed governance model (DAO, federated multisig, or hybrid).
* Economic model for sustaining registry operation and incentivizing issuer participation.
* Plan to mitigate surveillance or censorship risks.
5. **Adoption Strategy**
* Developer onboarding plan (SDKs, tutorials, documentation).
* Integration roadmap for privacy protocols and institutional partners.
* Metrics to track adoption and ecosystem traction.
6. **Roadmap & Timeline**
* **Phase 1:** Registry architecture, EAS integration, and governance design.
* **Phase 2:** Protocol adapters, issuer onboarding, and pilot deployment.
* **Phase 3:** Cross-chain propagation, production hardening, and ecosystem scaling.
* Milestones with clear deliverables per phase.
7. **Budget & Funding Structure**
* Phase-by-phase budget breakdown.
* Milestone-based disbursement tied to measurable outcomes (e.g., EAS integration, issuer onboarding, protocol adoption).
8. **Risks & Mitigations**
* Technical (cross-chain complexity, revocation efficiency, security).
* Governance (neutrality vs. quality control trade-offs, capture risks).
* Adoption (privacy protocol integration barriers, issuer incentives).
* Mitigation strategies for each.

## **7. Key Design Considerations**

The registry should act as a **decision layer, not an execution layer**. Privacy protocols manage proofs and data locally; the registry provides metadata, trust signals, and revocation status globally.

* **Federated Architecture:** Avoid single points of failure or control by exploring shared roots, Merkle aggregation, or multi-registry coordination.
* **Protocol Autonomy:** Allow each protocol to define custom trust tiers and allowlists while leveraging shared issuer discovery.
* **Cross-Chain Coordination:** Enable attestations to propagate across chains without requiring full state replication (e.g., via bridges, oracles, or ZK proofs).

> **Note:** Some privacy systems (e.g., Railgun's PPOI V2) already manage internal proof availability. The registry complements these systems by enabling **external verifiers** (bridges, dApps, institutions) to consume and validate attestations without bespoke integrations.

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

* All code, documentation, and specifications must be open-sourced under a permissive license (MIT, Apache 2.0, or equivalent).
* Governance must be transparent, neutral, and resistant to capture or surveillance.
* Proposals should outline a clear path to DAO-based or federated governance post-launch.

## **9. Funding**

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

* Completion of registry architecture and EAS integration.
* Onboarding of two or more issuers and integration with 2–3 privacy protocols.
* Demonstrated cross-chain attestation propagation.
* Pilot or production deployment

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

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

We welcome community feedback on:

* How should governance balance neutrality vs. quality control (e.g., permissionless issuer registration vs. curated allowlists)?
* What economic incentives can sustain registry operation and encourage issuer participation?
* How can the registry prevent becoming a framework for surveillance or centralized control?
* Should the registry use a shared root architecture, Merkle aggregation, or multiple federated registries?
* How should revocation be handled to minimize on-chain costs while ensuring auditability?