Izi

Posted on Apr 20

Blind Vaults

#blockchain #privacy #showdev #web3

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

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

Home / landing page
Swap page
Transaction pending page
Success receipt page
Trade history page
LP page for future versions
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.