1. Product Overview Product Name: BlindVaults Tagline: Private execution for everyday traders. One-line summary: BlindVaults is a privacy-preserving swap layer on Fhenix that lets retail users trade without exposing their intent, balances, or pool state to bots and front-runners until execution is complete. Core idea: Primary outcome: 2. Problem Statement The exact trade size, The direction of the trade, The slippage tolerance, And often the transaction before it is finalized. Sandwich attacks, Front-running, Reserve manipulation, And toxic order flow extraction. High gas costs, Thin liquidity, Volatile tokens, Poor execution, And inconsistent user experience. 3. Why This Matters for the African Retail Market Why the market is important Smaller ticket sizes, On mobile devices, With limited access to sophisticated execution tools, And with less tolerance for invisible losses. That means a trade that loses 2% to slippage or MEV can be much more painful than the same trade for a large institution. The market opportunity Retail traders in Nigeria and across Africa, Mobile-first crypto users, Young traders using stablecoins and ETH pairs, Users who want better execution without understanding advanced DeFi mechanics. This makes BlindVaults both a product and a fairness layer. 4. Why BlindVaults Fits Fhenix encrypt swap intent, keep reserves and LP positions private, compute with encrypted values, and settle transactions without exposing sensitive trading data. This aligns with Fhenix’s privacy-first ecosystem and shows a real-world use case beyond a demo. It also fits the hackathon theme of private-by-design applications on EVM. 5. Target Users Primary users 1. Retail crypto traders in Africa small to mid-size traders mobile-first users users trading stablecoins, ETH, and common ERC-20 assets 2. Privacy-conscious everyday traders users who do not want their trades visible to bots users who want more predictable execution Secondary users 3. Liquidity providers users who want to provide liquidity without exposing their full position size 4. Crypto communities and DAOs users who want to protect treasury trades from public exposure 6. Product Goals 1. Protect trade intent Hide user swap details until execution 2. Protect pool state Reduce visibility of reserves and position size where possible 3. Deliver a simple retail UX The user should not need to understand FHE to use the product 7. Non-Goals for MVP Out of scope for MVP multi-chain routing, advanced yield farming, full cross-chain bridge support, institutional compliance dashboards, full DEX aggregation across many pools, orderbook trading, perpetuals, lending markets. The first version should prove one thing clearly: private swaps work and are useful. 8. Core Product Concept private execution layer for swaps. What users should experience They enter a swap amount. They choose the token pair. They set slippage. The app says the trade will be executed privately. The trade settles. The user sees the final output and a “protected from MEV” result. 9. MVP Feature Set Wave 2 MVP features Wallet connection Select token pair Enter amount in and minimum amount out Encrypt swap intent client-side Submit encrypted trade to Fhenix Private execution via CoFHE View final settlement result Basic trade receipt/history Wave 3 features Encrypted liquidity provisioning Withdraw liquidity privately View LP position in encrypted form Trade protection status Better UI and transaction states Wave 4 features Better slippage and protection controls Support for more token pairs Mobile-optimized UX Analytics and event tracking Failure handling and retry logic Wave 5 features Polished demo experience Documentation page Clean audit-ready code structure Production-style testnet readiness Optional public transparency mode for selected trade metadata 10. Success Metrics at least one fully working private swap flow on testnet, clear encrypted execution using Fhenix, a smooth user interface for retail users, and a strong narrative around MEV protection for small traders. Product KPIs number of private swaps executed, average settlement time, success rate of encrypted transaction flow, number of unique wallets using the app, user completion rate from connect wallet to executed trade, number of failed or reverted trades, testnet retention during repeated use. 11. System Architecture High-Level Architecture Architecture explanation 1. Frontend 2. Client-side encryption layer @cofhe/sdk to encrypt swap inputs before they are sent onchain. 3. Smart contracts 4. Fhenix CoFHE 5. Threshold network 6. Event listener / indexer 12. Smart Contract Modules A. BlindVaultRouter.sol trade submission, encrypted trade routing, execution requests, settlement state updates. B. BlindVaultPool.sol encrypted reserves, encrypted swap math, internal pool balance updates. C. BlindVaultLP.sol liquidity deposits, encrypted LP shares, withdrawals. D. PermitManager.sol access control, decrypt permissions, delegated actions. E. TradeReceiptRegistry.sol trade receipts, execution status, history logs for frontend display. 13. User Flow Primary User Flow: Private Swap Step-by-step user journey User connects wallet. User selects token pair. User enters amount and slippage limit. App encrypts swap intent in the browser. Encrypted transaction is sent to the contract. Fhenix processes the trade privately. Contract finalizes settlement. User receives a clear receipt and final output. 14. UX Requirements UX principles no technical jargon on primary screens, no crypto-native complexity in the main user journey, clear status updates, visible protection messaging, obvious success and failure states. Main screens Home / landing page Swap page Transaction pending page Success receipt page Trade history page LP page for future versions Settings page Critical UI copy “Your trade is private.” “Bots cannot see your order.” “Execution completed.” “Protected from MEV.” 15. Technical Requirements Frontend Next.js or React Tailwind CSS @cofhe/react or @cofhe/sdk Wallet connect integration Mobile responsive design Smart contracts Solidity FHE-compatible encrypted types testnet deployment modular contract design Infrastructure testnet deployment on the relevant Fhenix-supported network, event indexing for receipts, error logging, simple analytics. 16. Data Model Encrypted values swap amount in, minimum amount out, reserve values, LP share values, partial execution state. Public values transaction hash, execution status, token pair, timestamp, receipt metadata. Sensitive values never shown in plaintext user trade size, reserve balances, LP position size, pre-settlement execution details. 17. Validation Rules the user has a valid wallet connection, the encrypted swap intent is correctly formed, slippage tolerance is respected, the contract has sufficient liquidity, the encrypted computation completes successfully. A trade should fail gracefully if: liquidity is insufficient, encryption payload is invalid, the transaction is expired, the wallet signature is missing, or the computation cannot be completed. 18. WaveHack Roadmap Wave 2 — Build Objective: prove the core private swap flow. Deliverables working frontend skeleton, wallet connection, encrypted swap intent submission, one token pair supported, testnet contract deployment, basic private execution flow, simple transaction receipt. Success criteria the developer can submit a private trade, the contract processes it, the UI shows completion. Wave 3 (Marathon) — Feature Expansion Objective: make BlindVaults feel like a real product, not just a demo. Deliverables LP deposit support, private withdraw support, better state handling, improved encryption flow, trade history view, cleaner design system, stronger settlement logic. Success criteria the app can support both trader and LP actions, the product has a recognizable identity. Wave 4 — Polish and Reliability Objective: improve quality and reliability. Deliverables UI polish, loading and error states, mobile responsiveness, better slippage validation, more stable testnet interactions, basic analytics, improved documentation. Success criteria judges can use the app without confusion, the experience feels intentional and professional. Wave 5 — Showcase and Production Readiness Objective: prepare the project for stronger evaluation and future growth. Deliverables final demo polish, pitch deck, walkthrough video, technical documentation, architecture diagram, public-facing project page, post-hack roadmap, optional compliance-ready mode for future expansion. Success criteria the project looks like a protocol foundation, not a weekend hack. 19. Post-Hack Build Roadmap Phase 1: More trading pairs stablecoin pairs, ETH pairs, major ERC-20 swaps. Phase 2: Better liquidity depth private LP rewards, incentive programs, deeper reserve management. Phase 3: Mobile-first product Phase 4: Retail protection layer MEV protection score, trade safety indicators, fee transparency, better execution analytics. Phase 5: Regional growth African retail markets, creator economies, remittance-adjacent stablecoin use cases, community-driven trading pools. 20. Alignment With the Fhenix Ecosystem Alignment points uses FHE the way it is meant to be used, shows encrypted logic in a real financial use case, serves a specific market pain point, contributes to Fhenix’s privacy-first narrative, is buildable within the hackathon timeline, can be extended after the hackathon. Ecosystem relevance privacy-preserving retail trading, MEV resistance, confidential execution, and practical adoption of Fhenix. 21. Risks and Mitigation Risk 1: Over-scoping Mitigation: keep Wave 2 tightly focused on one working private swap flow. Risk 2: Technical complexity Mitigation: isolate the core swap path first, then add LP features later. Risk 3: UX confusion Mitigation: use simple language and a guided flow. Risk 4: Liquidity limitations Mitigation: start with one or two supported assets and realistic testnet liquidity assumptions. Risk 5: Demo instability Mitigation: prioritize one smooth use case over multiple half-finished ones. Team Information: Izi: Project manager and Backend developer Emmanuel: Full-Stack Developer Adam Shelby: Project Researcher