Blog

A user in a jurisdiction with capital controls or political instability decides to hold cryptocurrency through a browser wallet rather than a custodial service. The obvious choice is to route all traffic through Tor to mask their IP address and prevent ISP-level observation. Yet simply enabling Tor in a browser does not automatically make a wallet’s operations private. Different wallet applications handle network requests differently, and the metadata that survives encryption and anonymization layers can be substantial. Fastset and Alby, both designed for non-custodial asset management, represent two different approaches to this problem: one focuses on self-custody through familiar browser extension architecture, the other integrates with Lightning Network activity. Understanding what each wallet actually protects requires examining not just the privacy feature, but the complete transaction surface.

The question at stake is not whether Tor works. Tor does obscure origin IP addresses at the network layer when properly configured. The question is what information a wallet application leaks independently of network routing: wallet addresses used, transaction amounts and timing, frequency of balance checks, connection patterns to specific nodes or services, and browser fingerprinting data that can re-identify users across sessions. An anti-phishing design and wallet security approach matter less if metadata reveals enough context for correlation. This guide examines the practical mechanics of Fastset and Alby when used with Tor, identifies the metadata surfaces that persist, and establishes a framework for understanding what privacy-first browser wallet setup actually achieves.

Why Tor alone is insufficient for browser wallet privacy

Tor encrypts and routes traffic through multiple relays, preventing exit nodes and network observers from directly mapping an IP address to a destination server. This is meaningful protection against passive network eavesdropping and ISP surveillance. However, a browser wallet is an application layer above Tor, and it makes decisions about what to request, when to request it, and what information to embed in those requests. If a wallet application sends your address to a third-party balance checker every 10 seconds, Tor obscures which IP address sent that traffic, but the balance checker still learns that your address is being queried repeatedly at that interval.

This distinction is crucial and often overlooked. Network-level privacy and application-level privacy are not the same. Tor protects against “who is this IP address contacting,” but does not prevent a service from building a profile through “which addresses is this session querying, and with what timing.” A browser wallet communicating with blockchain explorers, price feeds, or node services will generate patterns. Fastset and Alby each handle this differently depending on their architecture and node selection.

The threat model also matters. A user avoiding ISP-level blocking or law enforcement localization has a different risk than a user trying to prevent address clustering through transaction correlation. A user whose threat model includes a malicious internet service provider is well-served by Tor. A user whose threat model is a blockchain analyst trying to link wallet addresses across multiple transactions needs different tools entirely. Many users assume Tor solves both simultaneously when it does not.

Fastset’s architecture and what metadata it retains

Fastset is a non-custodial browser wallet extension designed for simplicity and self-sovereignty. It generates and stores private keys locally in the browser’s encrypted storage, never transmitting them to external servers. When a user opens the wallet, Fastset must determine the balance and retrieve transaction history. To do this without relying on a single trusted service, it can be configured to use custom nodes or connect through multiple sources. The architecture is non-custodial by design: Fastset holds no user funds and cannot freeze or reverse transactions.

However, when Fastset queries a node or service to check balances, it must send the address in question. If that query goes through Tor, the service does not learn the IP address, but it does learn that a particular address is being queried with a particular timing pattern. If the user checks their balance every morning at 08:00 UTC, that timing signal persists regardless of Tor. If the user holds balances across multiple addresses and queries each in sequence, the wallet learns the relationship between those addresses in the same session—a transaction correlation vector that Tor does not prevent.

The key protection Fastset offers is that it does not store your keys on a server. The key limitation is that it must still communicate to learn current blockchain state. Users can reduce leakage by running a personal full node and configuring Fastset to connect exclusively to that node—essentially moving the metadata leak from a public service to a system the user controls. For many users, this is impractical. A simpler approach is to understand that connecting through Tor reduces ISP observation but does not eliminate application-level leakage. Visiting cryptoextensionguide.at provides structured guidance on setting up browser wallet configurations that minimize these risks through better node selection and connection discipline.

Alby’s Lightning Network integration and payment channel metadata

