The Hidden Cost of Rabby Watch-Only Mode: What Portfolio Trackers Miss About Your Privacy

A user manages Bitcoin across multiple self-custody addresses, Ethereum in a hardware wallet, and several smaller holdings scattered across different chains. Rather than importing each private key or seed phrase into a single wallet application, they add these addresses to Rabby’s watch-only feature. The interface displays consolidated balances, transaction history, and connected protocols in one place. For portfolio visibility, this seems like a clean solution: no keys are handed over, the user retains control of signing operations, and the application simply watches public addresses on the blockchain. Yet that apparent simplicity masks a substantive privacy question: what information does the wallet—and the services it connects to—actually collect about a user’s holdings, transaction patterns, and financial footprint?

The distinction between a watch-only mode and a dedicated portfolio tracker is not primarily about whether assets are at risk of theft. Both approaches keep private keys offline. The distinction is about what data flows where. When an address is added to watch-only mode in Rabby, the application must retrieve balances, transaction histories, and token holdings from somewhere. The way that retrieval happens determines whether an observer—a blockchain node operator, a data provider, a network proxy, or the wallet developer’s own infrastructure—can correlate public addresses with a user’s device, IP address, usage patterns, or other watching activity. A portfolio tracker like Zerion or DeBank makes similar requests but may do so through different architectural pathways, with different data retention policies, and under different privacy assumptions. The practical result is that two tools offering apparently equivalent functionality can expose different surfaces to different observers.

Why watch-only mode creates a data exposure problem that self-custody does not solve

Self-custody generally means that a user holds private keys directly, without delegating signing authority to a custodian. Rabby supports this across seed phrases, private keys, and hardware wallet connections through Ledger, Trezor, GridPlus, OneKey, Keystone, BitBox02, and CoolWallet. The promise of self-custody is correct as far as it goes: only the user can authorize transactions, and a wallet service cannot freeze, censor, or steal funds. That security model succeeds because signing happens locally on the device, and the wallet application need only broadcast valid transactions to the network.

Watch-only mode operates under a different premise. The user does not import a key; they enter a public address or extend a seed phrase to derive addresses without the private component. Rabby then needs to answer questions that require external data: How much Ethereum is in this address? What tokens does it hold? Has it interacted with any smart contracts? These questions are inherently observable. A blockchain is a public ledger, so anyone can query it. But the way a query is made—who asks, from which IP address, how frequently, and in what pattern—reveals something about the querying entity beyond the transaction data itself.

The watch-only design concentrates all those queries on the user’s device while the user is actively checking balances. A user who opens Rabby and immediately reviews ten different addresses across three different chains sends a burst of requests to some data provider. If that provider logs IP addresses and can correlate them with the addresses being queried, they build a profile: this IP often checks these ten addresses, likely within seconds of each other. Over weeks or months, even if the provider does not know the user’s name, they can infer that the same person controls a specific cluster of assets and probably lives in a specific geography. That inference is valuable to malicious actors—ransomware operators, thieves, and kidnappers have used portfolio tracking data to identify and target high-value addresses.

An alternative architecture would be for the wallet to use a privacy-preserving route to retrieve address data. This might mean routing queries through Tor, using a trusted node that does not log IPs, or employing a protocol-level privacy mechanism such as a light client that obscures the user’s requested addresses among other noise. Rabby’s current architecture depends on the data provider’s policies and the user’s own network configuration. The wallet itself does not automatically route through Tor or obscure query patterns. This means the privacy guarantee is partially conditional on factors outside the application’s direct control.

How Zerion, DeBank, and other portfolio trackers make different privacy trade-offs

Zerion operates as both a portfolio tracker and a wallet, depending on how a user deploys it. When used as a watch-only tool, Zerion retrieves the same blockchain data that Rabby would fetch: balances, transaction histories, token holdings, and DeFi positions. The architectural difference is that Zerion has historically been more transparent about data collection and has offered features—such as the ability to select which blockchain RPCs or data providers the application connects to—that reduce the risk of a single entity observing all a user’s queries.

