EN
Join the waitlist Join the waitlist

Article 12 of 123 min read

Small and native: C++, no JavaScript runtime, from a workstation to a Raspberry Pi

A wallet is a security program. It should be small enough to audit, fast enough to forget about, and free of moving parts that are not its own.

A C++ chip above a monitor, a laptop and a single-board computer
One native binary per platform.
On this page

C++ and Qt

AirNox Wallet is written in C++ with the Qt toolkit. The cryptography, the chain code, the transaction builders and the screening all live in one native core, compiled for each platform. The interface is native too. There is no embedded browser rendering the wallet and no scripting engine running it.

That has three consequences you can feel. The wallet starts in a moment. It idles quietly, with a footprint that leaves the machine to its other work. And there is no runtime underneath it that updates itself, loads packages, or executes code it fetched from somewhere.

What is not inside

No JavaScript runtime. A large share of wallet compromises travel through package ecosystems and script injection. A wallet without a script engine is not a target for them.

No web view. The interface is drawn by the toolkit, not by a browser component. There is no page to inject into.

No telemetry, no analytics, no trackers. The wallet talks to blockchain nodes and to the swap and bridge providers you choose to use. It does not talk to us. Nothing phones home, and there is no account to create.

Four platform tiles for Windows, Linux, macOS and Raspberry Pi, and three crossed-out items: no JavaScript runtime, no web view, no telemetry
Where it runs, and what it leaves out.

Platforms

The desktop application runs on Windows, Linux and macOS, as a native build for each. The same code runs on Raspberry Pi class hardware, which makes AirNox a fit for embedded installations: an exchange-office terminal, a kiosk, a back-office signing station. A small board with a screen, a USB NFC reader and the wallet is a complete, air-gap-ready point of operation, with the keys on a phone that taps the reader.

One signing core

The phone app and the desktop share the same core. The code that derives keys, builds a transaction and decodes one for the screen is the same code on both devices, compiled for each. There is one implementation of each chain to audit, not two that have to agree, and a fix on one side is a fix on both.

Why it matters

Small and native is not a style preference. Every dependency is a place where someone else's mistake becomes yours. Every runtime is a surface. Every network call that is not strictly needed is a leak of something. A wallet that is a single native program, talking only to the nodes you point it at, is a wallet you can reason about. That is the standard we hold the whole product to, from the signer on the phone to the window on your desk.

The whole series

  1. Assume the computer is compromised
  2. Mass Adoption Security: the signer is a phone you already own
  3. Three ways across the gap: QR codes, Bluetooth LE and NFC
  4. Invisible on the air: a signer nobody can scan for
  5. The transport is never trusted
  6. What the phone shows you: transaction analysis on the signer
  7. The phone keeps its own record
  8. The vault on your desktop: Argon2id and a profile that resists guessing
  9. dApps without a browser wallet
  10. An MCP server with rules: AI agents under limits
  11. One protected wallet for all of it
  12. Small and native: C++, no JavaScript runtime, from a workstation to a Raspberry Pi

Join the waitlist

Leave your email and we will send release news. Nothing else.