This meetup took wallet interoperability out of the browser and into the operating system. The demo showed one local wallet serving command-line tools, installed apps, and AI agents—then turned to the harder question of how that power should be governed.
The short version
- BSV OS exposes one local BRC-100 wallet to apps, shell commands, and agents while keeping private keys inside a system daemon.
- The live demo installed a Metanet app, applied manifest-based spending limits, made micropayments, and used the same wallet from a command line.
- Richard described the project as very early software that needs testing, security review, and wider platform support.
- The group proposed shared compatibility and security testing across wallet implementations without forcing every wallet to use the same permission model.
- AI policy engines may reduce approval fatigue, but BRC-100 interoperability alone cannot guarantee that a wallet or app behaves safely.
Interoperability is a boundary, not a single wallet
The opening discussion returned to the purpose of wallet standards. The goal is to let people choose among wallets while applications keep speaking a stable language. Money, identity, privacy, and application data should remain portable even when builders take different approaches to custody, interfaces, and permissions.
That distinction matters because BRC-100 defines an application-to-wallet boundary; it does not prescribe one product or one user experience. A command-line wallet, a desktop wallet, and a browser-integrated wallet can compete on security and usability while the same applications continue to work. The common interface creates room for choice rather than erasing it. Watch from 0:09.
BSV OS puts the wallet behind a daemon
Richard Hein introduced
BSV OS
as an operating-system-level wallet stack. In the demonstration, a local daemon exposed
BRC-100-compatible services to the shell and to applications. The bsv
command could create, unlock, inspect, and use a wallet, while a companion panel showed
identity, transaction history, policies, installed apps, and outstanding approvals.
The custody boundary was the central design choice. Private keys were stored through the operating system's keyring and remained inside the daemon. Browser apps could request wallet actions, but they did not receive the keys themselves. That creates a reusable system capability: any compatible app can ask the wallet to act without each app inventing its own custody layer.
The repository also included agent-facing documentation and a skills file so coding agents could learn the stack's commands and conventions. Richard framed that as part of a larger agent economy in which software needs payment tools, budgets, and controlled authority to spend on a user's behalf. Watch from 11:21.
An app install becomes a policy decision
The live tour made the architecture concrete. Richard installed TempleMusic from the command line. BSV OS read the application's manifest, surfaced its capabilities and spending caps, and required policy approval before the app could spend. The app then ran in its own window with the system wallet behind it.
A second demo used PixelNet, a game Richard built to exercise the stack. It connected to the OS wallet, paid a satoshi, minted a game item as an NFT, and exposed a path toward an atomic-swap marketplace. The particular game was less important than the reuse: the same wallet, policy layer, and application interface served a very different experience.
Back in the terminal, wallet balance and history were available to a human or an agent. BSV OS also exposed an MCP server, giving AI systems a structured route to wallet actions while keeping those actions inside the same policy boundary. Watch from 15:21.
Compatibility needs a security lab beside it
The demo led directly to a proposal for a voluntary wallet interoperability lab. Shared tests could check whether applications work across BSV OS, Metanet Desktop, Yours Wallet, HandCash, and other implementations. A deeper track could examine key derivation, encryption, permission handling, and behavior under malicious applications—not merely whether a happy-path transaction succeeds.
Richard was candid about maturity: at the time of the meetup, BSV OS was early software that needed users and adversarial testing. The group urged wallet builders to publish a security policy and a private route for responsible vulnerability disclosure. Shared standards would make reviews repeatable, while recommendations could evolve as evidence and independent scrutiny improve.
The larger aim is a productive kind of competition: multiple wallets can implement the same application boundary, learn from common tests, and still distinguish themselves by how well they protect users. Watch from 22:37.
Agents need budgets, identity, and an off switch
Machine-to-machine commerce was more than a future use case in Richard's presentation. He described an agent-economy stack using MCP servers and x402 payments, with child wallets and spending controls intended to keep automated activity within limits. A command-line interface gives agents a familiar tool surface; the daemon keeps the authority and audit trail in one place.
Later, Richard demonstrated an experimental decision component that classified spending patterns and could block unusual activity or ask a human for input. The idea addressed a real interface problem: prompting for every request creates approval fatigue, while approving everything abandons meaningful control.
The group did not claim to have solved that balance. Different wallets may interpret manifests and spending authorizations differently. That is useful competition, provided users keep control of their keys and each wallet makes its authorization logic legible, testable, and responsive when something goes wrong. Watch from 37:26.
A common interface still needs a common security culture
The closing minutes widened the frame from one project to the ecosystem around it. Interoperability gives builders a shared vocabulary, but no interface specification can guarantee good behavior on either side. Wallet teams still need clear security policies, coordinated disclosure, prompt remediation, and the humility to treat early software as early software.
That responsibility grows as wallets hold more than payments. The same system may carry identity, permissions, private data, and authority delegated to agents. Getting the boundary right means users can choose better tools without rebuilding every app; getting the culture right means that freedom does not come at the cost of avoidable harm. Watch from 44:29.
Explore the projects mentioned
- Full meetup replay
- BSV OS source and documentation
- BRC-100 specification
- EntangleIT
- Join the BSV community chat
Editorial note: This recap was prepared from a full local Whisper transcription of the September 18, 2026 recording. It condenses and paraphrases the discussion; follow the timestamped links for the speakers' complete remarks and context. Project details are described as demonstrated during the meetup and may have evolved since the recording.