DeBank similarly provides portfolio tracking for users who connect only public addresses. Both platforms allow integration through WalletConnect, which means a user can sign transactions with a separate wallet application while DeBank or Zerion handles visibility. The privacy implication of this architecture is that the tracking and signing operations are separated: the tracking application sees the addresses but cannot sign transactions, while the wallet application handles keys but may not be the primary interface for viewing holdings. This separation is not absolute protection—the tracker still sees all the data—but it changes the attack surface and the incentive structure.

The critical difference between a browser extension like Rabby and a dedicated portfolio tracker is that Rabby stores more state locally on the user’s device. When a user returns to Rabby after closing the browser, the wallet still has cached information about imported addresses, holdings, and transaction history. This cache has a convenience benefit: opening Rabby again is faster because data does not need to be re-fetched immediately. But it also means that accessing this data does not require a live network query each time. A malware application, a compromised browser, or a physical adversary accessing the device can read this local state.

Dedicated portfolio trackers often take a simpler approach: load data fresh each time the application is opened. This increases network requests and can be slower, but it reduces the local attack surface and limits the window in which cached holdings data can be exposed. For a user concerned about device-level compromise, the trade-off may favor a stateless tracker over a cached wallet. For a user focused on privacy from network observers, the architecture of the data provider matters more than the application itself.

The data provider layer: where watch-only queries actually go

When Rabby checks a watch-only address, it must query a blockchain data provider. This might be an Ethereum RPC node, an indexing service such as Alchemy or Infura, or a dedicated blockchain explorer API. Each of these providers has its own logging practices, data retention policies, and visibility into the querying user. A user who relies on Rabby’s default settings may not know which provider is handling their queries or whether that provider is logging IP addresses.

The Rabby Wallet app supports the ability to customize RPC endpoints and connect to custom nodes, which allows technically sophisticated users to direct queries to their own infrastructure or to trusted privacy-preserving services. However, most users will use the default configuration. The default providers are typically chosen for reliability and speed, not necessarily for privacy. A node or indexer that is well-known and heavily used is fast, but it also faces more scrutiny and more likely maintains detailed logs.

Block explorers and indexing services often maintain comprehensive logs of all queries. These logs can be subpoenaed by law enforcement, requested by intelligence agencies, or voluntarily shared with third parties under terms of service that users rarely read. A blockchain analyst who wants to know which IP addresses are monitoring a specific wallet can sometimes acquire this information from the provider’s logs. Even if the provider does not intentionally expose this data, a data breach affecting the provider’s logging infrastructure could leak millions of IP-to-address correlations.

This is where a portfolio tracker that aggregates data from multiple providers and obscures individual queries has a structural advantage. Zerion, for instance, can distribute queries across multiple data sources, making it harder for any single provider to build a complete profile of what the user is watching. The user’s device makes one request to Zerion, and Zerion internally decides which providers to query and how to distribute that load. From the perspective of each individual provider, they see only a fraction of the user’s queries, and often they see them coming from Zerion’s infrastructure rather than directly from the user’s IP address.

The institutional context: how Rabby’s broader integration landscape affects watch-only privacy

Rabby integrates with hardware wallets, software wallets, and institutional signing solutions. It can import accounts from MetaMask, connect to WalletConnect, and interface with Safe, Cobo, Argus, Amber, Fireblocks, Jade Wallet, and MPCVault. This integration ecosystem is powerful for users who want to consolidate multiple key sources, but it also creates a potential aggregation point for transaction and holding information.

When a user adds a watch-only address to Rabby and also imports a different account from a hardware wallet, Rabby now has visibility into both the watched addresses and the addresses controlled by the imported account. If the user then connects to a DeFi application through Rabby, and that application interacts with both sets of addresses, a sophisticated observer could infer that they are controlled by the same person or entity. The watch-only feature by itself is innocent, but its combination with other account sources can collapse the separation that was originally intended.

Institutional use cases amplify this risk. A user managing assets through Fireblocks for signing and Rabby for visibility is effectively handing Rabby a map of their institutional and personal holdings. If Rabby’s logs are compromised or its privacy policies change, that aggregated view becomes a liability. This is one reason that some sophisticated users prefer to use Rabby only for watching addresses and rely on a separate, air-gapped tool for signing and key management. The tools are then deliberately kept isolated, reducing the risk that a single compromise or policy change affects both the user’s security and their privacy.

Privacy-preserving practices for watch-only address management