Alby is a non-custodial wallet focused on Bitcoin Lightning Network integration with support for direct on-chain interactions. The wallet can be connected to self-hosted Lightning nodes or used in a lighter mode connecting to public nodes. The significant difference from Fastset is that Alby’s primary value proposition involves creating and managing payment channels, which are fundamentally different from simple address-balance queries.

When a user opens a Lightning channel through Alby, they are broadcasting an on-chain transaction that creates a state channel with another participant. This transaction is public on the Bitcoin blockchain and visible to any observer. The channel itself reveals that two addresses or nodes are exchanging funds, and subsequent routing through payment channels can create inference about payment relationships. Tor protects the origin IP address of the wallet application, but does not make the channel announcement or the recipient address private. If a user opens a channel to a known Lightning service provider, the blockchain permanently records that association.

Alby addresses this partly through support for connecting to user-operated Lightning nodes, which allows the user to manage channels without directly exposing their wallet to the public network. However, most users operate Alby with a default or recommended node configuration, which may be a managed service. The privacy benefit of Tor is therefore conditional on the user also controlling their Lightning node infrastructure. For casual users, Alby through Tor offers better network privacy than Alby without Tor, but it does not provide payment privacy at the protocol level.

Metadata surfaces that persist through Tor configuration

Several categories of information remain visible or learnable even when both Fastset and Alby operate through Tor. Understanding these surfaces is essential for realistic threat modeling. First is address correlation through timing. If a wallet checks address A at 08:00, address B at 08:05, and address C at 08:10, every time this pattern repeats, it reinforces the likelihood that the same entity controls all three addresses. Tor does not prevent this; it only hides which IP address is making the queries.

Second is blockchain transaction patterns themselves. Both wallets broadcast transactions that are permanently recorded. A user sending from address X to address Y is visible on the public ledger regardless of Tor. If the user receives payments at address X from a known service (an exchange, employer, or merchant), the blockchain link between that service and address X persists. Alby users additionally expose Lightning channel creation events and payment route information depending on their node configuration.

Third is browser fingerprinting and session linking. Even through Tor, the browser extension itself can be fingerprinted by the websites it visits. If the user visits an exchange site in the same browser session as operating their wallet, and both sites use the same analytics or tracking infrastructure, the sites may correlate activity despite Tor isolation. Extensions add identifying characteristics such as user agent strings and installed add-on lists that can survive Tor circuits if not carefully managed.

Fourth is balance check frequency and node selection patterns. If a user connects through Tor to a specific node each time they check balances, and that node can correlate queries by timestamp or pattern even without an IP address, the node still learns which addresses are controlled together. Public nodes used by many users have less power to perform this inference; nodes selected because they are “fast” or “recommended” may be operated by entities with stronger inference capabilities.

Practical setup to minimize metadata leakage

A user implementing Fastset or Alby with actual privacy requirements should follow specific operational discipline. Begin by configuring the browser to use Tor exclusively; this means either the Tor Browser itself or a properly configured Tor socket on the operating system. Browser extensions are not guaranteed to respect Tor settings automatically, so verify that queries exit through Tor by checking the IP address on a Tor confirmation service before sending any transactions.

For Fastset, configure a custom node if possible. If using a public node, select one that is less likely to be operated by a surveillance entity. Spacing out balance checks is less convenient than automated monitoring but reduces timing-based correlation. Never check all addresses in immediate succession. Query different addresses at different times of day if feasible. These practices are tedious because metadata reduction requires disrupting the normal workflow that wallets optimize for.

For Alby, the Lightning integration introduces additional considerations. If connecting to a public node, understand that your channel announcements are visible. If the user’s threat model includes payment privacy, then channel announcements are inherently problematic, and Tor does not solve this. For users whose threat model is narrower—such as evading IP-level tracking during routine balance checks—Alby through Tor provides meaningful protection without requiring node infrastructure.

Both wallets should be configured with strong anti-phishing practices before any Tor connection is relevant. Verify that the browser extension is installed from the official source and that it is the authentic wallet application, not a phishing replica. Use the browser’s extension management interface to confirm the publisher, permissions, and installation source. Enable any optional authentication such as PIN-protected access. These measures prevent the Tor infrastructure from protecting a compromised wallet application.

