EconWall

EconWall: The Web3-Native Cloudflare A decentralized economic firewall that replaces fragile IP blocking with Surge Pricing—making DDoS attacks mathematically unaffordable ($1,000+ cost) while legitimate users browse for pennies.

Project Description Modern web security is broken. We rely on centralized gatekeepers like Cloudflare to protect us. While effective, they introduce critical flaws: Censorship (they can de-platform anyone), Cost (enterprise protection starts at $5k/mo), and Fragility (attackers with botnets simply rotate IPs to bypass blocks). It's a game of Whac-A-Mole where the defender always loses.

EconWall changes the game. Instead of blocking IPs, we block economic inefficiency.

We have built a Token-Gated Browser where every request is gated by a micro-payment on Unichain. For a normal user, this cost is negligible (~$0.01/session). But for an attacker sending millions of requests, our custom Uniswap V4 Hook detects the surge and exponentially raises the fee.

How It Works: The "Economic Firewall" ENS Gateway & Requests Blocking: The Gateway (gateway.econwall.eth) acts as the absolute gatekeeper. It is an Offchain Resolver that sits between the user and the real server.

Blocking: Before signing any data, the Gateway checks the user's Unichain wallet balance. If they hold 0 EWT, the browser agent automatically attempts to swap ETH for EWT. If the swap fails (e.g., no ETH) after retries, the user is kicked out. Zero-Gas Resolution: We use CCIP-Read (EIP-3668). The resolution happens off-chain via an HTTP request to our Gateway, which signs the response. This means legitimate users pay zero gas to resolve the DNS, keeping the experience instant and free. Rolling AES-256 Encryption: To prevent "Replay Attacks" (where a hacker captures a valid signed URL and reuses it), every session is unique.

Dynamic IVs: We use AES-256-CBC with a randomly generated Initialization Vector (IV) for every single request. Session Exclusive: The server rotates encryption keys periodically. Even if an attacker scrapes a URL, it becomes garbage data within minutes. The Agentic Wallet (Background Economy): Users don't sign transactions manually. Our embedded "Agent Wallet" runs in the background, automatically signing micro-swaps (ETH -> EWT) to keep the session alive.

"Three Strike" Rule (Actually 5): The Agent monitors the swap status on-chain. If a user's wallet runs out of funds and swaps fail 5 times in a row, the session is hard-terminated. The proxy cuts the connection, and the user is kicked out. Uniswap V4 Surge Hooks: Our core logic lives in SurgeHook.sol This custom hook intercepts every swap and strictly enforces the pricing slabs based on the rolling 1-hour swap volume.

The Pricing Slabs: 0 - 60 Swaps: 0.01% Fee (Standard Browsing) 60 - 100 Swaps: 5.00% Fee (High Traffic) 100 - 150 Swaps: 15.00% Fee (Potential Spam) 150+ Swaps: 25.00% Fee (DDoS / Max Surge)

The Impact: Normal Users: Even with prolonged browsing, the cost increases by only a few pennies. Hackers: The cost increases exponentially in an uncapped way. A distributed attack attempting to sustain high throughput will see costs skyrocket to $1,000+ per minute, burning their treasury instantly. We don't need to know who they are; we just make it too expensive for them to exist.

Why Unichain? EconWall requires high-frequency, low-latency execution for its agentic loops. Unichain's performance allows our background agent to process transaction batches seamlessly without interrupting the user experience.

EconWall is not just a proxy. It is the first security layer that uses DeFi primitives to solve a cybersecurity problem.

1. System Architecture Overview EconWall is a distributed security protocol built on Unichain Sepolia. It functions as a "decentralized Cloudflare," replacing traditional IP-based firewalls with a crypto-economic barrier.

The "Failure Flow" Design Unlike traditional firewalls that block malicious traffic, EconWall taxes it.

Request: User attempts to fetch a resource via the Proxy. Check: Proxy verifies the user's on-chain "Session Credibility." Surge: If traffic is high, the cost to maintain credibility spikes exponentially. Failure: If the user cannot pay the surge fee (insufficient funds), the request fails at the cryptographic level (Gateway refuses to sign). 2. Core Technical Components A. The "Browser-in-a-Browser" Agent (Frontend) We built a custom browsing environment inside Next.js (app/page.tsx?mode=browser) that creates a sandboxed runtime.

