Using Solflare in Air-Gapped Computers: Offline Signing Workflow for High-Net-Worth Solana Holders

A Solana holder with substantial SOL or SPL token positions faces a practical security dilemma: maintaining convenient access to DeFi platforms while reducing the attack surface that an internet-connected device presents. Hardware wallets provide one answer, but they require physical interaction and have transaction limits. An air-gapped signing workflow—where transactions are created on an offline machine, transferred to a signing device, and then broadcast from a connected system—offers a different balance. This approach isolates private key material entirely from network exposure while preserving the ability to interact with Solana programs, stake tokens, and manage complex transactions.

Solflare’s offline transaction signing capability makes this workflow practical for advanced users. Rather than storing keys on a hot wallet or relying solely on hardware device buttons, the workflow uses an air-gapped machine running an unsigned Solflare instance. The offline computer generates transaction details and produces an unsigned payload that never contains private keys. That payload is transferred to a signing machine—either via QR code, USB drive, or physical media—where Solflare signs the transaction using a local key or connected hardware wallet. The signed transaction then returns to the broadcast system for submission to the Solana network. Each step maintains isolation while the process remains verifiable at every stage.

Understanding the air-gap security model and its limitations

An air-gapped machine is a computer with no network connection—no WiFi, Bluetooth, Ethernet, or cellular connectivity. The device is physically isolated from any network infrastructure that could deliver malware, permit remote access, or enable exfiltration of private keys. For a Solana holder, this isolation means that even if an adversary compromises every connected device on the network, they cannot directly access keys stored on the offline system. That is the core benefit, and it is substantial when holdings are large enough that the cost of hardware, redundancy, and operational discipline is justified.

However, air-gapping is not absolute security; it is a architectural boundary that reduces specific classes of attack while introducing others. A machine that was never connected to the internet but was installed with pre-compromised software, or one that was connected briefly during setup or updates, may harbor dormant malware. Physical theft, shoulder surfing, malware on a device used to create QR codes, or careless handling of recovery phrases can defeat the isolation. The air-gap protects against remote network attacks; it does not protect against facility security, supply chain integrity, or user error.

The second limitation is that offline machines cannot verify blockchain state directly. When constructing a transaction, the system must trust that the transaction details—the account balances, program addresses, recent blockhash, fee estimates—are accurate. These details are gathered on a connected machine, displayed on the offline machine, and signed by the offline machine, but the offline device never queries the network to confirm them independently. An attacker controlling a compromised node or routing layer could show false balances or stale blockhashes. This risk is manageable by following rigid verification procedures and using multiple independent sources to confirm critical data, but it is a real trade-off of the air-gapped design.

For Solflare specifically, the workflow leverages Solflare security features including local encryption for private keys and offline transaction signing capability. The encryption is performed by the wallet itself, never transmitted to Solflare’s servers or third-party services. The offline signing does not require an internet connection to function; the wallet can generate unsigned transactions, display them for manual verification, and accept signed transactions for broadcast. This makes it suitable for high-value Solana operations where the cost of operational complexity is lower than the cost of potential key compromise.

Setting up the offline and broadcast machines

The first practical step is acquiring two separate machines or creating two separate system partitions. The offline machine will generate transaction details and perform signing; the broadcast machine will gather current blockchain state and submit signed transactions to the network. For maximum isolation, use dedicated hardware. A used laptop, a stripped-down desktop, or a dedicated single-board computer can serve as the air-gapped device. The broadcast machine can be a standard computer with internet access but should still maintain good security practices: current operating system, malware protection, regular updates, and clean browser access to trusted Solana tools.

The offline machine should be installed with a minimal operating system, no unnecessary software, and no network drivers enabled. Remove or disable WiFi cards, Bluetooth adapters, and cellular modules. Verify the removal using BIOS or device manager settings. Install a modern browser—Chrome or Firefox are both supported—and download the Solflare extension from the official sites.google.com/solflare-wallet.com/solflare-wallet-extension or verified distribution channels. Do not rely on browser auto-update on the offline machine; updates will not be available anyway. Instead, update the browser and extension periodically using an external USB drive on a connected machine, ensuring you download from official sources.

