Many cryptocurrency users want the security benefits of cold storage—keeping private keys offline or highly restricted—but lack access to a dedicated hardware wallet or find the cost prohibitive. A practical alternative is to configure a rabby wallet extension across two devices: one for signing transactions and one for monitoring balances and preparing transfers. This approach, sometimes called “air-gapped” or “watch-only” management, reduces the attack surface on internet-connected machines while keeping assets under direct personal control. The setup works because Rabby is a self-custodial wallet that can separate key storage from transaction approval, turning a standard browser extension into a two-device security architecture.

The strategy does not require custom coding or advanced technical knowledge, but it does require discipline and understanding of what each device does. One machine holds the private keys and remains offline or strictly isolated; the second machine monitors accounts, prepares transactions, and uses Rabby’s transaction simulation features to verify what will happen before signing. The security gain comes from forcing an attacker to compromise two separate devices or networks to move funds. The usability cost is slower transaction workflows and the need to manually transfer unsigned transactions between devices. For users holding meaningful balances and willing to accept longer confirmation processes, this trade-off is often worthwhile.

Understanding the watch-only and signing device split

The fundamental principle is role separation. A watch-only device imports an extended public key (often called an xpub or zpub in wallet terminology, though Rabby uses account-derived addresses). This device never touches the private key. It can display balances, show transaction history, build unsigned transactions, and display what approvals or transfers would cost in gas. It cannot move funds because it lacks the cryptographic material required to sign. The signing device, by contrast, stores the private key and handles all approval operations. Ideally, this device remains disconnected from the internet except during specific, planned signing sessions.

Rabby’s architecture supports this separation through its support for hardware wallets and custom key management. When setting up a watch-only instance of the rabby wallet extension, the process involves exporting the account’s public key from the primary device, then importing it into a separate installation where the private key is never loaded. Rabby does not natively export an xpub in the way some other wallets do, but it can work with derived account information when integrated with hardware signers or imported through advanced means. The practical workflow is to use the signing device to construct a recovery phrase, then use that phrase only on the signing device while configuring watch-only access on the monitoring machine.

A critical detail is network connectivity for the watch-only device. While it holds no private keys, it still broadcasts transactions to the blockchain network and queries balances. An attacker who compromises the watch-only device could potentially create false transaction proposals, redirect funds to an incorrect address, or observe which accounts are being monitored. Therefore, the watch-only device should run on a separate, physically different computer—not merely a different browser profile on the same machine. This prevents a single malware infection or supply-chain compromise from exposing both the monitoring setup and the signing keys.

Creating a secure signing device configuration

The signing device is where the recovery phrase and private keys exist. This machine should have minimal exposure to untrusted software, downloads, or network activity. The strictest approach is to keep it completely offline: no Wi-Fi, no Bluetooth, no network cable except during brief signing sessions on a separate, clean network. A more practical middle ground is to use an older computer running a minimal operating system, with Wi-Fi and Bluetooth disabled by default, network access through a hardwired connection to a separate router if needed, and no other installed applications except Rabby and essential utilities.

When creating the wallet on the signing device, Rabby generates a recovery phrase—a 12 or 24-word mnemonic that encodes the seed material for all derived keys. This phrase must be written down by hand on paper and stored in a physically secure location, such as a safe deposit box or home safe. Do not photograph it, email it, store it in cloud notes, or keep it on any internet-connected device. The signed transaction workflow then proceeds as follows: the user prepares an unsigned transaction on the watch-only device, exports it (typically as a JSON or hex-encoded string), transfers it to the signing device via USB or another offline method, signs it in Rabby on the signing device, and then moves the signed transaction back to the watch-only device for broadcast.

Rabby’s support for multiple EVM chains—Arbitrum, Optimism, Polygon, BNB Smart Chain, Avalanche, and others—means this setup applies across the entire ecosystem. The private key on the signing device controls accounts on all supported networks simultaneously. When a transaction is prepared for, say, Polygon, and then signed offline, the confirmation is valid only for Polygon. This reduces the risk of accidentally signing a transaction intended for one chain and broadcasting it on another, but the user must still verify the chain and contract address during the signing process.

