Using Rabby Wallet Without Ever Connecting to the Internet: Air-Gap Guide

An institutional treasury holding significant cryptocurrency across multiple blockchains faces a practical constraint: the more accessible a wallet becomes, the larger its attack surface. A private key stored on an internet-connected device can be compromised through malware, a zero-day browser vulnerability, a supply-chain attack on wallet software, or a physical device seizure where the attacker has seconds to extract credentials. For custodians managing millions in assets across Ethereum, Arbitrum, Polygon, and other EVM chains, the question is not whether to use a wallet application at all. It is how to use one while keeping signing capacity completely offline.

Rabby Wallet is designed as a non-custodial multi-chain application, but its architecture also permits a cold storage workflow that separates key custody from transaction broadcasting. A signer remains completely isolated—never connecting to the internet, never seeing live balances, never receiving external input—while a watching-only instance on an internet-connected device constructs and previews transactions. The signer approves or rejects each one before the approved transaction returns to the connected device for broadcast. This workflow trades convenience for control. It is most valuable when the security risk of connection exceeds the operational burden of air-gap discipline.

The distinction between watching and signing

A watching-only wallet can derive public keys and generate receive addresses without ever touching a private key. It can fetch balance information, build transaction objects, estimate gas costs, and display a complete portfolio across all connected chains. What it cannot do is sign. Signing—the cryptographic act of proving ownership and authorizing a transaction—must happen on the device that holds the private key. In a traditional single-device setup, watching and signing occur on the same machine, which means that machine must connect to the internet to fetch data and broadcast results. In an air-gap setup, they are deliberately separated.

Rabby’s architecture supports this separation through extended public keys (xpubs) and QR code transmission. When you generate a wallet on an offline signer device using a seed phrase or hardware wallet, you export the xpub—a hardened public key that can derive all receive addresses and verify any transaction, but cannot sign or spend. This xpub moves to the watching instance via QR code, USB, or other one-way channels. The watching instance uses it to construct a complete portfolio view, track NFTs, calculate DeFi positions, and compose unsigned transactions. When a transaction is ready, it is encoded into a QR code and transferred to the offline signer. The signer reviews it, approves it, and returns the signed transaction via QR code to the watching instance, which then broadcasts it to the blockchain.

The security model depends entirely on the one-way nature of this channel. Data flows out of the offline device (public keys, signed transactions) but nothing returns except transaction objects that are too large to hide malicious code. The watching instance can attempt to trick the signer by presenting a false transaction, but the signer can verify that it is correctly formed and that it spends to the intended address. The offline device has no network connection to be hacked, no software update channel that could introduce malware, and no external input that could modify its behavior. Its only security obligation is to protect the seed phrase and the device itself from physical access.

Designing the offline signer

The most common air-gap signers are dedicated hardware wallets (Ledger, Trezor) or a secondary computer (laptop, tablet, or Raspberry Pi) used exclusively for signing. Each has different trade-offs. A hardware wallet is purpose-built, compact, and designed to resist tampering. It has a small screen, limited input, and no general-purpose computing capability—features that reduce complexity and attack surface. However, hardware wallets have their own firmware, which must be kept current, and they support only a subset of blockchains and transaction types. A general-purpose computer offers flexibility but demands more discipline.

If using a general-purpose device as an offline signer, begin with a clean installation of a minimal operating system. A lightweight Linux distribution (Ubuntu Server, Debian minimal) is preferable to a full desktop environment because it reduces unnecessary software and network services. Never install browser plugins, package managers configured for automatic updates, or cloud sync agents. Disable network interfaces entirely—remove WiFi drivers, physically disconnect Ethernet if possible, and confirm that the device cannot accidentally acquire a connection. An air-gapped device that connects to WiFi because a service was misconfigured has failed its fundamental purpose.

Install Rabby Wallet on this offline device through the official browser extension source. Verify the installation by checking the extension’s manifest and source code against the published GitHub repository. Create a new wallet using a strong, randomly generated seed phrase—not a phrase imported from anywhere else, and not one ever exposed to network-connected equipment. Store this seed phrase offline in a secure location: a physical safe, a safety deposit box, or a vault. Consider splitting it using Shamir’s Secret Sharing (SSS) so that no single piece reveals the whole. Export the xpub to transfer it to the watching instance, but never export the seed phrase or private key from this device under any circumstances.