The broadcast machine requires a connected browser and access to tools that fetch current blockchain state. This machine should have network connectivity but be segregated from machines holding other sensitive data if possible. A dedicated user account, a separate browser profile, or even a virtual machine can reduce the risk of cross-contamination. Install Solflare on the broadcast machine as well, but use this instance only for watching balances and preparing unsigned transactions. Do not store private keys on the broadcast machine. Instead, use Solflare’s “watch-only” or “public key import” feature if available, or verify addresses offline and refer to them by memory or secure notes during the unsigned transaction setup.

Between the two machines, establish a physical transfer mechanism. QR code scanning is the most convenient: use a camera or smartphone on the broadcast machine to photograph QR codes displayed on the offline machine, and use a QR code generator on the offline machine (from copied text) to display signed transaction data. Alternatively, use a USB drive that is inserted into the offline machine, written to in isolation, physically removed, and then inserted into the broadcast machine. The USB drive must be formatted cleanly, used only for this purpose, and scanned for malware on the broadcast machine before use. Some users employ optical transfer mechanisms—displaying QR codes on one screen and photographing them with a camera isolated from the network—but this is typically excessive unless the risk model demands it.

Creating and verifying unsigned transactions on the offline machine

The offline machine has no direct access to blockchain state, so transaction creation relies on data imported from the broadcast machine. This is the critical step where accuracy must be verified. On the broadcast machine, use a web-based Solana explorer, an RPC endpoint, or Solflare’s own monitoring features to gather the following information: the current blockhash (valid for approximately 150 blocks, roughly 60 seconds), the fee per transaction signature (lamports per signature, typically 5000 currently), the public keys of all program addresses involved, and the current balances or state of relevant accounts.

Export this data in a format that can be manually transferred or photographed. Solflare on the broadcast machine can display transaction previews that include the destination address, token amount, program involved, and estimated fee. Write down or photograph these details. Transfer them to the offline machine using the physical mechanism established earlier—either by typing them manually, reading from a USB drive, or scanning a QR code. This process is deliberately slow and manual because each piece of information should be verified against independent sources before being entered on the offline machine.

On the offline machine, launch Solflare and navigate to the transaction creation interface. Enter the gathered details: recipient address, token amount, program address, blockhash, and expected fee. Solflare will construct the transaction and display it for review. At this point, the transaction is unsigned and contains no key material. Review the displayed details extremely carefully. Verify that the recipient address matches what was written or photographed from the broadcast machine. Confirm the amount in SOL or SPL token quantities. Check that the fee seems reasonable relative to the documented network rate. Look for any fields that seem incorrect or unexpected.

This verification step is where human attention matters most. An offline machine cannot verify that the recipient address actually belongs to the intended recipient, only that the address format is valid. If the address was changed in transit, or if it was incorrect from the start, the transaction will be signed and broadcast correctly but will deliver funds to the wrong location. Cross-reference addresses using multiple independent sources: if a friend provided an address, request that they verify it again via a different communication channel. If withdrawing to an exchange address, log in to the exchange separately and copy the address directly from the exchange interface rather than trusting email or chat.

Signing transactions on the dedicated signing machine

Once the unsigned transaction has been verified on the offline machine, it must be transferred to a signing machine. The signing machine is the third piece of the architecture: it may be the same as the offline machine or a second separate device. The purpose of having a dedicated signing machine is to segregate the act of signing from the act of broadcasting. An attacker who compromises a network-connected machine cannot immediately broadcast a signed transaction without also compromising the signing machine or physically accessing it.

For a typical workflow, the signing machine runs Solflare with a stored private key or a connected hardware wallet such as a Ledger device. Transfer the unsigned transaction payload from the offline machine to the signing machine using the physical mechanism. If using QR codes, display the unsigned transaction as a QR code on the offline machine, photograph it with a camera on the signing machine, and paste the result into Solflare. If using a USB drive, copy the transaction file to the drive on the offline machine, disconnect the drive, physically transport it, insert it into the signing machine, and import the transaction into Solflare.

On the signing machine, import the transaction into Solflare and review the transaction details one final time. Solflare will display the parsed transaction, showing the destination, amount, and program. Compare this display to the details you verified on the offline machine. If they match, proceed with signing. If anything appears different, stop immediately and retrace the transaction creation process. The key difference at this stage is that you are now authorizing the use of a private key or hardware wallet.

