AirGap Wallet: keeping private keys on a second, offline phone

Two devices, one secret that never leaves the second one

The design goal of AirGap is that your private key is created and used on hardware that has no network connection, while the phone you actually carry handles everything else. The system is split in two. The AirGap Vault application lives on a dedicated device with no connection to any network, which is what makes it air gapped. The AirGap Wallet application lives on the everyday smartphone and, according to the project description, has access only to public information.

That split drives the whole flow. The Wallet creates an unsigned transaction, encodes it as a QR code, and the Vault reads it, signs it, and sends a signed transaction back as a QR code that the Wallet then broadcasts to the network. Nothing secret ever lands on the internet-connected phone, and the phone holds no key capable of spending your funds.

The audience is a user with a meaningful balance in more than one chain who is willing to treat a second device as signing hardware. That is a real cost, in hardware, in charging, and in the discipline of keeping the Vault offline. The alternative framing, that any hot wallet is fine if the key is encrypted, misses what this project is for: the point is not protecting a key at rest on a connected device, it is removing the key from a connected device entirely.

The Wallet builds and broadcasts, the Vault signs

The division of labour is precise. AirGap Wallet keeps an overview of all accounts with their balances and transaction histories, and those accounts are synced from the Vault. It never touches the secret data stored in the Vault. What it is responsible for is creating and broadcasting transactions.

That means two distinct network operations sit on the Wallet side: assembling a transaction payload, and pushing an already signed one to the chain. The signing itself happens in the Vault. The consequence for the user is that the Wallet must be online, or at least able to reach the relevant chain, while the Vault must be offline, and those two states are incompatible in the same device, which is why the split exists in the first place.

The transport between the two is QR codes, and the documentation also describes app switching when the Vault is installed on the same device. That fallback is worth understanding for what it is: it is a convenience for testing or for a user who cannot yet commit to two devices, but it removes the physical separation that the air gap depends on, since the same phone then has both roles. The QR path across two physical devices is the configuration the architecture is actually built for.

Multi-chain support through the coin library

AirGap Wallet is a hybrid application, meaning the same codebase ships to both Android and iOS. The repository layout shows an Angular and Ionic application, with an angular.json, an ionic.config.json, and separate apple, android and ios directories for the native shells, plus a capacitor.config.ts that ties the web build to the native projects. The primary language of the repository is TypeScript.

Chain support is delegated. The application is built on AirGap's protocol agnostic airgap-coin-lib library, which is what allows one app to handle Aeternity, Bitcoin, Ethereum, Tezos, Cosmos, Kusama, Polkadot, Groestlcoin and the rest of the listed currencies. The library also has its own contribution rules, and integrating a new blockchain is a task that lives in that project rather than in the wallet.

The wallet also carries its own secure storage implementation, which the description lists alongside the coin library as a deliberate architectural choice. On top of the library sit patch scripts that run on postinstall, including patch-coinlib.js, browserify-coinlib.js and copy-builtin-modules.js, plus jetifier and dependency version patching. That is a sign of a codebase that carries build-time adjustments for native dependency compatibility, which matters to anyone forking it.

Building the app from source with Capacitor

There are two ways to get the app. The documented download route is the Google Play and App Store listings, which is what almost every user should do. Building from source is for contributors and for anyone who needs a modified build.

The build documentation starts by installing the dependencies, with a global Capacitor CLI and then the project dependencies:

$ npm install -g @capacitor/cli
$ npm install

The project can then be run in a browser, which is the fastest loop for frontend work:

$ npm run start

That script maps to ng serve in the package.json, so the Angular dev server is what you get. The native projects are built and synchronised with Capacitor, and afterwards the iOS or Android project can be opened in its IDE:

$ npm run build
$ npx cap sync

$ npx cap open ios
$ npx cap open android

The unit tests run through ng test, and the package.json also carries a protractor based end to end setup with separate Docker and CI configurations, plus a lint script over src TypeScript files. A contributor therefore needs a full native toolchain, Xcode or Android Studio, to exercise anything that touches the QR scanner.

A container image for reproducible browser test runs

The repository ships a Dockerfile that is worth a look even if you never build the app, because it shows how the maintainers run browser based tests. The base image is node:20, and the image installs the system libraries that Puppeteer's bundled Chromium needs, including fonts for Chinese, Japanese, Arabic, Hebrew and Thai characters, which matters for a wallet that renders asset names in many scripts.

