Privacy architecture
Built to push a burner wallet far past what desktop and mobile wallets leak. Secrets stay in your tab, your IP enters through Nym before our gateway ever sees traffic, and the decrypting BG server forwards transactions and normal sync through Tor to an onion-hidden Monero core. Code, routing and hardware evidence — not faith.
No need to trust. Verify.
The decrypting hop runs inside an AMD SEV-SNP Bulgarian enclave and is designed to expose a hardware-signed attestation: proof that this exact no-log gateway is the code handling your request. Tamper with it and the quote breaks, so the wallet can refuse to connect instead of trusting a black box.
The same source compiles to the same hash, every time. Anyone can rebuild it and confirm that the binary the attestation reports is the binary you can read on GitHub. No hidden version.
Your seed, spend key and view key stay inside the browser. The gateway only receives already-prepared wallet traffic: public-chain sync requests, encrypted session material and locally signed transaction payloads — never the secrets that could spend or scan your funds.
Metadata is the real leak
Monero hides amounts and addresses on-chain. But a normal app on Windows, Android or iOS still hands out your IP, your timing, your device fingerprint and your network requests — straight to a node operator or an OS vendor. That metadata is what deanonymizes people. This wallet is built to shut that channel.
Typical software wallet
This wallet
Not just what — also when, how big, and from whom
Your browser talks into the Nym mixnet first. The Swiss-rooted privacy layer sees only that one of thousands of users submitted encrypted Sphinx traffic; it does not learn the wallet destination, the opened domain, or the Monero request behind it.
Traffic enters a packet-mixing network before it touches the gateway. Variable routing, cover-style packet flow and fixed-size envelopes make it harder to line up a browser action with a specific Monero request by the clock.
Requests are shaped toward uniform sizes so payload length and poll rhythm give away as little as possible about what you're actually doing.
After the Nym layer, BG forwards transaction broadcast and normal wallet sync through Tor to the hidden Monero core. The node's public location stays off the internet, and neither the user IP nor the gateway IP rides along to the Monero backend.
The backend serves compressed public-chain data; matching happens locally in WASM. The server stays blind to which outputs are yours.
Transactions follow Monero wallet conventions instead of inventing a browser-only fingerprint. Privacy that blends into the crowd, not privacy that looks custom.
Jurisdictional friction by design
Nym acts as the first privacy layer: its entry gateway may see an IP among thousands, but it does not know which wallet domain, onion service or Monero action sits behind the encrypted mixnet packet. The next hop is our Bulgarian SEV-SNP gateway — an EU jurisdiction with a crypto-tolerant operating climate and stronger procedural friction against unilateral foreign requests than a US-hosted backend. If a provider is pushed into cooperation, the design still keeps the two critical facts split: Nym sees an IP without contents, BG sees contents without the user IP, and transaction plus normal sync traffic continues through Tor to the onion-hidden Monero core.
Even a full node can't do some of this
Your identity isn't bolted to one machine at your address. There's no home node humming away to raid, watch, or trace back to you.
Spin up a fresh wallet in seconds. There's no long-lived node for an agency to quietly re-point or correlate across months of traffic.
Nothing persistent lives on your device. Close the tab and the session is gone — there's no local state to confiscate and replay.
Run a full node for deep verification and a burner for fast, decoupled, throwaway flows. The two don't compete — they complement each other.
A full node still wins on raw verification. A burner wins on decoupling, disposability and reach — and it stacks neatly with one.
Fees, disguised as change
Every transaction keeps Monero's standard two-output shape. Fees are never a separate, fingerprintable payment — they ride inside regular on-chain change. The network sees an ordinary transaction, and your wallet lands clean at zero with no tell-tale dust left behind.
When your change would land under $1.20, that sliver becomes the service fee instead of a traceable dust output. The recipient is paid to the cent, your balance hits $0.00 — and the dust trail heuristics love simply isn't there.
When change is $1.20 or more, 100% of it returns to your burner and the developer fee is exactly zero. You only ever contribute when there'd be privacy-leaking dust anyway.
Emptying the wallet? The fee is randomized between $0.50 and $1.20, so the final amount carries no fixed signature. The wallet ends at $0.00 with nothing left to correlate.
No dust outputs left behind to fingerprint your wallet across transactions.
Fees ride inside ordinary two-output change — no custom pattern for chain analysis to flag.
Service fees rotate across a pool of 100,000+ pre-generated addresses, picked locally at random — there's no single fee address to cluster transactions on.
You pay only as a side-effect of clearing dust, never a flat tax — incentives that stay honest long-term.
Wallets that end at exactly zero leave no remainder to track or seize.
Two routes, pick your level
Mixnet + onion, everyday
Browser → Nym mixnet → BG attested gateway → onion → hidden Monero core. Transactions and normal sync use this route by default: BG gets request content without your IP, while the Nym entry sees an IP without the wallet destination or Monero action.
Mixnet in front, Tor/onion behind — default, not an upgrade.
Only for old manual restores
Fresh burners and normal re-opens stay on the protected route. Only when restoring a wallet older than the 7-day default window can you choose a faster bulk-sync path for historical chain data — a speed tradeoff, never the normal transaction path.
Optional speed for deep history, not the default privacy posture.
Transactions and normal sync already use the Nym + Tor/onion route by default. The only speed tradeoff is the optional fast bulk-sync path for manual restores older than the 7-day window.
Honest ceiling
A browser wallet still isn't your own full node — and we won't claim it is.
Default mode is strong and disciplined, not magic: the Nym entry sees a connection, but not the wallet destination, Monero action, request contents, or onion backend.
Only manual deep-restore beyond the 7-day default window may use the faster bulk-sync exception if you choose it.
RAM cleanup is best-effort — JavaScript can't guarantee hardware-grade erasure.
Every claim here is meant to be verified against code, build hashes and attestation — not believed.