What Tor and wallet design do not protect

Tor does not protect against malware on the user’s device that can intercept wallet operations before encryption. If the device is compromised, Tor cannot protect private keys, seed phrases, or transaction approval. A user installing an infected driver, kernel module, or privileged application can lose wallet security regardless of network configuration. The wallet security measures—strong encryption of stored keys, local key derivation, no remote backup of secrets—remain the primary line of defense.

Tor also does not protect against the user accidentally revealing information. If a user discusses their cryptocurrency holdings in an email account connected to the same device or network, or if they maintain social media accounts with transaction-timing patterns visible to followers, Tor provides no benefit. Privacy is a system property, not a button. The wallet’s privacy is only as strong as the weakest link in the user’s operational security.

Transaction finality and counterparty privacy are not solved by Tor either. A user receiving a payment through Alby still exposes their Lightning invoice, which reveals the payment amount and purpose if the invoice includes a description. The recipient learns the user’s node or channel information. On-chain transactions sent through Fastset are visible to all blockchain observers. Tor protects the IP address of the wallet software, but does not make the transaction itself private unless the underlying protocol (such as Monero or a confidential transaction scheme) provides that property.

Realistic expectations and risk classification

Users evaluating privacy-first browser wallet setups should classify their specific threat against the actual protections offered. If the threat is “my ISP sees which addresses I control,” Tor through Fastset or Alby solves most of this. If the threat is “blockchain analysts link my addresses through public transactions,” neither wallet setup solves this; only protocol-level privacy such as Monero or Zcash shielded addresses addresses it. If the threat is “my browser is compromised and malware steals my keys,” wallet privacy configuration is irrelevant; device security is decisive.

A privacy-first browser wallet setup is most valuable for users in jurisdictions where cryptocurrency ownership is restricted or monitored, where ISP surveillance is routine, or where political opposition makes financial surveillance a credible threat. For these users, Tor routing through Fastset or Alby meaningfully reduces the attack surface. A user in a jurisdiction with capital controls who holds Bitcoin should use Tor and a non-custodial wallet rather than a custodial service that can freeze accounts.

For users in jurisdictions with open capital markets and high internet freedom, the privacy benefit of Tor-routed browser wallets is smaller. The primary value is preventing transaction correlation through timing analysis and reducing the metadata available to service providers. This is valuable, but not transformative. The wallet’s security features—key encryption, anti-phishing verification, recovery safeguards emphasizing irreversible transaction risks—remain the dominant security controls regardless of Tor usage.

The operational discipline required to maintain privacy through Fastset or Alby over Tor is also underestimated by most users. Tor provides technical protection, but wallet metadata leakage still occurs through application behavior. Users must configure custom nodes, space out queries, verify extensions, maintain device security, and understand that blockchain transparency limits what any wallet software can protect. These practices are not optional conveniences if privacy is a genuine requirement.

Future directions and protocol-level improvements

The limitations of Tor-routed browser wallets have driven interest in protocol-level privacy solutions. Bitcoin development includes proposals such as Silent Payments, which allow users to receive payments without revealing a static address. Litecoin’s MWEB layer implements MimbleWimble for optional privacy. Monero and Zcash provide protocol-level address and transaction privacy. These approaches address the limitation that Tor protects network privacy but not ledger privacy.

Browser wallet development may also benefit from better integration with privacy-preserving services such as decentralized node networks or light client protocols that do not require trusting a single service. Implementations such as Electrum-style server protocols with filtering support could allow balance checking without revealing addresses to the service provider. These improvements would reduce the metadata surface that currently persists despite Tor usage.

In the shorter term, browser wallet design can improve through better node selection interfaces, clearer privacy disclosures, and operational workflows that discourage address clustering. Wallets could warn users about timing-based correlation, suggest spacing out balance checks, or provide built-in Tor integration that is verified and enforced rather than relying on external Tor configuration. These are incremental improvements, but they reduce the gap between user expectations and actual privacy.