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.
Cold Storage / SPV
Vault Manager builds an air-gapped workflow around transaction evidence
Vault Manager is an offline-first tool for operating a BSV cold-storage environment with transaction verification kept inside the vault.
The project is designed around an air gap. Its interface can be built into a static package, transferred through removable media, and operated without outbound network access. Signing decisions therefore remain inside the offline environment rather than depending on a connected wallet service.
What makes the project particularly interesting is that offline signing is only one part of the design.
Every transaction artifact entering or leaving the vault is required to use Atomic BEEF, keeping the transaction together with the evidence needed to establish its ancestry or inclusion. The vault implements its own ChainTracker so that Merkle proofs can be checked against block headers supplied independently to the offline environment.
The documented operating procedure calls for at least two independent header sources during a session. If transaction evidence cannot be verified against both, the vault is instructed to reject it.
The project also treats physical procedure as part of the system.
Its operating guidance includes two-person control, recorded sessions, serialized removable media, checksum verification, build logs, and defined processes for transferring software into the air-gapped environment.
That distinction is important for high-assurance storage.
Keeping private keys offline reduces one class of risk, but an offline computer can still be given misleading transaction data. A signing environment therefore also needs a way to determine what it is being asked to sign and whether the transaction evidence presented to it is consistent with the blockchain it independently recognizes.
Vault Manager brings SPV, transaction evidence, software integrity, and physical operating procedure together around that problem.
It is highly specialized infrastructure rather than an ordinary user wallet. That specialization is precisely what makes it worth watching: as BSV wallet architecture develops, cold storage can increasingly verify transaction evidence rather than functioning only as an isolated signing device.
Source: GitHub
Wallet Standards / Multiparty Applications
BRC-229 lets a wallet hide a cryptographic scalar even from the application using it
BRC-229 introduces a wallet capability for a particular class of multiparty cryptographic applications.
Some protocols require several participants to apply secret mathematical transformations to shared data and later remove those transformations without any participant revealing the secret they used.
A familiar example is “mental poker.”
Digital playing cards can be represented cryptographically and shuffled or masked by several players. Each participant applies a private transformation. Because the underlying elliptic-curve operation is commutative, those masks can later be removed in a different order while no application or other player ever needs to learn another participant’s secret scalar.
BRC-229 gives a supporting BRC-100 wallet a way to perform that operation.
An application supplies an arbitrary valid secp256k1 curve point. The wallet derives a private scalar internally and can either multiply the supplied point by that scalar or later multiply it by the scalar’s modular inverse.
The application receives the resulting point but never receives the scalar itself.
Rather than adding another method to BRC-100, the proposal uses the existing getPublicKey call through the BRC-98 permission-module mechanism. Wallets that support the module interpret requests inside its reserved namespace accordingly, while wallets without the capability reject them.
That preserves the existing application-to-wallet interface while allowing specialized cryptographic behavior to be added behind it.
The immediate examples are games and verifiable shuffles, but the broader pattern is interesting.
A wallet increasingly becomes more than a place that signs payments. It can act as a protected cryptographic boundary, allowing applications to use carefully defined capabilities while secrets remain inside the wallet itself.
BRC-229 is a new standard proposal and implementation support will determine how useful that model becomes in practice.
Wallet Standards / Application State
BRC-164 gives applications a stable way to find one wallet output again
BRC-164 addresses a much smaller problem, but one that becomes important when applications begin holding and managing specific outputs through a BRC-100 wallet.
Suppose an application creates or receives an output that it expects to use later.
While the application is running, it may know exactly which wallet record represents that output. After the application closes and restarts, however, it needs a dependable way to find the same record again.
Scanning every output in a basket and attempting to reconstruct that relationship is inefficient and can become increasingly fragile as wallet state grows.
BRC-164 defines a simple convention for solving this.
A wallet or application can attach a tag of the form id:<key> to a held output. Later, the ordinary BRC-100 listOutputs method can query that complete tag and return the corresponding wallet record.
No new wallet method or storage mechanism is required.
The identifier is deliberately modest in meaning. It is not a transaction ID, global asset identifier, token identifier, origin, proof of ownership, or public blockchain identity. It is simply a stable handle for finding one particular row inside the wallet storage that created it.
That separation is useful.
Application state does not always need to become blockchain state. Some information exists only so software can reliably reconnect its own interface with objects a wallet is already holding.
BRC-164 standardizes that small piece of coordination using the tagging mechanism BRC-100 wallets already provide.
These details rarely become headlines, but they are part of what turns a technical wallet interface into dependable application infrastructure. Applications need to survive restarts, recover their state, locate the outputs they were working with, and continue without inventing a different storage convention every time.
Source: BRC-164
Update — September 4, 2026
Leave a comment