Today’s Community Picks highlights posts, projects, ideas, and reader comments from around the BSV community that remain worth attention. Some are new, some are continuing threads, and some are earlier signals that still help explain where builders and community voices are focused.
Wallet Infrastructure
A Cloudflare implementation makes BSV wallet infrastructure easier to self-host
bsv-wallet-infra-cloudflare is an open-source implementation of the BSV wallet-storage server designed to run as a single Cloudflare Worker.
The project ports the existing wallet infrastructure into Rust compiled to WebAssembly. It uses Cloudflare D1 for structured records, R2 for larger transaction and proof data, and KV for authenticated sessions.
The server stores wallet information such as transactions, spendable outputs, baskets, labels, and identity certificates. It supports BRC-31 authentication, BRC-29 payment handling, BEEF transaction data, transaction broadcasting, and Merkle-proof verification.
An important feature is interface compatibility. Applications built for the existing TypeScript wallet-storage service can use the same JSON-RPC methods and data structures with the Cloudflare implementation.
This does not move private-key control into the server. Its role is to provide the storage, synchronization, transaction-processing, and proof infrastructure that a user-controlled wallet may need behind the interface.
The project’s July hardening work also connects broadcasting with Arcade and established ARC services, verifies proofs against a chain tracker, and distinguishes genuine network rejection from temporary provider or proof delays.
Self-hostable wallet infrastructure matters because a user-controlled wallet still depends on reliable supporting services. Making those services easier to deploy across different environments can reduce dependence on one hosted provider while preserving compatibility across applications.
Developer Standards / SPV
BRC-119 gives Teranode subtrees a compact Merkle-proof format
BRC-119 defines the SubTree Unified Merkle Path, or STUMP, format.
A conventional Merkle proof connects a transaction with the Merkle root of an entire block. As blocks grow to contain very large numbers of transactions, constructing and transporting complete block-level paths for every registered transaction becomes increasingly demanding.
Teranode divides block processing into smaller subtrees that can be handled in parallel. A STUMP records the path between a transaction and the root of its particular subtree rather than immediately extending across the complete block.
That partial proof can be delivered soon after the subtree is processed. It can later be combined with the path from the subtree root to the block’s Merkle root, producing a complete BRC-74 BUMP suitable for SPV verification.
The format reuses the established BRC-74 level and leaf encoding while replacing the full block-height header with a compact subtree-height field. Multiple STUMPs can also be merged or carried together.
This is a technical standard, but its purpose is practical. Applications need timely evidence that their transactions were included without downloading and searching entire blocks. As transaction volume grows, proof infrastructure must scale alongside transaction processing.
BRC-119 provides a common format for moving those proofs through a subtree-based Teranode architecture. An implementation is already identified within the BSV Blockchain Merkle Service.
Source: BRC-119 / Merkle Service
Accounting & Commercial Records
triple-entry-bsv-sql explores blockchain-linked records beneath ordinary SQL
triple-entry-bsv-sql is an experimental research implementation connecting PostgreSQL with BSV Blockchain records.
Its central idea is that a user or business could continue working through ordinary SQL while selected database changes are mirrored into a cryptographically linked third entry on BSV Blockchain.
Traditional double-entry accounting records matching debits and credits inside an accounting system. A blockchain-linked third entry can provide a shared, timestamped reference that helps reveal later insertion, removal, reordering, or alteration of recorded events.
The project extends that model beyond accounting alone. Its proposed architecture includes electronic business documents, orders, invoices, payments, shipping records, and logistics events within the same commercial-data framework.
That is an ambitious scope, and the project should be understood accordingly. It remains research-grade, is centered on regtest development, has no published software release, and should not be treated as a production accounting or logistics platform.
The useful signal is the architectural direction.
Public blockchain infrastructure does not need to replace familiar databases or require every employee to work through a blockchain interface. It can operate beneath existing software, preserving cryptographic evidence while users continue working through ordinary commercial systems.
If that model can be developed securely, blockchain-linked accounting may become less about adding a separate ledger application and more about strengthening the records businesses already create.
Update — July 29, 2026
Leave a comment