If using a hardware wallet such as Ledger, approve the transaction on the device itself. The hardware wallet will display the transaction details on its own screen, which is independent of any computer and cannot be spoofed by a compromised Solflare instance. Review the destination address and amount on the hardware device screen very carefully. Once confirmed, the hardware wallet signs the transaction and returns the signature to Solflare. If storing the private key directly in Solflare on the signing machine, use a strong local password and ensure the device itself is secured with full-disk encryption and a login password.

Broadcasting the signed transaction and recovery procedures

Once signed, the transaction is no longer bound to the offline machine or the signing machine. It is a complete, self-contained message that includes all necessary information and cryptographic proof that the holder of the private key authorized it. Transfer the signed transaction back to the broadcast machine using the same physical transfer mechanism. On the broadcast machine, import the signed transaction into Solflare or use a Solana CLI tool to broadcast it to the network.

Before broadcasting, verify the transaction one last time. Solflare will display the parsed transaction and the signature. Check the transaction ID (signature), which is a unique identifier for this transaction. If broadcast successfully, the signature will appear in Solana transaction history and on block explorers. If broadcast and rejected, check the error message: common failures include an invalid or expired blockhash, an incorrect account state, insufficient balance for fees, or a program-level validation failure. If the blockhash has expired (which can happen if transfer between machines took too long), return to the offline machine and create a new unsigned transaction with a fresh blockhash from the broadcast machine.

If the transaction is broadcast but you do not immediately see it in history, wait a few seconds and check again. Solana transactions are typically finalized in 10–30 seconds, but confirmation can take longer under network congestion. If after a minute the transaction has not appeared, check the transaction signature on a block explorer directly. If it does not appear after several minutes, the transaction was likely not broadcast successfully; attempt the broadcast again or investigate network connectivity on the broadcast machine.

For recovery and emergency access, maintain an offline backup of the recovery phrase used to create the keys on the offline machine. Store this backup separately from the offline machine itself—in a safe deposit box, a secure vault, or a distributed secret sharing scheme. The offline machine itself should be treated as a critical asset: maintain redundancy by keeping an encrypted backup of the wallet state, including the encrypted private keys, on a disconnected backup drive. If the offline machine fails, you can restore it from the backup. The backup drive should be encrypted, tested for restoration before it is needed, and stored securely offline.

Practical workflows for staking, DeFi, and batch operations

The offline signing workflow is not limited to simple fund transfers. Solana-based staking, DeFi interactions, and batch operations all generate transactions that Solflare can construct, sign, and broadcast using the same air-gapped architecture. For staking SOL, the offline machine generates a delegate transaction targeting a validator. Solflare constructs the transaction, displaying the validator’s public key and expected stake amount. You verify these details on the offline machine against independent sources—the validator’s website, a known validator registry, or communication with the validator operator. Once verified, sign the transaction on the signing machine and broadcast it from the broadcast machine. Solana’s staking system will then begin the delegation process.

DeFi interactions follow the same pattern. Whether lending on Anchor, trading on Serum, or providing liquidity on Orca, each action generates a transaction that Solflare can construct and sign offline. The key difference is that DeFi transactions often involve multiple accounts and complex instruction data. When reviewing these transactions on the offline machine, you may not immediately recognize all the account addresses or understand the instruction parameters. This is where additional research becomes necessary: look up the program address on a Solana explorer to confirm it belongs to the legitimate DeFi platform, verify the recent transaction data to understand what the program does, and use trusted community documentation to confirm the instruction format. If anything seems suspicious or unfamiliar, do not sign the transaction until you have traced back through multiple independent sources.

Offline transaction signing using Solflare also supports batch operations, where multiple transactions are signed together and broadcast as a sequence. Batch transactions can reduce total fees and ensure atomic execution of related operations. The construction and signing process is identical, but review is more important: examine each transaction in the batch separately, ensure they are in the correct order, and confirm that their combined effect matches your intent. A batch of 5 transactions might clear quickly if everything is correct, but misconfigured sequences can cause later transactions to fail while earlier ones succeed, leaving intermediate state inconsistent.

