The decision a wallet
is waiting for.

A wallet that is waiting for its owner to read a permission request is doing useful work. A wallet that has lost the request and left the application waiting is broken. The two can look identical to a customer staring at a spinner.

That distinction belongs in the practical discussion of decentralisation in BSV. Competing wallet suppliers need room to choose their interfaces, storage arrangements and implementation techniques. Customers need a way to distinguish a deliberate pause from a defect. An interface standard can make that responsibility clearer without becoming a compulsory architecture for every participant.

BRC-219, Wallet Permission Prompt Liveness Contract, by Ty Everett, provides a useful starting point. The inspected specification ties a permission-dependent wait to a real decision path for the user. It distinguishes interactive wallets from services that cannot display a prompt, and ordinary deliberation from loss of the communication channel. Those distinctions have consequences for service quality, software testing and the allocation of blame.

Keep the common rules and the chosen service separate

The BSV protocol documentation separates transaction validity from an operator's local relay or mining policy. It also identifies implementation component boundaries as choices rather than protocol requirements. A business can therefore improve its service without treating every internal design decision as a change to the common validity rules.

I favour fixed base rules because they provide a dependable foundation for investment. Above that foundation, competing suppliers should be able to offer better products and accept responsibility for what they sell. A wallet interface can be worth adopting because it reduces integration costs or makes failures easier to diagnose. Its usefulness does not make its adoption mandatory across BSV.

My published research on governance, commitment and rule change distinguishes access to a system from authority over its rules. The application here is narrower: a supplier choosing to implement an interface should meet the commitments it makes through that interface. This article applies that institutional question to wallet operation; the paper does not provide a wallet benchmark or validate BRC-219.

Describe the wait before trying to shorten it

Consider a hypothetical procurement application asking a wallet to sign an instruction. The buyer opens the details, checks the amount against an invoice and switches to another application to confirm the supplier. Three minutes pass. A short permission timer would measure elapsed time, but would not establish that anything had failed.

Now consider the same application request when a wallet window never appears. The application remains connected, but the buyer has no place to approve or refuse. Waiting longer does not improve this situation. Reporting both cases as a slow user makes the wallet's defect disappear into the customer's statistics.

Under BRC-219, an interactive wallet requiring permission should either make the decision available or return a clear error when it cannot ask. A connected request should not expire solely because the user takes time. Grant and denial should resolve the original request rather than force the application to discover the decision through retries. The specification does not promise survival after a process dies or a channel is destroyed; transport failure remains a separate case.

The commercial distinction is straightforward. The buyer owns the decision. The wallet supplier owns the promised means of presenting and returning that decision. Neither responsibility is served by an unexplained spinner.

Ask what the permission covers

A visible prompt is only useful if the customer can understand its scope. A request for one signature and a request for continuing access to a class of operations create different exposures. Presenting them with the same vague approval text prevents a meaningful comparison.

BRC-43 illustrates the importance of scope in hierarchical-key applications. It defines protocol IDs, key IDs and security levels for derivation. For a given application, level 1 permission applies across counterparties within the protocol; level 2 makes grants counterparty-specific. Those are permissioning distinctions, not progressively stronger signature algorithms.

For a business adopting that arrangement, I would ask the wallet to explain the authority requested in terms the customer can recognise. Which application is asking? Which operation or relationship will it cover? Is the customer approving one operation or permitting later operations within an agreed scope? A customer should not need to reverse-engineer a derivation label to discover the answer.

The earlier articles on hierarchical-key compromise and signature scope address separate boundaries. Derivation organises keys; the signing construction determines what bytes are authenticated; permission handling governs whether the wallet carries out the requested operation. A well-presented prompt cannot repair a weak key-containment design, and a valid signature cannot prove that a human saw the correct request.

This separation allows independent implementations to compete honestly. One supplier may use a hardware-backed signing arrangement, another a different service architecture. Each still needs evidence for its own claims about approval, key protection and the result returned to the application. No single screen design settles all three.

Make interruption part of the product

Real customers switch applications, lock their phones and return after an interruption. A service tested only while every window stays in the foreground has avoided a large part of its actual operating environment.

BRC-219 treats ordinary mobile interruption differently from destruction of the request context. While the process and context survive, the wallet should preserve or restore the decision path, or report a clear lifecycle error when it cannot represent the original request safely. A non-interactive wallet must instead use existing authority or reject the request. It cannot sensibly wait for a user interface it does not possess.

For the procurement example, I would bind the displayed approval to the original instruction and its revision. If the application changes the amount while the buyer is away, the returning prompt must not silently authorise a different purchase. This is a proposed application requirement, not a claim that BRC-219 specifies an invoice format or solves every authorisation race.

A lost connection introduces another question: what outcome can the application establish? Absence of a response should not become evidence that no effect occurred. The recovery design needs to reconcile the original operation before submitting a potentially duplicate action. Permission liveness and transaction outcome reconciliation should be tested separately, even when a single interruption exposes both.

Measure the supplier's work separately from the buyer's time

A useful evaluation would record when the application submitted the request, when the wallet made the prompt available, when the user decided, and when the original request received its result. These intervals answer different questions. Combining them into one response-time average can penalise careful customers while concealing slow prompt presentation.

Suppose, purely as an illustration, one implementation presents the prompt in a tenth of a second and the buyer reads it for two minutes. Another loses the prompt for twenty seconds and then fails. A report concerned only with completed-request speed can make the second product look better by excluding its failures. The evaluation should retain the denominator: all requests admitted for the tested workload, their dispositions and unresolved outcomes.

I would compare independent implementations using the same cases: immediate approval, deliberate delay, refusal, backgrounding and return, unavailable prompt surface, channel loss and process termination. Add two simultaneous requests with different origins or amounts, and verify that each decision resolves the correct request. A repeated click should not become an accidental approval of the next item in a queue.

These are proposed tests, not measurements. They would need careful consent handling and a declared workload. Logging enough to reconstruct request identity does not require collecting private keys, full business documents or unnecessary personal details.

Scale the decision path without taking away the decision

A busy wallet may have many requests awaiting attention. Keeping them intelligible requires resources: pending-state storage, clear ordering, reliable return paths and support when something goes wrong. Scaling transaction processing does not remove this work at the application boundary.

Suppliers can compete over how they manage it. They can explain admission limits, separate unrelated requests and offer customers policies suited to repeated low-risk work. A bounded pre-authorisation can reduce repeated interruptions when the customer deliberately chooses it. It should not be introduced silently to make a throughput figure look better.

Likewise, declining work before accepting a request is different from accepting it and losing the decision path. An overloaded service needs an honest refusal or a correctly represented pending state. Marketing a failure as unlimited patience transfers the supplier's problem to the customer.

The decentralisation argument becomes concrete at this boundary. Fixed base rules let different firms build and improve their own BSV services. Voluntary standards give customers a language for comparing the promises. Independent implementations make those promises contestable. Responsibility means identifying who must repair a failure when the promised behaviour does not occur.

The customer should be free to take time over a consequential decision. The supplier should be able to show that the decision is genuinely available. That is a modest requirement, but it is far more useful than another claim that a spinning icon proves the system is working.