Important: This document is a work in progress and represents an early-stage architectural proposal. It defines intended system boundaries & design principles, but does not specify finalised implementations or security guarantees. Please note that Etherveil is a tentative name. The purpose of this post is to gather community feedback, so please share your feedback!
Vision
Etherveil is a Firefox/Gecko-based browser built on the Tor Browser’s patch set, with Kohaku embedded as a native wallet engine. The core premise is simple: privacy should be a property of the runtime, not something users configure.
Most privacy tools put the burden on the user, i.e. install this extension, route through this VPN, remember to use your shielded address etc., you name it. Etherveil treats that as a design failure. The browser enforces privacy-by-default across three layers: network (IP & traffic metadata), execution (browser fingerprint surfaces), and on-chain (addresses, transaction origin, balances). A user should be able to open the browser, navigate to some Ethereum-supporting site, and transact without generating stable, linkable distinguishable signals beyond their assigned anonymity class (and without requiring the user to understand the underlying mechanisms). Etherveil replaces probabilistic privacy mechanisms with deterministic constraint enforcement over all observable execution surfaces.
System Invariant
Invariant: all observable browser APIs must resolve into a finite set of equivalence classes shared across users within the same Fingerprint Profile class.
In simple words: Everyone using the same privacy profile looks exactly the same to websites, because the browser forces all observable behaviour into a small number of standardised patterns.
Architecture
┌────────────────────────────────────────────────────┐
│ Etherveil Browser Shell (Firefox/Tor Fork) │
├───────────────────────────┬────────────────────────┤
│ Execution & Fingerprint │ Kohaku Engine │
│ Normalisation Layer │ (Wallet + Tx) │
│ (Tor Browser Base) │ │
├───────────────────────────┴────────────────────────┤
│ Network Privacy & Verification Layer │
│ Tor/Optional Mixnet, Helios Light Client │
│ ERC-4337 Bundler Relay │
└────────────────────────────────────────────────────┘
Fingerprint Normalisation Layer
The Tor Browser already solves most of the hard fingerprinting problems; we’re extending it, not reinventing it. The main addition is what we call a Fingerprint Profile: a fixed, precomputed equivalence class over browser observables, constructed as a constraint-satisfying tuple over correlated browser signals derived from empirical distributions, assigned per browsing context and immutable for the lifetime of a session. This ensures cross-field consistency (e.g. timezone-locale-language coherence) and prevents independent attribute spoofing.
The key design decision is that this is not per-user configuration or runtime randomisation. Randomisation is actually counterproductive: if your canvas noise seed changes between page loads, that transition is a fingerprint. Instead, each profile is a consistent snapshot derived offline from real-world distributions, but not sampled at runtime, chosen to maximise the size of the anonymity set it belongs to. If a site breaks under an assigned profile, the entire browsing context restarts under a different compatible class. There is no mid-session mutation.
Surfaces normalised at Gecko/SpiderMonkey level via deterministic API interception and rewriting (not content scripts, which are detectable):
navigator.*: UA, platform, hardware concurrency, device memoryIntl/Date: timezone, locale, language negotiation headers- Canvas/WebGL: deterministic per-profile outputs; vendor and renderer strings aligned to class distribution
screen.*,devicePixelRatio- WebRTC: ICE candidates suppressed or standardised
- High-entropy APIs (audio, fonts, performance timing): quantised across profile class
All high-entropy APIs are either quantised, unified, or mapped into profile-bounded equivalence classes.
Storage & Interaction Isolation
Storage (IndexedDB, localStorage, cookies, cache) is partitioned per origin and profile with no cross-profile leakage. Beyond storage, interaction signals - scroll timing, pointer movement, keystroke cadence - are smoothed and quantised within bounded stochastic models. The goal is to reduce behavioural entropy enough to defeat biometric re-identification without making the browser feel broken to use. The usability-entropy tradeoff boundary is a core open design parameter of the system.
Kohaku Wallet Engine
The wallet is a native browser subsystem, not an extension. The browser exposes a single transaction API to dApps and deliberately does not surface whether a given transaction is executing privately or publicly. That distinction is an implementation detail of the engine, not something dApps need to know.
dApp -> Wallet API -> Kohaku Engine -> Privacy Relay -> Chain
| Component | Role |
|---|---|
tornado-cash |
Default shielded transaction layer |
provider |
Unified RPC (Helios/external nodes/local client) |
pq-account |
Post-quantum ERC-4337 default account type |
All new accounts are pq-account smart accounts by default. Transactions route through Tornado Cash (or more generally, an abstract zk shielding layer) unless the user explicitly opts into a public flow. UserOperations are submitted via Tor-routed ERC-4337 bundlers, so the user’s IP is never associated with a transaction in the public mempool.
Network Privacy Layer
The network stack is inherited from Tor Browser and extended:
- Tor (default): per-origin circuit isolation; all traffic and DNS fully routed
- Mixnet (optional): stronger metadata resistance against timing correlation attacks, at the cost of latency; whether this should be opt-in or default is deferred
- Helios light client: local Ethereum state verification via sync committee proofs, eliminating reliance on centralised RPC providers; ENS resolution goes through Helios only
- Traffic shaping: deterministic latency padding and request batching to reduce timing correlation
Threat Model
The browser is designed to defend against:
- ISP and exit-node traffic analysis
- Cross-site fingerprinting via canvas, WebGL, and other high-entropy APIs
- RPC endpoint surveillance (address queries to Infura/Alchemy etc.)
- On-chain address clustering and transaction graph analysis
- Behavioural biometric re-identification (bounded mitigation)
It does not fully solve (and makes no claim to solve) attacks by global passive adversaries with complete network visibility, OS or hardware-level side channels, or user operational security failures.
Non-Goals
A few things explicitly out of scope, to keep the design coherent:
- Extension compatibility: WebExtension APIs reintroduce identity surface that would undermine the fingerprint model
- User-controlled fingerprint tuning: the anonymity guarantee depends on users being indistinguishable from each other, not on individual customisation
- Opt-in or “best-effort” privacy modes: the model only works if it’s enforced uniformly
- Exposing execution mode (private vs public) to dApps
Deferred Design Questions
A few decisions that need to be made before implementation but don’t have obvious right answers yet:
- Profile persistence: should the same profile be assigned to a given origin across sessions, or rotated per session? Per-origin consistency is better for usability; rotation is better for unlinkability.
- Mixnet defaulting: Tor-only as the baseline with mixnet as opt-in, or default-on with an escape hatch for latency-sensitive contexts?
- Interaction hardening: where is the acceptable tradeoff between behavioural entropy suppression and usability?
- Web compatibility: some sites will break under strict fingerprint classes. What’s the escalation path when no compatible high-population profile class renders the site correctly?