Why transaction preview matters in an air-gap

The most dangerous assumption in an air-gap workflow is that the watching instance is trustworthy. It is not. The watching instance lives on an internet-connected device, perhaps in a web browser, potentially exposed to malicious websites, extensions, or network-level attacks. It could be compromised and silently modifying transactions before presenting them to the signer for approval. This is why Rabby’s transaction simulation and pre-signing preview are not convenience features—they are security-critical controls.

When the watching instance displays a transaction, it shows the from address, to address, amount, gas estimate, and the decoded data if it involves a contract interaction. The signer must review each field carefully before approving. For a simple ETH transfer, this is straightforward: verify the recipient address matches the intended target, and that the amount is correct. For a smart contract interaction—staking in Lido, swapping on Uniswap, or approving a token allowance—the preview must show the actual function being called and its parameters. A malicious watching instance could attempt to swap you into a different token, increase an allowance to a compromised contract, or approve a transfer to an attacker’s address.

Rabby’s decoded preview helps mitigate this. Instead of showing raw hex data, it displays what function is being called and what values it receives. However, the offline signer cannot independently verify that the watching instance’s decoding is correct. The signer must use additional tools: looking up the contract address on Etherscan to confirm it is the legitimate Uniswap router or Lido contract, checking the function signature in the contract’s source code, and cross-referencing the parameter values against what the user intended. This verification is tedious, which is precisely why attacks exploit it. A user tired of reviewing complex transactions may approve one that contains a subtle deviation.

The practical defense is to limit transaction complexity. Use only well-audited protocols. Avoid approving unlimited token allowances; instead, approve only the exact amount needed for a specific transaction, then revoke the approval afterward. For high-value or infrequent transactions, take time to verify every detail. If the watching instance is displaying a transaction that seems complex or unfamiliar, do not approve it until you have independently confirmed what it does through a second source.

Hardware wallet integration in an air-gap

A Ledger or Trezor device can eliminate the need for a separate offline computer. These devices store private keys in a secure enclave, display transactions on their own screen, and sign without exposing the key material. Rabby’s hardware wallet support means you can connect a hardware wallet to your internet-connected device, construct transactions normally, and approve them directly on the hardware wallet’s screen. The device asks for PIN confirmation and then cryptographically signs the transaction without transmitting the private key to your computer.

This is a practical middle ground: easier than maintaining a completely air-gapped computer, but significantly more secure than storing private keys in a browser extension on an internet-connected machine. The hardware wallet is a specialized, well-audited device that has resisted thousands of hours of security research. Its firmware can be updated, and updates should be installed promptly. The device itself should be purchased from the official manufacturer, never from a reseller where the physical integrity cannot be verified.

However, hardware wallets have limits. They support Ethereum and many EVM chains, but not all. They display transactions on a small screen, which can make verifying long addresses error-prone. They also require a PIN entry, which must be guarded carefully—an attacker who observes your PIN can compromise the device. For institutional treasuries holding across many chains or managing complex DeFi positions, a hardware wallet may be insufficient. For individual HODLers holding primarily Ethereum and a few EVM tokens, a Ledger or Trezor provides strong wallet security without the operational burden of a separate air-gapped computer.

Managing the transition between offline and online

The most vulnerable moment in an air-gap workflow is the transfer of data between devices. If you are using QR codes, the watching instance must have a camera or a phone that can photograph the QR code from the offline device’s screen. If you are using USB, you must have a dedicated USB device that has never been exposed to the internet. A USB stick that has been connected to a malicious computer can introduce malware to the offline signer. A USB stick used for both air-gapped and internet-connected purposes defeats the air-gap.

The safest transfer method is a one-way QR code: the offline device displays a QR code, and a camera-equipped phone (not network-connected during the transfer) photographs it and manually enters the data into the watching instance. This is slow and somewhat cumbersome, but it prevents bidirectional data flow. If you use a physical medium like USB, maintain strict separation: one USB device is used only for moving data from the offline signer to the watching instance, and it must be wiped and isolated between uses.

