A user downloads what appears to be a single browser extension, yet the footprint on disk, memory usage during runtime, and the actual data transferred involve several discrete components working together. Rabby Wallet, available as a Chromium browser extension and mobile app, presents an instructive case because its architecture separates transaction simulation, security scanning, NFT metadata fetching, token price tracking, and core wallet operations into distinct layers. Understanding what gets installed and why helps explain both the total size and the practical trade-offs between functionality and resource consumption.

The question matters because browser extensions occupy a sensitive position: they run in the context of every website a user visits, they have access to private keys if local encryption is weak, and a bloated or poorly optimized extension can degrade browser performance or consume battery on mobile devices. Before installing Rabby, users often ask whether the extension is lightweight, what data it stores locally, and whether all advertised features are included in the base download or whether some require network calls to external services.

Core extension size and what comprises it

The base Rabby browser extension, installed from the official Chrome Web Store, Brave, or Edge store, typically unpacks to 8–12 MB after decompression. This includes the JavaScript bundle for the wallet interface, background scripts that listen for blockchain events, content scripts injected into web pages, and vendor libraries for cryptographic operations. The compressed download itself is smaller, usually 2–3 MB, because the browser’s installer decompresses files automatically during installation. Users accustomed to lightweight add-ons may find even this footprint noticeable on bandwidth-constrained connections, though the one-time download burden is generally manageable compared to ongoing storage or memory use.

The extension’s primary executable code performs wallet initialization, account derivation, transaction signing, and user interface rendering. Rabby uses Ethers.js or Web3.js libraries to handle EVM blockchain interactions, which accounts for a substantial portion of the bundle size. These libraries include support for multiple network providers, contract decoding, and gas estimation. Because the extension must function without requiring users to install additional software, all necessary cryptographic primitives—ECDSA key generation, Keccak hashing, and encryption for local key storage—are bundled directly rather than delegated to external processes.

The interface layer, rendered using React or a similar framework, includes the popup displayed when clicking the extension icon, the settings page, and the transaction approval screen that users see before signing. Each screen must render account balances, transaction previews, and security warnings without meaningful latency. This creates a tension between feature richness and bundle size: more UI components and validation logic increase the download and memory footprint, while cutting features reduces functionality. Rabby’s design prioritizes transaction transparency, which requires enough code to parse contract interactions, simulate execution, and display expected balance changes.

When a user performs a rabby wallet download from the official store, the browser unpacks these components into a local directory, typically under `~/.config/google-chrome/Default/Extensions` on Linux or an equivalent path on macOS or Windows. The actual stored size depends on the operating system’s file system block allocation, but the logical footprint remains consistent across platforms.

Transaction simulation and security scanning: the heavyweight components

One of Rabby’s distinctive features is transaction simulation, which executes a transaction locally using a simulated EVM state and reports the expected outcome before the user signs. This feature prevents certain classes of errors, such as accidentally sending tokens to a contract address that cannot return them or approving an unlimited spending allowance to a malicious contract. Implementing this feature requires bundling a lightweight EVM simulator, which adds roughly 1–2 MB to the extension size depending on optimization.

The simulator does not run a full blockchain node; instead, it fetches the minimal blockchain state needed to simulate a specific transaction, uses that state temporarily in memory, and then discards it. This approach keeps the extension responsive and avoids storing gigabytes of blockchain history. However, the simulation engine itself—the code that interprets EVM opcodes, manages memory, and applies state transitions—is non-trivial. Rabby’s implementation focuses on the most common transaction types (token transfers, approvals, swaps, liquidity operations) and may fall back to a generic simulation for less common interactions.

Security scanning, integrated into the transaction preview, checks the destination address against known phishing lists, examines contract interactions for suspicious patterns, and flags unusual spending approvals. This logic is partly local—checking addresses against a cached phishing database—and partly remote. The cached database updates periodically and typically occupies 500 KB to 1 MB in local storage. When the local data is insufficient, the extension contacts a security service over HTTPS to obtain a verdict on an unknown contract address, but no private keys or signed transactions are transmitted in these queries.