For ongoing operations—regular staking payouts, periodic rebalancing, or routine transfers—establish a documented checklist for each type of transaction. The checklist should include the exact data to gather from the broadcast machine, the verification steps on the offline machine, the signing process, and the confirmation steps. A written procedure prevents casual mistakes and makes it easier to delegate to a trusted team member if needed. The procedure should also include contingency steps: what to do if a transaction expires, if signing fails, or if the broadcast machine loses connectivity mid-operation.

Risks and failure modes in air-gapped workflows

The air-gapped architecture reduces network attack surface but introduces new operational risks. Transcription errors—typing an address incorrectly, misreading a character from a QR code, or entering the wrong amount—can cause funds to be sent to unintended recipients. These errors are not security failures; they are user mistakes that can be prevented only through careful procedures and multiple verification passes. For high-value transactions, verify each critical field at least twice, and request independent confirmation of addresses from the recipient whenever possible.

Hardware failure of the offline machine is another practical concern. If the device fails and no backup exists, recovery of the keys may be impossible. Maintain encrypted backups of the wallet state, including the encrypted private keys and the recovery phrase, stored on separate offline media. Test restoration from backups at regular intervals—ideally quarterly—to ensure that the backup process works and that you can recover the wallet if needed. A backup that cannot be restored is worthless.

Supply chain and installation integrity are also critical. If the offline machine comes pre-compromised, or if malware is introduced during operating system installation, the entire air-gap can be undermined. Use a clean installation media from official sources, verify cryptographic signatures where available, and minimize the software installed on the offline machine. Do not download or install software casually. Each additional program increases the attack surface. For Solflare, install only from the official distribution channels, and verify the extension ID and permissions before enabling it.

Network-to-offline attacks through side channels are theoretically possible but practically difficult. A researcher has shown that certain offline devices can be attacked through power analysis or electromagnetic emission, but these require specialized equipment and physical proximity. For a practical high-net-worth workflow, the risk is acceptable given the security benefits. However, if the threat model includes sophisticated adversaries with physical access to the facility, consider additional protections such as Faraday cages, which prevent electromagnetic emission from leaking information.

The final risk is operational lock-out. If both the offline and signing machines become inaccessible simultaneously, or if a critical recovery phrase is lost, the Solana holdings may become unrecoverable. Mitigate this by maintaining redundant offline machines, distributed backups of recovery phrases in secure locations, and clear procedures for recovery. A lawyer or trusted advisor can hold a copy of the recovery procedure in a sealed envelope, to be opened only in case of emergency or incapacity.

Best practices for Solflare security in offline workflows

Following Solflare best practices in an offline context requires attention to several operational details. First, use a strong password for the Solflare wallet on both the offline and signing machines. The password encrypts the private key material locally. If an attacker gains physical access to the machines, a strong password provides time and difficulty in accessing the keys, particularly if the disk is encrypted and the devices are powered off. Second, keep the offline machine powered off when not in use. An offline machine that is powered on but disconnected from the network is still vulnerable to physical attacks or to dormant malware that may execute and attempt to leak data via side channels.

Third, use custom RPC node configuration where possible. On the broadcast machine, if using Solflare’s built-in RPC connection, verify that it is connecting to a trusted node. Solflare’s default RPC is operated by the Solflare team, but for maximum security, consider running a personal Solana node and configuring Solflare to use it. A personal node provides complete control over the blockchain data returned and eliminates reliance on third-party RPC providers. This is an advanced step, but it ensures that all blockchain state you verify on the offline machine comes from your own infrastructure.

Fourth, maintain detailed logs of all transactions created, signed, and broadcast. Record the date, time, transaction type, addresses involved, amounts, transaction ID (signature), and confirmation status. This record helps detect any unauthorized transactions and provides a clear audit trail. If holdings are large enough to warrant air-gapped security, they are large enough to warrant detailed record-keeping.

Fifth, perform regular security reviews. Every few months, audit the offline machine for unexpected files or logs, verify that the backup restoration process still works, confirm that recovery phrases are still secure, and test a complete transaction cycle from creation to broadcast. This periodic review catches slow decay and ensures that procedures remain understood and executable. For organizations holding significant Solana positions, make the security review a formal process with documentation and approval from multiple people.