Leveraging transaction simulation and approval management

One of the strongest security features in Rabby is its transaction simulation capability. Before submitting any transaction, the wallet displays a human-readable breakdown of what will occur: which tokens or NFTs will move, which contracts will receive approvals, what slippage is expected on a swap, and what the actual gas cost will be. This feature is particularly valuable in a watch-only setup because it allows detailed review before the transaction ever reaches the signing device. A malicious site or phishing attack might present a false transaction proposal, but the simulation layer helps identify anomalies.

The approval management system is equally important. Many EVM transactions involve granting permission to a decentralized application or router to spend tokens on the user’s behalf. These approvals can be abused if left unlimited or if an old approval is exploited when a contract is later compromised. Rabby displays all active approvals and their limits, allowing users to revoke or reduce permissions. In a two-device setup, the watch-only device can show all current approvals to the signing device before any new approval is requested. This creates an audit trail: the signing device operator can verify that the approvals requested match what the watch-only monitoring showed, and can refuse to sign if the amounts or addresses are unexpected.

The simulation feature also guards against a subtle but real attack: a transaction that looks correct in the wallet interface but executes very differently on-chain. A swap might claim to use a specific router but actually route through multiple hops with worse pricing. An NFT approval might be tied to a marketplace that has since been compromised. Rabby’s transaction simulation unpacks these details before signing, pushing the security decision to the user rather than leaving it to interface assumptions.

Managing wallet recovery and device replacement

The strength of a two-device setup is also its vulnerability during recovery. If the signing device is lost, stolen, or fails, the recovery process must retrieve the private key from the backup recovery phrase without compromising security. This is why the paper backup must be secure and accessible only to the legitimate owner. To recover, the user would install Rabby on a new signing device, enter the recovery phrase exactly as written, and verify that the derived account addresses match the original. This matching step is critical: if a single word is wrong, the derived key will be different and the recovery will fail silently.

The watch-only device does not need recovery in the same way because it holds no secrets. If it is lost or compromised, the user can simply erase it and set up a new watch-only instance by exporting account information from the recovered signing device. However, before erasing a compromised watch-only device, the user should assume that an attacker may have captured transaction data, account addresses, or even transaction proposals that were unsigned. On that assumption, moving funds to a fresh address on the signing device after device replacement is a reasonable precaution for high-value accounts.

For wallet recovery testing, users should periodically verify that they can recover from their backup phrase on a different device without using the primary signing machine. This test should be performed in a controlled environment where the recovered device is not connected to the internet and the recovered keys are not used to move real funds. Testing recovery this way identifies problems—forgotten passphrases, illegible notes, or missing steps—before an actual emergency.

Practical transaction workflows with Rabby wallet extension

A typical transaction workflow in a two-device setup proceeds as follows. First, the user accesses the watch-only instance of the rabby wallet extension on the monitoring device. They initiate a transfer, swap, or approval through Rabby’s interface. The wallet simulates the transaction and displays the details. The user reviews the simulation output carefully, comparing contract addresses against the expected destination and checking gas estimates. They then export the unsigned transaction, typically as a QR code or hex string, and transfer it to the signing device through a USB drive or other offline medium.

On the signing device, the user imports the unsigned transaction into Rabby and reviews the same details. Because the transaction is prepared on the watch-only device, it will contain all contract interaction details. The signing device’s Rabby instance allows the user to review the simulation once more before approving. If everything matches expectations, the user signs the transaction. Signing produces a signed transaction blob, which is then transferred back to the watch-only device. The watch-only device broadcasts the signed transaction to the blockchain. After broadcast, both devices will eventually show the transaction as confirmed.

This workflow is slower than standard wallet usage because of the offline transfer step. For a single transaction, the entire process might take 10 to 30 minutes depending on physical distance between devices and network confirmation time. For frequent trading or rapid transactions, this delay is impractical, which is why the two-device approach is best suited for hodling, long-term management, and occasional rebalancing rather than active trading. Users who require speed should keep a smaller hot wallet in Rabby on an internet-connected device for frequent operations while reserving the two-device setup for larger balances.

Addressing limitations and remaining risks

