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.

AI & Agents / Wallet Infrastructure

bsv-wallet-cli Turns BRC-100 Wallet Functions Into Infrastructure for Software Agents

A BSV wallet does not necessarily need a graphical interface or a person sitting in front of it.

bsv-wallet-cli explores a different model: a self-hosted wallet that can run as infrastructure and expose its capabilities directly to applications, servers and software agents.

The open-source project is implemented as a single Rust binary. It can operate as a command-line wallet, run as an HTTP service exposing all 28 BRC-100 WalletInterface endpoints, or do both at the same time.

That makes the wallet less like a standalone application and more like a service other software can call.

An application can ask it to construct and sign transactions, manage outputs, derive public keys, create and verify signatures, encrypt and decrypt data, create HMACs, work with certificates, discover identities and perform other wallet functions defined through the common interface.

The application does not need direct access to the wallet’s private key material to perform those operations.

The agent can use the wallet without becoming the wallet

That separation becomes particularly interesting for AI agents and other autonomous software.

A conventional approach might give each agent its own keys, wallet database and funding source.

bsv-wallet-cli supports another arrangement.

One wallet server can remain on controlled infrastructure while several separate agents connect to it through the BRC-100 interface.

The agents send requests describing what they need—for example a protocol identifier, key identifier, counterparty or transaction action—while key derivation and signing remain inside the wallet service.

The repository describes this as a custody-separation model.

An agent can run inside a replaceable virtual machine or application environment without requiring the wallet’s root private key to be copied into that environment.

If the application process is discarded, the wallet infrastructure can remain separate.

That does not make the system automatically secure.

The wallet server itself becomes sensitive infrastructure and still needs appropriate authentication, network isolation, operating-system security, backups and access policies.

But separating the software performing a task from the system controlling the keys reduces the number of places where key material needs to exist.

One wallet can serve multiple agents

The project also documents a shared-wallet model for fleets of agents.

Several independent agent processes can connect to one wallet server, use one funding source and work from the same UTXO pool.

That has practical implications for machine-operated services.

Instead of provisioning a completely separate wallet for every agent, an operator could manage funding and key material centrally while allowing individual software processes to request permitted wallet actions through a common interface.

Spending operations are serialized through the wallet engine, while non-spending operations such as cryptographic requests, status checks and queries can run concurrently.

The project also includes tools for splitting UTXOs, helping prepare a wallet for workloads where several independent transactions may need to be constructed in parallel.

The model still requires careful application policy.

A common technical interface does not by itself determine which agent should be allowed to spend how much, sign which message or use which certificate.

Those controls remain responsibilities of the operator and the systems placed around the wallet.

BRC-100 becomes useful beyond graphical wallets

The architecture illustrates a broader consequence of a standardized wallet interface.

BRC-100 is often visible through browser wallets, mobile wallets or desktop applications because those are the interfaces people directly interact with.

But the WalletInterface itself describes capabilities rather than a particular user interface.

If two implementations expose the same methods and data structures, an application can potentially change the wallet environment beneath it without redesigning its own wallet integration.

bsv-wallet-cli is designed to remain wire-compatible with MetaNet Client.

A developer can therefore build against the familiar BRC-100 interface locally and later point compatible software toward a separately hosted wallet service by changing its connection rather than rewriting its wallet logic.

That becomes especially relevant as software agents begin performing tasks that involve payments, signatures, encryption or identity.

The agent does not necessarily need its own specialized wallet API.

It can use the same standardized wallet capabilities available to conventional applications.

MCP makes the same wallet callable by AI tools

The repository also includes a separate MCP server.

Model Context Protocol allows an AI agent environment to discover and call external tools through a defined interface.

In this implementation, the MCP service exposes the wallet’s BRC-100 functionality as tools that an agent environment can call.

The wallet daemon remains responsible for the actual wallet operations.

The AI-facing process becomes another client.

That is an important architectural boundary.

The language model does not need to know a private key. It does not need to implement transaction signing internally. And it does not need a different wallet architecture simply because the caller happens to be an AI agent rather than a conventional application.

It requests a defined operation from wallet infrastructure built to perform that operation.

Transaction lifecycle infrastructure is also being connected

The wallet is not limited to constructing and signing transactions.

Its current architecture also connects with transaction broadcasting, network status and Merkle-proof handling.

The repository documents integration with ChainTracks for header and proof validation, several broadcast providers for fallback, and an Arcade mode designed around the Teranode transaction-broadcast architecture.

In Arcade mode, the wallet can receive network-status events, react when transactions are seen or rejected, and acquire Merkle proofs after mining through several possible paths.

That creates a wider lifecycle:

an application requests an action, the wallet constructs and signs the transaction, broadcast infrastructure submits it, network events report what happens next, and proof infrastructure eventually supplies evidence of inclusion.

Those responsibilities can remain separated while communicating through defined interfaces.

An early example of wallets becoming service infrastructure

bsv-wallet-cli is an existing developer project rather than a newly launched wallet product. Its package history lists version 0.2.27 as published on September 8.

Its significance for Under the Surface is therefore not a release date.

It is the model becoming visible around it.

Wallet functionality can sit behind an API.

Applications can run elsewhere.

Agents can remain replaceable.

Keys can remain inside a separate wallet environment.

And the same BRC-100 interface can serve a graphical application, command-line software or an autonomous agent without requiring each of them to invent a different cryptographic and payment stack.

That points toward a useful role for the wallet in machine-driven applications: not something an AI agent has to become, but infrastructure the agent can call when it needs authority to sign, pay, encrypt or prove something.

Source: bsv-wallet-cli — GitHub

Update — September 23, 2026