Blind Vaults

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:

Most retail traders lose value not because they trade badly, but because their trades are visible before execution. BlindVaults uses FHE-based confidential computation to hide swap intent and pool state, so bots cannot sandwich, copy, or manipulate trades before they settle.

Primary outcome:

A retail-friendly private swap experience on Fhenix that protects small traders, especially in emerging markets where every dollar matters.

2. Problem Statement

Retail crypto users face a fairness problem on public blockchains.

When a user submits a swap on a transparent DEX, the market can see:

• The exact trade size,


• The direction of the trade,


• The slippage tolerance,



• And often the transaction before it is finalized.
  
  This creates room for MEV bots and opportunistic traders to exploit the transaction through:




• Sandwich attacks,




• Front-running,




• Reserve manipulation,




• And toxic order flow extraction.
  
  For retail users, especially in African markets where trade sizes are often small, these losses are felt more sharply. Many users already struggle with:




• High gas costs,




• Thin liquidity,




• Volatile tokens,




• Poor execution,




• And inconsistent user experience.
  
  BlindVaults exists to solve this exact pain point.

3. Why This Matters for the African Retail Market

BlindVaults is not being built as a generic “privacy protocol.” It is being built for the everyday trader.

Why the market is important

Retail users in Africa often trade:

• 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

BlindVaults is positioned for:

• 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

BlindVaults is a natural fit for Fhenix because Fhenix is built for confidential computation on EVM chains.

BlindVaults uses Fhenix to:

• 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

BlindVaults should do three things well:

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

To keep the build realistic for Wave 2 and future waves, BlindVaults will not try to solve everything at once.

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

BlindVaults is a private execution layer for swaps.

Instead of users broadcasting their trade publicly, they submit an encrypted swap intent. The contract and Fhenix compute the trade privately and reveal only the final execution result.

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

BlindVaults will be considered successful if it demonstrates:

• 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

The frontend is the retail user interface. It should be simple, mobile-friendly, and easy to understand. The user never needs to understand the cryptography.

2. Client-side encryption layer

The frontend uses @cofhe/sdk to encrypt swap inputs before they are sent onchain.

3. Smart contracts

BlindVaults contracts store and process encrypted swap intent and encrypted reserve logic.

4. Fhenix CoFHE

Fhenix performs confidential computation over encrypted values.

5. Threshold network

When decryption is required, it happens through the Fhenix threshold model, with permissions and controlled reveal.

6. Event listener / indexer

A lightweight indexer records trade status and settlement events for the user interface.

12. Smart Contract Modules

To keep the project modular and understandable, the build should be split into these components:

A. BlindVaultRouter.sol

Handles:

• trade submission,


• encrypted trade routing,


• execution requests,


• settlement state updates.

B. BlindVaultPool.sol

Handles:

• encrypted reserves,


• encrypted swap math,


• internal pool balance updates.

C. BlindVaultLP.sol

Handles:

• liquidity deposits,


• encrypted LP shares,


• withdrawals.

D. PermitManager.sol

Handles:

• access control,


• decrypt permissions,


• delegated actions.

E. TradeReceiptRegistry.sol

Handles:

• trade receipts,


• execution status,


• history logs for frontend display.

13. User Flow

Primary User Flow: Private Swap

Step-by-step user journey

1. User connects wallet.


2. User selects token pair.


3. User enters amount and slippage limit.


4. App encrypts swap intent in the browser.


5. Encrypted transaction is sent to the contract.


6. Fhenix processes the trade privately.


7. Contract finalizes settlement.


8. User receives a clear receipt and final output.

14. UX Requirements

The product must be simple enough for a retail user.

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

1. Home / landing page


2. Swap page


3. Transaction pending page


4. Success receipt page


5. Trade history page


6. LP page for future versions


7. Settings page

Critical UI copy

The app should use language like:

• “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

A trade should only execute if:

• 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

This roadmap is aligned to the Akindo buildathon rhythm shown in your screenshot.

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

After the hackathon, BlindVaults can grow into a broader private execution product.

Phase 1: More trading pairs

Expand beyond one pair to:

• stablecoin pairs,


• ETH pairs,


• major ERC-20 swaps.

Phase 2: Better liquidity depth

Add:

• private LP rewards,


• incentive programs,


• deeper reserve management.

Phase 3: Mobile-first product

Build a simpler mobile interface for everyday traders.

Phase 4: Retail protection layer

Introduce:

• MEV protection score,


• trade safety indicators,


• fee transparency,


• better execution analytics.

Phase 5: Regional growth

Focus on:

• African retail markets,


• creator economies,


• remittance-adjacent stablecoin use cases,


• community-driven trading pools.

20. Alignment With the Fhenix Ecosystem

BlindVaults aligns well with Fhenix because it demonstrates the actual power of confidential computation.

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

BlindVaults is not just a swap app. It becomes a case study for:

• privacy-preserving retail trading,


• MEV resistance,


• confidential execution,


• and practical adoption of Fhenix.

21. Risks and Mitigation

Risk 1: Over-scoping

The biggest risk is trying to build too much at once.

Mitigation: keep Wave 2 tightly focused on one working private swap flow.

Risk 2: Technical complexity

FHE is hard and can slow development.

Mitigation: isolate the core swap path first, then add LP features later.

Risk 3: UX confusion

Retail users may not understand privacy mechanics.

Mitigation: use simple language and a guided flow.

Risk 4: Liquidity limitations

A private pool is only useful if it can execute trades.

Mitigation: start with one or two supported assets and realistic testnet liquidity assumptions.

Risk 5: Demo instability

Hackathon demos fail when too many features are squeezed in.

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