Document your transfer procedure and practice it multiple times before moving real funds. Test a small transaction end-to-end: generate an address on the offline signer, send a small amount from your watching instance, and confirm receipt. This reveals any procedural errors, mismatches between devices, or incompatibilities before you commit significant assets. The first time you use a new process should never involve large sums.

Backup and recovery procedures for air-gapped wallets

An air-gapped wallet’s seed phrase is its most critical asset. If the seed phrase is lost, the wallet cannot be recovered. If the seed phrase is exposed, the wallet is compromised regardless of how carefully you manage the signing device. Backup procedures must therefore balance two opposing risks: making the backup accessible enough to enable recovery, and keeping it secure enough that no unauthorized person can access it.

The most common approach is to write the seed phrase on paper and store it in a physical vault—a home safe, a safety deposit box, or a bank vault. Paper is not degraded by electromagnetic pulses, does not depend on batteries or software, and cannot be remotely hacked. However, paper can be stolen, damaged by fire or water, or lost. For higher-value holdings, consider Shamir’s Secret Sharing, where the seed phrase is split into parts such that any three of five pieces (or any threshold you choose) can reconstruct the original. Store these pieces in separate locations, making it unlikely that an attacker can steal all the pieces needed to reconstruct the seed.

Never store a backup in a cloud service, email, or any internet-connected location. Never photograph the seed phrase and store the photo on a phone or computer. Never type the seed phrase into a document editor or text file. The offline device used for signing should never be used to generate or store backups; backups are created manually or through a secure, non-network procedure. Test your recovery procedure on a secondary device before you depend on it. Create a small test wallet, follow your exact backup procedure, then attempt recovery to ensure that the procedure works and that you have all necessary information.

Operational discipline in practice

An air-gap is only as strong as the person operating it. Security failures come from slipping into convenience: connecting the offline device “just once” to download a package, using the same USB for air-gapped and regular backups, or approving a transaction without carefully reviewing it because you are in a hurry. These lapses are human, but they are fatal to an air-gap.

Establish clear procedures for each task: how to generate a new receiving address, how to construct a transaction, how to review and approve it. Write them down. Perform the same steps every time. Before moving large sums, practice the workflow with small amounts multiple times. If circumstances force a deviation—for example, you need to sign a transaction that is more complex than any you have encountered before—slow down and take extra time to understand it. If you cannot confidently verify what a transaction does, do not approve it.

The Rabby Wallet app offers tools that support this discipline: transaction preview, simulation, and decoded contract interaction details. Use them consistently. If a transaction seems unfamiliar or complex, take time to verify it against a second source. Keep the offline signing device physically secure. Never leave it unattended in an accessible location. If you suspect it has been tampered with—physically, or through discovering unexpected files—consider it compromised and generate a new wallet from a new seed phrase.

When air-gap is appropriate and when it is not

An air-gap is appropriate for holdings that are large enough to justify the operational overhead, infrequently moved, and managed by people who can maintain discipline. Institutional treasuries holding millions in cryptocurrency, long-term HODLers who move funds once or twice a year, and custodians managing assets on behalf of others are candidates. An air-gap is not appropriate for frequent traders, users who need to access DeFi constantly, or anyone who finds the additional steps burdensome enough to encourage shortcuts.

The security benefit of an air-gap diminishes if you undermine it through carelessness. An offline device that is physically accessed by others, a seed phrase written on a sticky note next to the computer, a USB device that gets connected to infected machines, or a user who approves transactions without reviewing them—these are security failures that an air-gap cannot prevent. Before committing to this workflow, honestly assess whether you will maintain the discipline it requires. If the answer is no, a hardware wallet provides substantially more offline storage security than a standard internet-connected wallet, with far less operational complexity.

For those who do maintain the discipline, an air-gap provides genuine protection against the most sophisticated attacks. A malicious website, a compromised browser extension, a zero-day vulnerability in Rabby’s code, or a supply-chain attack on software distribution cannot affect an offline signer. The attacker would need physical access to the device itself. For an institutional treasury or a long-term holder of significant assets, that shift in the threat model is meaningful.