A user who wants to use watch-only functionality while minimizing data exposure should take several concrete steps. First, use a custom RPC provider that does not log IP addresses or is operated by an entity the user trusts. Many public RPC endpoints include logging, but some do not. Running a local node is the most private option, though it requires technical competence and hardware resources. Second, route Rabby’s network traffic through Tor or a quality VPN that does not log connections. This hides the user’s IP address from the RPC provider, preventing direct correlation between the user’s device and their addresses.

Third, batch address queries rather than adding them one at a time. If a user watches twenty addresses, adding them all at once and then checking the wallet once daily creates fewer observable query patterns than adding a new address every few hours. A provider reviewing logs will see sporadic bursts of activity from a single IP rather than a stream of separate requests that might be easier to correlate with a specific person or entity.

Fourth, avoid connecting watch-only addresses to active transactions and DeFi interactions in the same wallet session. Use Rabby for visibility and a separate application (or a separate browser profile) for signing transactions. This prevents a provider who logs queries from building a complete timeline of both a user’s holdings and their transaction activity. Fifth, do not use watch-only mode for addresses that are connected to your on-chain identity. If an address has sent funds to a centralized exchange using your registered account, any observer who knows your exchange account can correlate your watch-only queries with your identity regardless of the network privacy measures you take.

Finally, review Rabby’s privacy policy and understand its data handling practices. The wallet developer may promise not to store logs, but that promise applies only to their own infrastructure. If Rabby relies on third-party RPC providers or analytics services, those providers have their own terms of service. A user is ultimately responsible for understanding the complete data flow, not just the wallet’s stated practices.

The comparison between active wallets and portfolio trackers is not a clean privacy win

It is tempting to assume that a dedicated portfolio tracker is inherently more private than a wallet with watch-only mode. Trackers such as Zerion are designed specifically for visibility and usually do not support signing transactions, which might suggest they are not in the business of logging user activity. But this reasoning is incomplete. A tracker still sees the same addresses and retrieves the same data. If anything, a tracker that is less attention-grabbing than a wallet might log requests less carefully, creating both a false sense of security and actual risk.

The more important distinction is that a dedicated tracker is a single-purpose tool, while Rabby is a multi-function application. If a user uses Rabby only for watch-only viewing and does not import any private keys, the privacy attack surface is limited to address queries and cached balance data. But most users of Rabby will also import accounts, sign transactions, and interact with DeFi through the same interface. This increases the value of the application to attackers and the consequence of a compromise.

For a user who needs unified visibility and active transaction capability, a portfolio tracker cannot fully replace a wallet. But for a user who is willing to manage active accounts through a separate application, using Rabby as a watch-only tool while tracking assets through Zerion or another dedicated tracker may reduce overall privacy exposure. The risk is fragmented across more applications, but each individual application sees less sensitive data.

What users should do differently about watch-only mode

The practical implication of this privacy analysis is that watch-only mode is not a neutral observation tool. It creates a data trace at the application level, the network level, and potentially at the data provider level. Users should treat watch-only addresses with the same care they apply to active wallets: be intentional about which addresses are visible in which application, understand where the data goes, and consider whether the convenience of unified portfolio viewing is worth the concentration of data in a single tool.

For a user managing a large portfolio, the use case for watch-only visibility is clear. Checking balances across ten different addresses would be tedious if each address had to be inspected separately in a block explorer. A consolidated view saves time and reduces mistakes. But that efficiency comes with a privacy cost that is not always obvious. A dedicated portfolio tracker that aggregates data through multiple providers and obscures individual queries may be slower to load and less integrated with signing, yet it may be a better privacy choice for a user who is concerned about address clustering.

The watchlist feature in Rabby should be understood as a convenience mechanism that trades some privacy for usability. Neither choice—using it or avoiding it—is universally correct. The right decision depends on the user’s threat model, the sensitivity of their holdings, and their tolerance for network observation. A user managing personal funds across multiple self-custody addresses and facing no specific surveillance threat can reasonably use Rabby’s watch-only mode without additional privacy measures. A user managing large institutional holdings, concerned about physical security, or operating in a jurisdiction with adversarial financial surveillance should invest in a more privacy-conscious infrastructure: custom RPC endpoints, network anonymization, and separation between viewing and signing operations.