The security scanning components add another 0.5–1 MB to the extension bundle, including the code to parse contract bytecode, recognize common patterns associated with phishing or rug pulls, and display warnings in the transaction UI. Because the goal is to catch errors before signing rather than to guarantee absolute security, the scanner accepts some false negatives (missing some attacks) and false positives (warning about legitimate but unusual interactions). Users should treat these warnings as a check, not an absolute safety guarantee.

NFT and token metadata: fetching versus caching

Displaying user-friendly names, icons, and decimal precision for tokens and NFTs requires metadata beyond what the blockchain itself provides. Rabby uses token registries and NFT metadata services to enrich the wallet display. A critical design decision is whether to bundle this metadata or fetch it dynamically. Including a complete token registry for all EVM chains would add 5–10 MB or more to the extension, making downloads slower and updates more frequent. Instead, Rabby bundles a curated set of well-known tokens (major stablecoins, blue-chip DeFi tokens, popular NFTs) and fetches additional metadata on demand.

The bundled token registry covers perhaps 200–500 of the most widely used tokens across Ethereum, Polygon, Arbitrum, Optimism, and other supported chains. This core set is included in the initial extension download and covers the vast majority of user transactions. When a user imports a wallet containing tokens not in the cached registry, or encounters an obscure ERC-20 or ERC-721 contract, Rabby queries external metadata services—typically OpenSea, Etherscan, or dedicated token APIs—to fetch names, symbols, decimals, and media URLs.

This hybrid approach keeps the extension lean while ensuring that users see sensible labels for common assets. The trade-off is that users with limited internet connectivity may see token addresses displayed as hex strings until metadata loads. Similarly, NFT images are not bundled; instead, URLs to external hosting are cached, and images are loaded on demand when the user opens the NFT viewer. This design avoids bundling thousands of image files but requires that external image services remain responsive.

Local caching of fetched metadata helps reduce repeated network requests. Rabby maintains a small local database—typically a few hundred kilobytes—of recently viewed tokens and NFTs. This cache persists across browser sessions and reduces latency on subsequent visits to the same tokens. However, local caching also means that if a token’s icon or name changes, the wallet may display stale information until the cache expires or is manually cleared.

Mobile apps and the install Rabby workflow on phones

The mobile experience presents different constraints. Android and iOS versions of Rabby are distributed through Google Play and the App Store, where size limits and storage considerations are more stringent. A typical mobile app install is 15–25 MB for Android and similar for iOS, larger than the browser extension because mobile apps bundle platform-specific code, native libraries for secure key storage, and permission handling specific to the operating system.

When a user chooses to install Rabby on a mobile device, the download size can be a meaningful factor on metered connections or devices with limited storage. The mobile version includes a built-in browser for viewing decentralized applications (dapps) and interacting with DeFi protocols, which adds code compared to the desktop extension that relies on the user’s main browser. Hardware wallet support—connecting to Ledger or Trezor via Bluetooth—requires additional native code to handle the communication protocol.

The “install Rabby” process on iOS is simpler in terms of permissions because the iOS App Store handles sandboxing, but it is more complex for key storage. iOS’s Secure Enclave requires specialized code to store private keys in a hardware-backed keychain, which Rabby must implement correctly to avoid weakening security. Android’s implementation varies depending on whether the device has a secure processor and which Android API level is targeted. This platform-specific complexity inflates the mobile app size compared to a theoretical minimum but is necessary for meeting security standards expected on phones.

Neither mobile app stores the entire Ethereum state or transaction history locally. Instead, mobile versions query blockchain data from public RPC endpoints or Rabby’s own service layer, keeping the app itself relatively lightweight. The extension is similarly stateless with respect to blockchain history; it does not maintain a local copy of all past transactions but retrieves them from block explorers or archive nodes when needed.

Optional and peripheral components

Rabby’s architecture includes several optional or conditionally loaded components that do not inflate the base download size but are worth understanding. Hardware wallet support—for Ledger, Trezor, and similar devices—requires only a small USB communication library in the desktop extension, typically under 100 KB. The library is included in all downloads, but it only activates when the user opts to use a hardware wallet; users with only software keys never load this code into active memory.

