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.
Wallet Standards / Application Reliability
A wallet asking for permission introduces an unusual kind of delay into an application.
The software may be working perfectly. The network may be connected. Nothing may have failed.
The user simply has not answered yet.
BRC-219, the Wallet Permission Prompt Liveness Contract, defines how BSV wallet applications and wallets should handle that state.
The principle is straightforward: waiting for a human decision should not be treated like waiting for a server response.
When an interactive wallet receives a valid application request that requires user consent, it has two choices.
It can display a permission prompt and keep the original application request pending until the user grants or denies it.
Or, if the wallet cannot present the required prompt, it should immediately return a clear error.
What it should not do is accept the request, leave the application waiting, and fail to give the user any visible way to respond.
The corresponding rule for application developers is equally important.
An application should not decide that a wallet permission request has failed simply because a fixed number of seconds or minutes has passed.
A person may need time to read what an application is requesting. They may compare information, switch to another app, put down the device, or return to the decision later.
As long as the wallet remains connected and the permission request is still active, that delay can be normal behavior.
BRC-219 therefore separates permission liveness from ordinary network or transport failure.
If the wallet connection closes, a browser tab is destroyed, a process exits, or another genuine communication failure occurs, normal timeout and failure handling still applies.
But elapsed time alone is not supposed to turn an unanswered permission request into an application error.
The prompt has to remain visible
The standard also places responsibility clearly on the wallet.
If a wallet leaves a request pending because it is waiting for permission, the user must actually have access to the prompt.
On desktop, that may mean bringing the wallet window forward, displaying a modal, highlighting the application icon, or otherwise making it obvious that a decision is waiting.
On mobile, the wallet may use an in-app prompt, system notification, foregrounded activity, or another platform-appropriate mechanism.
The prompt also needs enough context for a meaningful decision, including which application is asking, what capability it wants, and whether the permission is temporary or continuing where that distinction applies.
A request that appears to hang while the wallet shows nothing is therefore not something every application should be expected to work around.
Under BRC-219, that is a wallet defect.
Mobile wallets get a specific continuity rule
Mobile operating systems make this problem more complicated because applications are constantly moving between foreground and background states.
BRC-219 explicitly addresses that.
Ordinary events such as switching applications, locking the screen, navigating within the wallet, changing orientation, or temporarily backgrounding the wallet should not cause a permission prompt to disappear while the corresponding application request remains unresolved.
When the wallet returns, it should restore the same prompt, present an equivalent one for the pending request, or return a clear cancellation or lifecycle error if the original request can no longer be represented safely.
The important rule is consistency:
the application should not remain waiting for a decision that the user no longer has any way to make.
Servers follow a different rule
The standard also distinguishes interactive wallets from wallets operating without a user interface.
A server-side wallet, daemon, CI system, or other non-interactive environment cannot sensibly wait for someone to answer a visual permission prompt.
Those wallets must instead make a deterministic decision.
If existing policy or previously granted authority allows the requested action, it can proceed.
If not, it should reject the request with a clear permission or policy error.
That keeps human permission waiting where it belongs: inside wallet environments that can actually ask a human.
No new wallet method is required
BRC-219 does not introduce a new BRC-100 wallet method or alter existing request and response structures.
It defines expected behavior around the methods that already require permission.
That makes the change subtle but important.
A common wallet interface is only truly interoperable if applications can also rely on common behavior around that interface. If one wallet abandons a permission request after 30 seconds, another leaves it pending indefinitely, and a third silently loses the prompt when a phone is backgrounded, application developers are forced to compensate for every wallet separately.
BRC-219 attempts to remove that uncertainty.
A connected request has a clearer meaning:
it succeeds, it returns an explicit error, or it is visibly waiting for the user.
That may not look like a major wallet feature. But dependable infrastructure often develops through agreements like this—defining what should happen not only when the user immediately clicks “Allow,” but also when ordinary human behavior interrupts the ideal software flow.
Update — September 9, 2026
Leave a comment