Wallets & Identity
A modern wallet may need to preserve considerably more than a seed phrase.
In a BRC-100 wallet, transaction history, derivation information, output state and other wallet data can be part of what allows the software to understand and continue operating with the assets associated with its keys.
Yours Wallet already made that distinction visible through remote synchronization and backup. Its current architecture goes a step further by treating that storage as a service that can be operated independently from the wallet itself.
A user can keep wallet state locally, select a remote server as the active storage location for synchronization across devices, maintain additional backup remotes, or connect to a custom server. The project also documents how an outside operator can run a compatible BRC-100 storage service using the 1Sat command-line tooling. GitHub
The interesting part is not simply remote backup.
It is that storage can now have its own provider, capacity rules and payment mechanism while remaining underneath the normal wallet experience.
Local, Active and Backup Storage
The Yours Wallet model distinguishes three roles.
A new wallet can remain local-only, keeping its working data in browser storage.
A remote active server can instead become the wallet’s primary storage location, allowing devices using the same keys to synchronize against common wallet state.
Additional backup remotes can receive copies of that state for redundancy. GitHub
That makes storage choice more independent from the wallet application.
A user does not necessarily have to depend on one storage operator simply because they use Yours Wallet. A compatible server can be self-hosted, offered free to a community, or operated as a paid service.
The provider guide describes all three arrangements. GitHub
Storage Can Be Metered Without a Separate Subscription System
The paid-provider model is the more unusual part.
A storage operator can assign each user a free baseline capacity and then sell additional capacity in defined increments.
When a wallet operation would exceed the available allowance, the server responds with HTTP 507 — Insufficient Storage.
The wallet SDK can then request the provider’s account status, obtain the information needed for the next payment, construct a BRC-29 payment, broadcast it, wait for the server to recognize the resulting capacity credit, and retry the original operation. GitHub
The provider therefore does not need to build a separate checkout page, subscription account or conventional payment endpoint around the storage service.
Payment is connected directly to the resource being consumed.
The documentation describes the process as transparent after the user’s initial consent. If the wallet cannot make the required payment, it instead reports that the remote storage payment could not be completed. GitHub
This is a small example of a broader machine-service pattern: the application encounters a resource limit, pays for additional capacity and continues the original operation.
Reads and Writes Are Treated Differently
The metering model also distinguishes between retrieving existing wallet data and causing the remote service to store additional state.
The provider guide says reads remain free, while storage-writing operations are metered.
That means the service is not simply charging every time a wallet communicates with it. The billable resource is additional maintained storage capacity. GitHub
Only the active remote participates in the documented automatic 507 payment path. Backup remotes receive synchronized data without triggering that billing mechanism.
Custom remotes are also slightly different from providers listed in the wallet’s provider picker. Known providers expose account status so Yours Wallet can display live capacity and pricing information, while custom remotes can be entered directly and may handle billing separately. GitHub
That distinction keeps the architecture open without requiring every storage server to participate in exactly the same commercial model.
Anyone Can Operate the Server
The server side is exposed through the same broader 1Sat tooling.
The documented setup uses 1sat serve to run a BRC-100 wallet-storage server, with BRC-103 mutual authentication handling communication between the wallet and server.
An operator can disable accounts for personal use, enable accounts with free capacity for community hosting, or configure capacity units and pricing for paid storage. PostgreSQL is recommended in the provider guide for production use, while SQLite is the default local database. GitHub
Providers that want to appear directly in Yours Wallet’s picker can submit their server for inclusion. Pricing and capacity are then retrieved from the provider rather than hardcoded into the wallet. GitHub
That begins to make the storage layer look less like a backend belonging to one wallet company and more like a service boundary of its own.
The Provider Is Still Part of the Security Model
Independent operation does not automatically mean that every remote provider can be treated as untrusted.
A June issue that remains open in the Yours Wallet repository reported a concern in the underlying remote-storage transaction path: according to the report, a malicious active provider could substitute an outgoing transaction’s recipient output before signing. GitHub
The issue references an upstream ts-stack report that has since been deleted, and the available public record does not establish whether later wallet-toolbox changes have eliminated the condition. GitHub
That makes the appropriate boundary clear.
The current provider architecture demonstrates storage portability, self-hosting and metered service operation, but it should not yet be described as proving that an arbitrary active provider can be used without trust or security review.
For users choosing third-party storage, the provider remains part of the operational security environment unless and until the relevant trust boundaries are independently verified.
More Than Remote Backup
BSV TIMES covered Yours Wallet 5.1.0 in September primarily through its USB security and portable-recovery architecture.
Remote BRC-100 storage mattered there because it illustrated why recovering wallet keys and recovering complete wallet state are not always the same problem. BSV TIMES
The current provider model exposes another consequence of that distinction.
Once wallet state becomes important infrastructure, storage itself becomes a service that can be separated from the wallet application.
One user may keep it locally.
Another may run a private server.
A community may provide storage without charge.
A commercial operator may offer capacity and receive BRC-29 payments when a wallet needs more of it.
That is more interesting than adding another backup destination.
It shows one way a BRC-100 wallet can decompose into independently operated pieces while still presenting a coherent experience to the user.
The wallet remains the interface.
The storage provider maintains state.
Authentication connects them.
And, where required, payment for the infrastructure can happen as part of the service interaction rather than through a separate subscription workflow.
Developer context
Yours Wallet (@yoursxbt) is the public project identity for the open-source Yours Wallet repository. The current wallet is built around BRC-100 and uses components from the wider 1Sat and BSV wallet-toolbox ecosystem for wallet actions, remote synchronization and authenticated server communication. GitHub
The Yours organization also maintains or has published related projects including:
yours-wallet-provider- the Yours web frontend
pow20-miner- Yours smart-contract tooling
The public organization does not expose individual members, so I would keep the developer attribution at the project level here rather than assign this particular storage work to an individual without stronger commit-level evidence. GitHub
Source Links
Yours Wallet remote-storage security issue #315
BSV TIMES – Under the Surface
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.
Update — October 5, 2026
Leave a comment