Gas estimation and fee calculation logic, used to populate suggested gas prices before transaction approval, draws from historical transaction data and current mempool state. This involves querying external services and performing calculations locally. The calculation code itself is minimal, but the data structures needed to work with multiple networks and fee markets add some overhead. A user who only interacts with a single chain will not benefit from this complexity, but supporting multiple networks and fee models is part of Rabby’s value proposition.

Watch-only functionality—the ability to import an address without importing the corresponding private key—requires minimal additional code. Once an address is imported, Rabby queries its balance and transaction history from public sources. This feature adds perhaps 10–20 KB to the extension and is always present even if the user never uses it. The size impact is negligible, but the principle illustrates how seemingly optional features can live in the extension without proportional overhead.

Biometric authentication for unlocking the wallet on mobile devices (Face ID on iOS, fingerprint on Android) relies on native APIs and platform security services. These features are present in the mobile app but absent from the browser extension, where browser-based security models handle authentication differently. The mobile app’s use of biometrics is more storage-intensive than the extension’s PIN-only approach, contributing to the size difference between platforms.

Network selection and provider redundancy

Rabby supports connections to multiple EVM networks and allows users to configure custom RPC endpoints. The extension includes a bundled list of publicly available RPC providers for Ethereum, Polygon, Arbitrum, Optimism, and others. This provider list is a plain text or JSON file, typically 50–100 KB, that maps network names to endpoint URLs and includes information about network characteristics (chain ID, native token symbol, block explorers).

The automatic network selection feature, which detects when a website is requesting connection to a specific chain and switches the wallet’s active network, relies on this provider list and some logic to handle chain switching. This adds minimal code but is convenient enough to be included by default. Users can also add custom RPC endpoints, which the extension stores in encrypted local storage. The extension does not bundle redundant or backup providers; it relies on the user to configure fallbacks or trusts that the default public endpoints remain accessible.

This design is practical but creates a dependency on external services. If all bundled RPC endpoints for a particular chain go offline, users cannot transact on that chain until they add a custom endpoint or the defaults are restored. The size impact is negligible—a few kilobytes for the provider list and configuration logic—but the operational implication is significant for users who do not understand this relationship.

Updates, deltas, and bandwidth over time

Once installed, Rabby receives periodic updates. The browser extension store handles updates automatically; the extension checks for new versions and downloads them in the background. Update sizes are typically smaller than the initial download because only changed files are transferred. A minor security patch might be 500 KB, while a major feature release could be 2–3 MB. Users on cellular networks or with very limited bandwidth may benefit from disabling auto-update and choosing to update manually when connected to WiFi, although this creates a security risk if critical vulnerabilities are patched and left uninstalled.

The mobile apps follow similar update mechanics through the App Store and Google Play. iOS and Android handle update delivery more carefully, often compressing deltas and offering staged rollout to catch problems before every user receives an update. The trade-off is less control for the user but more reliability and fewer situations where an update breaks the app for a significant portion of users.

Over a year of use, assuming monthly updates with an average size of 1 MB, a user downloading Rabby wallet updates will consume an additional 12 MB of bandwidth above the initial install. For most users, this is negligible. For users on very constrained connections, it remains a consideration, though security updates justify the cost.

Verification and spotting unofficial downloads

Rabby emphasizes that the official distribution channels are the Chrome Web Store, Brave’s extension marketplace, Edge’s add-on store, and the official rabby.io website for desktop and mobile downloads. Unofficial sources, including unverified GitHub releases or third-party mirrors, pose a phishing risk. An attacker could host a modified version that logs private keys or signs transactions without the user’s explicit approval.

The size of a download can sometimes hint at tampering. If an unofficial copy of Rabby is notably larger than the official version—say, 15 MB instead of 8–12 MB—it may contain injected code. Conversely, a significantly smaller version might have removed security features. Users should verify extension checksums or the published hash of downloads against official announcements, although few users perform this step in practice.

When performing a rabby wallet download from rabby.io or the official browser stores, users see an “Add to Chrome,” “Add to Brave,” or equivalent button that routes to the official store. This routing, combined with the store’s own security review process, provides a reasonable level of assurance that the extension has not been modified. Users who download a Rabby extension from any other source should treat it as potentially compromised and generate new recovery phrases afterward.