# Request for Proposal (RFP): Secure and Decentralized Frontends ## Background Despite the decentralized design of smart contracts and blockchain infrastructure, most decentralized applications (dApps) today remain dependent on centralized frontend hosting and gateways. This reliance introduces risks such as: - **Compromise of hosting providers or DNS records** - **Single points of failure** through gateways - **Censorship and jurisdictional restrictions** that undermine web3's neutrality and resilience To fully realize the promise of permissionless, censorship-resistant systems, dApp frontends must become verifiable, decentralized, and resilient to tampering. ## Objectives This RFP seeks proposals that deliver: 1. **Verifiable Retrieval** - Ensure frontend assets can be validated cryptographically at the client side. - Eliminate reliance on trusted intermediaries (gateways, CDNs, single providers). 2. **Decentralized Distribution** - Support direct peer-to-peer retrieval via technologies such as WebRTC, WebTransport, or other decentralized transport layers. - Enable fallback mechanisms without central chokepoints. 3. **Seamless User Experience** - Users should be able to access frontends securely in at least one modern browser, without neesing to installing additional extensions. - If browser integration is not immediately feasible, wallets must serve as secure verification points, with at least one working proof-of-concept (PoC) implementation. 4. **Ecosystem Adoption** - Adoption is the ultimate measure of success. Proposals must include strategies to onboard dApps, and to integrate verification into wallets or browsers. - Solutions should work toward becoming a default behavior for users interacting with web3 dApps. ## Scope of Work The scope includes, but is not limited to: - Development of libraries, tooling, and reference implementations for **frontend verification in browsers and/or wallets**. - Mechanisms for **redirecting or replacing existing gateway-based retrieval** with decentralized, verifiable equivalents. - **Developer tooling and documentation** to ease integration for dApp teams and/or browsers / wallets. - **Performance, scalability, and UX testing** to ensure feasibility for large-scale adoption. - **Case studies and partnerships** with flagship dApps and wallets to drive usage. ## Deliverables Proposals should specify clear deliverables, such as: - A functional system for **verifiable, decentralized frontend retrieval** (PoC + production readiness). - Wallet integration demonstrating frontend verification (e.g., integration into Kohaku or another wallet). - At least one major dApp and multiple less major dApps live with verified frontends. - Open-source and permissive code, specifications, and documentation. - A roadmap for broader ecosystem adoption. ## Success Criteria - **Security:** Users can cryptographically verify they are loading the intended frontend, mitigating risks from DNS, hosting, or gateway compromise. - **Usability:** Access does not depend on extensions; flows must be native or wallet-integrated. - **Adoption:** Demonstrated usage by wallets and multiple major dApps. - **Openness:** All results must be open-source and designed as public goods. ## Proposal Requirements Responses should include: 1. **Team Profile** - Experience with decentralized protocols, browser technologies, cryptography, and frontend infrastructure. 2. **Technical Approach** - Architecture, protocols, and validation mechanisms. - Compatibility with existing standards. 3. **Adoption Plan** - Strategy for onboarding wallets and dApps. - Metrics for measuring adoption. 4. **Roadmap and Timeline** - Clear milestones for development, adoption, and ecosystem integration. 5. **Budget** - Breakdown by phases (development, adoption, ongoing maintenance). - Structure funding so that the majority is released upon demonstrated adoption milestones. 6. **Risks and Mitigations** - Technical, ecosystem, and adoption risks. 7. **Open Source Commitment** - License and public availability of code and specifications. ## Funding Grant size and disbursement will depend on the proposal, but should follow a milestone-based structure, with significant funding tied to **adoption and integration outcomes**.