Technology: React + Privy + viem Implementation: Invisible Wallet: Uses Privy to provision an embedded wallet for every user. Keys are managed via MPC (Multi-Party Computation), so users never see a seed phrase. Agent Loop: A background interaction listener ( lib/browse-session.ts ) tracks every click. Batching: Instead of asking the user to sign for every click, the Agent batches interactions. Every 10 clicks, it triggers a swap() transaction.

Auto-Swap Logic: If the Agent detects the user has 0 EWT tokens but holds ETH, it automatically attempts a swap before the user gets blocked.

The "5-Strike" Rule: If the auto-swap fails 5 times consecutively (e.g., wallet empty, network error), the Agent strictly terminates the session and kicks the user back to the portal page. B. The Economic Firewall: Uniswap V4 Surge Hooks.

The core defense mechanism is a custom Uniswap V4 Hook (contracts/SurgeHook.sol) that dynamically adjusts swap fees based on volume.

Technology: Solidity + Uniswap V4 Core The "Rolling Window" Optimization: Storing every swap timestamp on-chain is prohibitively expensive (gas costs). Solution: We implemented an O(1) Rolling Window algorithm. We track global volume in "buckets" (Global Tiers). The hook does not need a Chainlink Oracle. It calculates surcharges natively using block timestamps. The Fee Slabs (Hardcoded in Solidity): Tier 0 (0-60 swaps/hr): 100 (0.01%) - Standard browsing. Tier 1 (60-100 swaps/hr): 5000 (5.00%) - High traffic. Tier 2 (100-150 swaps/hr): 15000 (15.00%) - Spam suspected. Tier 3 (150+ swaps/hr): 25000 (25.00%) - MAX SURGE. Impact: A hacker attempting a DDoS attack (sending 1000s of requests) hits Tier 3 instanly.

Their cost per minute escalates from pennies to >$1,000. C. The Gatekeeper: ENS + CCIP-Read (EIP-3668) We replaced standard DNS resolution with a cryptographic handshake.

Technology: ENS + Offchain Resolver (Go/Typescript Gateway) The "Hack": Standard ENS directs domain.eth to an Ethereum address. We deployed a custom Resolver that reverts with OffchainLookup. This forces the client (browser) to query our HTTP Gateway (gateway.econwall.eth).

The Handshake Protocol: Challenge: Client requests resolution for app.econwall.eth. Verification: Gateway checks the sender address on Unichain. balanceOf(sender, EWT) > 0?

Rejection: If balance is 0, Gateway returns 403. Client cannot proceed. Signing: If valid, Gateway signs the Real Server URL with its private key. Zero Gas: Because this happens via eth_call, it costs the user 0 gas.

D. Rolling AES-256 Encryption To prevent "Replay Attacks" (where an attacker intercepts a valid signed URL and reuses it), we implemented a rolling encryption scheme.

Technology: Node.js crypto (AES-256-CBC) Mechanism: Dynamic IVs: Every single request generates a unique 16-byte Initialization Vector (IV). The Gateway encrypts the Real URL: AES(Real_URL, Key, Random_IV). The browser decrypts it locally: Dec(Ciphertext, Key, IV).

Outcome: Even if two users access google.com at the same second, their encrypted payloads are completely different bytes. An attacker cannot "replay" a captured packet.

1. Deployment & Sequence

2. Smart Contract Deployment (Unichain Sepolia) Deploy Tokens: EWT (ERC-20) is deployed. Deploy Pool: A Uniswap V4 Pool is initialized for ETH / EWT. Mine Hook Address: The SurgeHook address is mined using HookMiner to ensure it starts with specific flags (allowing beforeSwap and afterSwap callbacks). Attach Hook: The Hook is attached to the Pool.

3. Gateway Spinning The Gateway API (/api/gateway) is spun up. It holds the Signer Private Key and the AES Encryption Key. It begins listening for CCIP-Read requests.

4. Agent Activation User connects wallet on Frontend. The Browser Agent performs an initial health check. If successful, the "Portal" unlocks, and the secure browsing session begins.