Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.
Wallet Infrastructure / Air-Gap Transport
Keeping a signing device disconnected from every network creates an obvious security boundary, but it also creates a practical problem.
How does a connected application give an offline wallet the transaction information it needs, and how does the wallet return the resulting data?
A single QR code works for small messages. Real wallet payloads can be much larger.
An unsigned extended transaction, transaction evidence carried as BEEF, a cosigning request, or another BRC-100-related payload can exceed what is practical to place into one QR symbol.
BRC-141 defines a common optical transport for moving that larger data across an air gap.
The specification divides an arbitrary binary payload into blocks and displays the information as a continuing sequence of QR-readable parts. The offline device scans the stream until it has collected enough information to reconstruct the original payload.
The important feature is that it does not need to capture every particular frame.
BRC-141 uses a fountain-code approach. The beginning of the stream contains the original blocks, while later frames contain deterministic combinations of those blocks.
If the camera misses one QR code, the user does not necessarily need to wait for that exact frame to appear again. Other frames can provide enough information for the decoder to recover what was missed.
Frames can arrive out of order, and duplicates are tolerated.
Each stream also contains a session identifier so a receiver can distinguish the QR sequence it is currently collecting from stray frames belonging to another transfer. Once reconstruction succeeds, the complete payload is checked before it is returned to the application.
The transport does not need to understand the transaction
BRC-141 deliberately does not define what the data itself means.
It can carry a BRC-100 call, an Atomic BEEF transaction package, a cosigning envelope, or another binary record within the specified size limit.
The wallet or application using the transport remains responsible for interpreting that payload.
That separation is useful because an optical transport does not need a new wire format every time wallet functionality changes. Independent applications can agree on how bytes cross the air gap while using other standards to determine what those bytes represent.
The same separation applies to security.
BRC-141 checks whether the payload was reconstructed correctly after passing through the camera. It does not by itself establish who created the payload, and it does not encrypt what appears on the screen.
Authentication, signatures, encryption, permissions, and transaction verification remain responsibilities of the layers carried inside or above the transport.
A reference implementation is now available as a reusable package
The specification is accompanied by a TypeScript implementation in the BSV Blockchain development stack.
The @bsv/air-gap package provides the encoder and decoder without prescribing a camera interface, QR renderer, or wallet design. That allows browsers, React Native applications, Node applications, and other environments to build their own user experience around the same underlying wire format.
The public package has recently advanced to version 0.1.2.
BSV Browser already lists @bsv/air-gap among its dependencies, providing an early example of the transport library entering an actual wallet/application codebase.
This moves the idea beyond merely documenting how an animated QR protocol could work.
BRC-141 and BRC-225 take different approaches
BRC-141 is not the only recent proposal for the problem.
BRC-225, known as TKQR1, also defines an animated-QR transport for arbitrary payloads. Its approach is simpler: the payload is divided into explicitly numbered pieces, and every required piece must eventually be collected before reconstruction can finish.
BRC-141 instead uses fountain coding so missing one particular frame does not necessarily prevent recovery.
The specifications describe themselves as peer alternatives. Their formats are not interchangeable, although an application could choose to support both.
Having competing approaches at this stage is not necessarily unusual. What ultimately matters for interoperability is whether independently developed wallets and offline signers converge on formats they can exchange without requiring a custom QR protocol for every application.
A small layer between online and offline infrastructure
Recent BSV wallet development has made air-gapped operation more visible.
Vault Manager explores an offline environment that verifies transaction evidence before signing. Other developing wallet infrastructure includes hardware-backed keys, recovery systems, BEEF-based transaction evidence, and mobile applications that need to exchange increasingly structured information.
Those systems still need a bridge across the deliberate absence of a network connection.
Animated QR transport is a small part of that architecture, but without an agreed format, each wallet can end up inventing its own way of splitting, displaying, scanning, and reconstructing the same information.
BRC-141 attempts to make that layer reusable.
The blockchain does not become involved merely because a QR code is being scanned. The value is interoperability between the devices that prepare, verify, and sign the transactions that eventually reach it.
It is a quiet piece of wallet infrastructure, but exactly the kind that becomes more important as offline signing moves from isolated demonstrations toward independently developed systems expected to work together.
Source Links
BRC-141 — Fountain-Coded Air-Gap Transport for Arbitrary Payloads / @bsv/air-gap / BSV Browser
Sources: BRC-141 on Beersy
September 10, 2026
Leave a comment