The container installs node-static as a static web server, creates an /app directory owned by the unprivileged node user, and copies in package.json, package-lock.json and a set of the same patch scripts the npm postinstall hook runs. The build runs as the node user rather than root. The image also includes a Trivy ignore file, which points at container vulnerability scanning in the pipeline.

The practical benefit for a contributor is that the browser test environment is defined in the repository rather than in a wiki page. The cost is size and build time, and the fact that you are pulling a full Chromium plus a font set for every run. There is also a .devcontainer directory in the repository, which suggests the same reproducibility goal for editor environments.

Where the air gap model strains

The design has honest costs, and they are worth stating before adoption rather than after.

The first is the second device. A Vault phone that is never on a network cannot receive the account list, the balances, or the transaction you need to sign. Every signing session is therefore a physical interaction, which means the two devices must be in the same physical place, and the workflow is slower than tapping a hardware wallet that also has a screen, let alone a hot wallet.

The second is that the separation depends on user discipline. The Vault is described as having no connection to any network, and the documentation does not describe an enforced mechanism that keeps it that way. A device with Wi-Fi enabled, or with a SIM that attaches to a network on power-up, is no longer air gapped, and the app has no way to detect that. In practice the air gap is a procedure you follow, not a property the software enforces.

The third is release cadence and versioning. Recent releases include v3.35.0 on 2026-09-28, with v3.34.4 in March 2026 and v3.34.3 in January 2026, and the last push was on 2026-09-25. Two apps that exchange data through encoded QR codes have to agree on that format, so a mismatched version between the Vault and the Wallet is a plausible failure. The README does not document a compatibility policy or a version pinning rule, and it does not document any rollback path, which leaves you reading the changelog yourself to judge whether a Vault update breaks a pairing you rely on.

Against a plain hot wallet and against a signing device

The two real alternatives are a conventional wallet app on one phone, and a hardware signing device attached to a connected computer. The difference in approach is worth spelling out, because AirGap sits between them.

A conventional hot wallet holds the key in the app's storage on a device that is online, or protects it with a passphrase. Its advantage is speed and simplicity. Its cost is that the key exists on a machine with a network stack, so the security rests entirely on the phone's own integrity, its OS patching, and the app's implementation. AirGap moves the key off that machine entirely and pays for it in physical ceremony.

A hardware signing device keeps the key in a dedicated chip and has the computer prepare the transaction, with the device confirming it on its own screen before signing. Against that, AirGap's Vault is a general phone, which means the signing device is a full operating system with a full app, not a device built to do one thing. What AirGap gains is that the signing side can be completely network free, since a hardware device normally needs a USB connection to a connected host to talk to the chain, whereas a QR code does not.

For a hot wallet user, the difference is a second phone to keep charged and offline. For a hardware wallet user, the difference is a slower but network-free signing path. Neither trade is free, and for small balances the AirGap arrangement is ceremony without a matching threat model.

Licence, security reporting and who builds on this

The wallet is released under the MIT licence, with the licence file named LICENSE.md at the repository root, and the package.json author entry names Papers GmbH. MIT means a company can take the code, modify it, and ship the result in a closed product without owing source disclosure, though the copyright notice has to travel with the code. That is a different position from the copyleft licences common in self-custody tooling, and it is the main legal reason a vendor might build on this codebase rather than only use the published app.

Vulnerabilities have a documented route. The README asks that any security issue found in the application be sent to [email protected], with a statement that all security vulnerabilities will be promptly addressed. The source is public, so the reporting path is the mechanism that makes a private disclosure useful rather than a public issue.

Contributing is coordinated rather than open-ended. The project asks that you reach out in an issue before integrating a new feature so the change can be discussed, and points blockchain integration work at the airgap-coin-lib guidelines. The related projects listed include the wallet itself, the coin library, an AirGap Linux distribution and an apk-signer, which suggests the system extends beyond the two phone apps into dedicated signing devices and offline packaging of the software itself.

Editorial conclusion

Adopt AirGap Wallet if you hold assets across several chains and want signing to happen on a device that never touches a network, and if you are willing to carry and maintain a second phone. Do not adopt it as a single-device wallet, for everyday hot payments, or if you cannot keep a spare handset in offline state without it reattaching to a network. Verify first that the Vault app and the Wallet app are on the same version line, that the QR transfer completes with the balances you expect, and that a test transaction in a low-value account comes back signed before you move anything you care about.

Frequently asked questions

Official sources

1. airgap-it/airgap-wallet on GitHub
2. Issues
3. License: MIT
4. README
5. Releases