Wallet Infrastructure Watch / Applications
In Brief
SpiffyVault has opened a testnet beta of its self-custodial desktop BSV wallet for Windows, macOS and Linux, combining person-to-person payments, encrypted offline delivery, local block-header verification and BRC-100 interoperability.
The current download identifies itself as version 0.2.3 testnet beta, released October 4, 2026. The wallet operates only on BSV testnet at this stage, allowing users to test its payment and recovery flows without using BSV tokens of real value.
SpiffyVault is built around contacts rather than requiring users to exchange conventional payment addresses for every transaction. When two SpiffyVault users are online, the wallet says payments can be delivered directly between their computers. When the recipient is offline, SpiffyVault can instead create an end-to-end encrypted handoff held by a relay until the recipient reconnects.
That sealed-mailbox mechanism is separate from BRC-100 payments. SpiffyVault also supports payments to and from other compatible BRC-100 wallets, but those transactions do not use its offline mailbox system.
News Report
SpiffyVault has released the first public testnet beta of a desktop BSV wallet designed around person-to-person payments, local key custody, Simplified Payment Verification and interoperability with BRC-100-compatible wallet applications.
Developer Stephan February, known publicly as BeardPappa, announced the beta as a desktop BSV wallet with SPV, P2P and BRC-100 payment support. The current SpiffyVault site lists downloadable builds for Windows, macOS and Linux, with iPhone and Android versions planned later.
The wallet remains strictly testnet-only for the present release. SpiffyVault warns users that testnet coins have no monetary value and that real BSV tokens should not be sent to testnet addresses.
Pay People Rather Than Exchange Addresses
SpiffyVault’s main user-facing idea is reflected in its tagline:
“Pay people, not addresses.”
Instead of centering the interface on manually copying and pasting payment addresses, the wallet presents contacts as the primary payment relationship.
A user can select a person, enter an amount and send from within the contact interface, while the underlying wallet handles the transaction details.
That approach is not entirely new to digital wallets, but SpiffyVault combines it with a peer-to-peer delivery model and BRC-100 interoperability rather than making the contact system merely an internal account directory.
The broader objective is to make ordinary payment behavior resemble communication software: identify the person first, while the wallet handles the payment route underneath.
Direct When Online, Encrypted When Offline
SpiffyVault distinguishes between two delivery situations.
When both SpiffyVault users are online, the wallet says the payment is delivered directly from one computer to the other.
When the intended recipient is unavailable, SpiffyVault uses a different mechanism. The payment handoff is encrypted for that recipient and left with a relay until the recipient’s application reconnects and collects it.
According to SpiffyVault’s security documentation, these waiting handoffs are sealed with the Signal Protocol, and the relay holding them cannot read their contents.
If the recipient never comes back online to collect the payment, the sender can reclaim it.
This creates a store-and-forward model for peer payments without requiring both participants to maintain an active connection at the same moment.
The relay still provides availability infrastructure, but it is not intended to receive plaintext payment contents.
The Offline Mailbox Is Not the BRC-100 Path
The offline mechanism should not be confused with SpiffyVault’s BRC-100 support.
SpiffyVault explicitly says that its sealed mailbox is not available for BRC-100 payments.
For BRC-100 interoperability, the wallet instead allows users to share a payment key so that someone using another compatible wallet can pay them, and vice versa, without manually exchanging conventional addresses.
BRC-100 defines a vendor-neutral wallet-to-application interface intended to allow different wallet implementations to interoperate while keeping wallet-specific internals behind a common API. GitHub
SpiffyVault therefore supports two related but distinct payment experiences: its own contact-oriented P2P delivery between SpiffyVault users, and a standards-based payment route for interaction with other BRC-100-compatible wallets.
SPV Without Treating a Remote Balance as Final Authority
SpiffyVault also presents SPV as a core part of the wallet rather than an optional developer feature.
The wallet says it maintains its own copy of BSV block headers locally so that it does not have to accept a remote server’s statement of the user’s balance without verification.
That does not mean the desktop application stores the entire blockchain.
Simplified Payment Verification is designed around keeping enough block-header and proof information to validate relevant transactions without operating a full archival node. BRC-100 itself describes SPV as verifying transaction inclusion and validating the relevant block through its Merkle root and proof-of-work rather than downloading the complete chain. GitHub
For SpiffyVault, the practical consequence is that chain verification remains part of the user-side wallet architecture rather than being entirely delegated to a centralized balance service.
Keys Stay on the Desktop
SpiffyVault describes itself as self-custodial.
According to the wallet’s security section, private keys remain on the user’s computer and are stored using the operating system’s secure keychain. Signing takes place in a separate isolated process rather than directly inside the main interface.
The service says it does not hold the user’s funds, cannot move or freeze them, and does not require the user to create a conventional SpiffyVault account.
The current download page likewise states that the application can be used without an account or email address.
That architecture places recovery responsibility on the user.
One Recovery Phrase Restores Wallet and Identity
SpiffyVault uses a recovery phrase as the continuity mechanism if the original computer is lost or replaced.
The wallet says the phrase can restore the user’s wallets and identity on a new computer.
That distinction matters because SpiffyVault is not treating identity and payment as entirely separate application layers. A contact-oriented wallet needs continuity not only of spendable keys but also of the cryptographic identity used to recognize counterparties and participate in the wallet’s communication model.
The site is equally clear about the consequence: without the recovery phrase, SpiffyVault says neither the company nor anyone else can recover the wallet.
A Real Desktop Application
The current release is distributed as a native desktop application rather than as a mobile interface wrapped for larger screens.
SpiffyVault currently lists:
- macOS for Apple silicon and Intel
- Windows 10 and 11, 64-bit
- Linux x86-64 as an AppImage
Version 0.2.3 is explicitly labeled testnet beta.
That qualification is meaningful rather than cosmetic. Early public testing has already produced user reports around wallet creation and interface behavior, with February responding directly and investigating problems.
The current release should therefore be understood as a public testing milestone rather than a finished mainnet wallet.
Mobile Comes Later
SpiffyVault also lists iPhone and Android versions as planned, but they are not part of the current beta.
The immediate focus is the desktop implementation, where the developer can test P2P networking, SPV behavior, recovery, BRC-100 compatibility and the offline-delivery system before exposing the same model across mobile platforms.
Mainnet BSV support is likewise reserved for a later release.
The present environment uses free testnet coins so users can test the application without putting real funds at risk.
A Different Combination of Existing Wallet Ideas
None of SpiffyVault’s individual concepts exists in isolation.
Self-custody, SPV, encrypted communication, contact-based payments and BRC-100 compatibility all have precedents elsewhere in the BSV ecosystem.
What distinguishes SpiffyVault is the way those elements are being combined into one desktop payment model.
The wallet does not ask users to choose between a peer-to-peer contact system and standards interoperability.
SpiffyVault users can use the richer direct relationship when both parties run the same wallet, while BRC-100 provides a broader interoperability path beyond the SpiffyVault user base.
Likewise, offline delivery does not require the relay to become the wallet custodian, while local block-header verification reduces the need to treat a centralized balance endpoint as the final authority.
The resulting architecture attempts to keep the convenience of modern messaging-style payment interfaces without moving key custody back toward a central service.
Developer Context
Stephan February / BeardPappa
Stephan February is a long-time BSV developer whose recent work has concentrated heavily on peer-to-peer networking, wallet infrastructure and token protocols.
Other notable public development includes:
- OverNode — a peer-to-peer networking architecture designed around local-first applications, SPV and distributed data exchange without a conventional centralized coordination server. February describes OverNode as a P2P network with wallet functionality rather than simply a wallet application. CoinGeek
- TSL1 — a BSV token protocol developed by February around UTXO-based scaling and transaction validation. CoinGeek
- Dart-LibP2P — February has also worked on Dart/Flutter peer-to-peer networking tooling, including interoperability with the reference Golang libp2p implementation. LinkedIn
SpiffyVault brings several of those recurring interests together in a consumer-facing wallet: peer-to-peer communication, SPV verification, local key control and interoperable payment infrastructure.
BSV TIMES Read
SpiffyVault is interesting less because BSV Blockchain needs another wallet than because it approaches wallet architecture as a combination of identity, communication and independently verifiable payment state.
The phrase “pay people, not addresses” sounds primarily like a usability choice, but implementing it without turning the wallet provider into the trusted intermediary requires additional infrastructure. The software needs a persistent way to identify counterparties, deliver information when one side is unavailable, protect that information while it waits and still preserve the user’s independent control of the keys.
SpiffyVault’s beta combines those requirements in a relatively coherent way. Direct P2P delivery handles the online case, an encrypted relay handles temporary unavailability, BRC-100 provides an interoperability path outside the wallet’s own user network, and SPV gives the application a way to verify relevant chain information without relying exclusively on a remote balance service.
The separation between those systems is just as important as their combination. The encrypted mailbox is a SpiffyVault-specific feature and does not silently become part of BRC-100. Likewise, BRC-100 compatibility does not require the wallet to give up its own P2P payment model.
That modularity is useful in an ecosystem where no single wallet should need to become the permanent gateway for every user or application.
The current testnet release is still early, and a mainnet wallet will need to prove more than architecture. Recovery needs to work reliably, SPV verification must behave correctly across edge cases, encrypted handoffs must survive real network conditions, and ordinary users need an interface that makes those mechanisms understandable without exposing unnecessary complexity.
Testnet is the appropriate place to discover those weaknesses.
If SpiffyVault reaches mainnet with the same basic architecture intact, the more consequential development may not be another desktop wallet entering the market. It may be another example of BSV wallet software moving away from the assumption that users must choose between convenient centralized coordination and self-custodial, peer-oriented infrastructure.
Source Links
Stephan February on OverNode and P2P Networks
Stephan February on TSL1 and BSV Development
Posted on October 5, 2026
Leave a comment