This setup is not true cold storage in the sense of a hardware wallet, and it carries risks that users must understand. A compromised watch-only device could, in theory, be used to trigger social engineering attacks—a sophisticated attacker might craft false transaction proposals designed to trick the signing device operator into approving a transfer to an attacker-controlled address. The best defense is the same discipline required for any wallet: verify addresses character-by-character, use address labels in Rabby to identify expected destinations, and be suspicious of any transaction that appears unusual or urgently required.

The signing device is also vulnerable if the machine itself has been physically tampered with or compromised at the firmware level before the wallet was created. If someone gained access to the signing device before the recovery phrase was generated, they could potentially extract keys. This is why the signing machine should be a trusted device that the user has physically controlled from its first use, or one purchased from a directly trusted source with verified chain of custody.

Another practical limitation is that Rabby does not natively support non-EVM blockchains such as Bitcoin or Solana. If a user maintains balances on multiple blockchain families, they will need separate wallets for each. For EVM assets, Rabby covers the landscape well, including wrapped versions of cross-chain tokens and stablecoins on multiple networks. But the user should verify that all their assets of concern are supported before committing to Rabby as the sole wallet solution.

A final consideration is the update cycle. Because Rabby is open-source and regularly updated, the signing device should occasionally receive updates to patch security issues. This creates a trade-off: staying on an older version to reduce changes to a stable system, or updating frequently to incorporate security fixes. A practical compromise is to update the signing device every few months or after any publicly disclosed vulnerability, doing so on a clean network connection, and then testing a small transaction before trusting the updated installation with large transfers.

When this approach makes sense versus hardware wallets

A two-device setup with Rabby provides meaningful security improvement over a single internet-connected wallet, and it costs much less than a hardware wallet—essentially just a second computer or repurposed device. It is appropriate for users who hold moderate balances, accept slower transaction workflows, have strong operational discipline, and already own or have access to a second machine. It is also useful as a training step: users who master two-device management with Rabby develop the habits and intuitions that make hardware wallet usage more natural.

However, a hardware wallet remains superior in one critical respect: the signing device is designed specifically for key storage, uses isolated processors, has minimal software attack surface, and is manufactured by a company with reputation and liability incentives to secure the product. A generic computer running Rabby, even in air-gapped mode, is not as hardened against sophisticated attacks. For very large balances, a self-custodial wallet approach should be combined with hardware signing rather than relying on a general-purpose machine.

The strongest approach for high-value accounts is actually a hybrid: use a hardware wallet as the signing device and Rabby as the watch-only and transaction preparation layer. Many hardware wallets, including Ledger and Trezor, can integrate with Rabby, allowing the extended public key to be imported for monitoring while all signing happens on the hardware device. This combines the security of dedicated hardware with Rabby’s superior user interface, transaction simulation, and approval management. Users can rabby wallet extension from the official source and then configure it to work with a hardware device, gaining the benefits of both systems.

Maintaining operational discipline over time

Security in a two-device setup depends heavily on consistent discipline. Users often weaken their own setup by moving the signing device online “just this once,” deciding that the offline transfer is too inconvenient, or forgetting security procedures during periods of inactivity. The stronger the security system, the more friction it creates, and the more tempting it is to bypass. To sustain this discipline, users should treat the two-device setup as a defined protocol rather than a casual practice. Document the exact steps, the location of backups, the physical security measures in place, and the conditions under which the signing device is accessed.

Regular operational tests help maintain familiarity with the workflow. Every few months, perform a small transfer or approval using the two-device process without any actual urgent need. This keeps the procedure fresh and helps identify forgotten steps or environmental changes—a moved computer, a new router, or changed backup locations—before they matter. Some users find it helpful to keep a checklist near the signing device: verify address, check gas estimate, confirm network, review approvals, sign only if all checks pass.

The watch-only device should also be treated as a secure system, even though it lacks private keys. Minimize the software installed on it, disable unnecessary features, use a strong password or biometric lock, and consider using an older operating system with minimal complexity. The goal is to reduce the attack surface and maintain focus on the wallet’s core function. A watch-only device that runs ten unrelated applications is more likely to be compromised than one dedicated to wallet monitoring.