STRKVeil
Private DEX Swaps
About
The problem it solves ## The Core Problem: MEV Attacks When trading on DEXs, every transaction is visible in the mempool before execution. MEV bots exploit this by: - **Front-running**: Executing their trades before yours - **Sandwich attacks**: Placing trades before AND after yours **Result**: Users lose 0.1-5%+ of trade value, get worse prices, and experience failed transactions. ## What Our Solution Enables ### 1. Private Trading Large traders can execute significant trades without revealing intentions. Trade details are hidden until execution, preventing MEV bots from front-running. **Example**: Whale swapping 10,000 ETH → USDC gets fair execution without price manipulation. ### 2. Fair Price Execution Regular users get market prices without bot interference. No price manipulation means better execution and more tokens received. **Example**: Swapping 1 ETH expecting 3,000 USDC - you get closer to 3,000 instead of 2,950 after MEV extraction. ### 3. Protection for High-Value Trades Large trades execute safely without being prime targets for MEV extraction. Reduced risk of failed transactions and better execution confidence. **Example**: DeFi protocol rebalancing 50,000 ETH → USDC without MEV losses. ### 4. Arbitrage Protection Arbitrage opportunities remain hidden. Bots can't copy your strategy, allowing you to capture opportunities without competition. **Example**: Spotting price difference between DEXs - your trade stays private, you capture the opportunity. ### 5. Strategic Trading Complex trading strategies remain hidden. Bots can't reverse-engineer your approach, enabling better execution of multi-step plans. ## How It Makes Tasks Easier ### For Regular Users - **Before**: Worry about MEV bots, accept worse prices, unexpected slippage - **After**: Trade with confidence, better prices, predictable outcomes ### For DeFi Protocols - **Before**: Large trades expensive due to MEV, need to split trades, complex workarounds - **After**: Execute large trades efficiently, simpler logic, lower costs ### For Traders - **Before**: Arbitrage gets front-run, strategies copied, need expensive private mempools - **After**: Arbitrage stays private, strategies hidden, more flexibility ## Safety Improvements 1. **Transaction Security**: No front-running, sandwich attacks, or back-running 2. **Financial Safety**: Better prices, reduced slippage, lower costs, predictable outcomes 3. **Privacy Safety**: Trade anonymity, strategy protection, position hiding ## Real-World Use Cases - **Institutional Trading**: Execute large trades without revealing positions - **DeFi Protocol Operations**: Rebalance portfolios without MEV extraction - **Arbitrage Trading**: Capture opportunities without bot competition - **Personal Trading**: Trade with confidence and fair prices - **High-Frequency Trading**: Execute many trades without front-running
How it's made
Challenges we ran into Development Challenges Challenge 1: Understanding ZK Proofs vs Encryption - The Problem: We initially thought ZK proofs could "encrypt" trade parameters and the contract could "decrypt" them. - What Failed: Attempted XOR encryption with public keys, stored decryption keys in contract storage. - The Solution: Learned that ZK proofs prove knowledge without revealing it. They don't hide data that needs to be acted upon. Moved to off-chain storage for trade parameters, using ZK proofs only for authorization. - Key Learning: ZK proofs are for proving knowledge, not for hiding data that needs to be used. Challenge 2: The Mempool Visibility Problem - The Problem: Even with ZK proofs, if trade parameters were included anywhere in the transaction, MEV bots could see them. What Failed: - Public outputs in circuit (visible in proof) - Private inputs only (contract couldn't execute) - Calldata parameters (always public) The Solution: Implemented off-chain oracle pattern - store params off-chain, submit only `intent_id`, contract fetches during execution. Key Learning: The timing of when data becomes known is crucial. Off-chain storage solves the timing problem. Challenge 3: Circom Syntax Errors The Problem: Multiple syntax errors prevented compilation - `signal private input` (invalid), `!==` operator (not supported), missing includes. The Solution: Changed to `signal input` (private by default), used `LessThan` component, added proper Circomlib includes. Key Learning: Circom has specific syntax rules. Inputs are private by default unless declared public. Challenge 4: MEV Bot Copying Prevention The Problem: What prevents MEV bots from copying the exact transaction and submitting it themselves? The Solution: Implemented caller verification - signed data includes user address, contract checks `caller == user`, MEV bot's address doesn't match, transaction fails. Key Learning: Always bind transactions to specific users. Signature verification + caller check prevents copying attacks.