The independence
a backup needs.

Three backup providers can leave a customer with one recovery dependency. The important question is what must still work when the wallet's usual means of access has disappeared.

In BSV, fixed base rules create room for competing wallets and recovery services. That competition becomes valuable when a customer can choose a different supplier without surrendering control of the entire arrangement. Counting service names or URLs gives an incomplete account of that choice. Recovery depends on how the shares, authentication methods and operators fit together.

BRC-154, Pluggable Backup Services for BRC-140 Share Vaults, by Brandon Cryderman / HandCash, specifies an optional service interface for storing and retrieving key shares. It gives a useful basis for examining the difference between a shared interface and independent recovery. The distinction matters to customers choosing a service and to suppliers accepting responsibility for its failures.

Keep recovery optional

The inspected BRC-154 profile requires ordinary wallet operation to remain possible without a backup service. A wallet may enroll multiple services, but recovery providers must not become required intermediaries for ordinary spending or use of the wallet-to-application interface. The specification concerns share storage and release, not spend-time co-signing.

That is a meaningful commercial boundary. A company can sell a useful recovery service without acquiring a compulsory role in every subsequent payment. Customers can decide whether the extra recovery path is worth its cost and exposure. Another supplier can implement the same interface, or offer a different recovery product whose assumptions are stated clearly.

I favour fixed base rules because they make that competition possible above a dependable foundation. Adopting this particular backup profile remains a voluntary application choice. Its requirements bind a claim to conform to the profile; they do not prescribe a backup architecture for all BSV users.

The BSV protocol documentation separates shared validity rules from local operating choices. My published research on governance and rule change likewise distinguishes admission from authority over rules. Here I apply that institutional question to a service relationship: what authority does buying recovery actually give the supplier? The paper does not test this backup profile.

Count shares and dependencies separately

BRC-154 describes a common two-of-three enrollment arrangement, while allowing other agreed thresholds. It requires local reconstruction and forbids sending the reconstructed root key to a service. Its wallet requirements also prohibit concentrating enough shares with one service to reach the recovery threshold. The profile requires wallets to keep offline BRC-140 and/or BRC-75 recovery available without services. A failure of online providers therefore needs to be distinguished from loss of every recovery route.

Consider a hypothetical customer who needs two distinct shares from three providers. If each provider can release its share independently, loss of one need not prevent recovery. If all three release paths require the same inaccessible email account, losing that account can block every provider release path. The threshold has not changed. The operating dependency has.

Different domain names do not establish different ownership, administration or infrastructure. A procurement review should therefore identify which failures are meant to be independent. Are two services operated by the same company? Can one administrator obtain both shares? Do they rely on the same authentication provider? Which assumptions remain true if a supplier changes its subcontractors?

This is a proposed review of the arrangement, not an allegation about any named service. It also cuts both ways. A common component may lower cost and simplify support. A customer can choose that tradeoff, but the resulting recovery claim should describe the shared exposure rather than conceal it behind a count of providers.

A recovery credential must survive the loss

BRC-154 explicitly rejects a circular recovery method: a key derived only from the protected root cannot be the sole credential for retrieving the shares needed to restore that root. Authentication must remain usable without possession of the secret being recovered.

This makes the role of hierarchical keys particularly clear. Deriving a separate key for the backup service may organise an existing wallet's relationships neatly. It does not create an independent route back into the wallet if the derived credential cannot be obtained after the root is lost. The recovery path must be evaluated from the customer's damaged state, not merely demonstrated while every original credential remains available.

The earlier article on hierarchical-key compromise considered containment when a key escapes. This is a different boundary: availability when the original key is absent. A signing algorithm can authenticate a request correctly and still be unsuitable as the only recovery method if producing that signature requires the missing secret.

Alternative authentication also creates responsibilities. A recovery method that is easy for the legitimate customer to regain may be easier for an impostor to abuse. The service needs to explain its identity checks, account-recovery process and response to suspected compromise. Strong encryption of stored shares does not answer those questions about authorised release.

Make supplier exit an ordinary event

BRC-154 provides lifecycle information for active, sunsetting and retired services. During sunset, retrieval remains available but new enrollment stops. Retirement ends retrieval. The profile includes a possible suggested successor URL, but a suggestion is not evidence that the successor has safely received a share or that the customer's recovery arrangement remains intact.

I would treat replacement as a separately verified operation. Before relying on a new service, the customer should be able to establish what was deposited, which authentication path will release it and whether the overall threshold remains recoverable. That verification must avoid exposing real secrets in logs or routine support tickets.

A business also needs a policy for old shares. A successful deletion response describes what an interface reported. It does not prove that every historical copy has disappeared. If replacement is intended to address compromise rather than ordinary provider retirement, simply moving the same share may leave the original exposure unchanged. Deciding whether to replace a share set or change the protected key requires the underlying sharing scheme and threat model; the service-interface profile alone does not settle it.

This is where responsibility becomes specific. The provider owns the accuracy of its lifecycle notices and release behaviour. The wallet owns the enrollment topology it constructs. The customer owns the choices made after receiving an intelligible account of the consequences. Calling the whole arrangement decentralised does not remove any of those jobs.

Recover the work as well as the key

The profile explicitly leaves wallet transaction-history and output-data synchronisation outside its scope. Reconstructing a root key therefore should not be advertised as proof that a replacement wallet has everything needed to resume the customer's work.

For a business, the practical recovery test should continue beyond obtaining the key. Can the replacement identify the relevant outputs and records? Can it distinguish completed payments from uncertain attempts? Can the customer resume the intended operations without accidentally repeating an action? Those questions require additional data and service behaviour, and should be described separately from the share-reconstruction result.

A useful proposed evaluation would start with a clean replacement environment and only the recovery material the product promises the customer will retain. It would test loss of one provider, loss of the usual authentication device, a provider entering sunset, an unavailable shared identity service and a malformed share. It would record both successful recovery and the dependencies that prevented it, alongside time, customer effort and cost.

No such experiment is reported here. In particular, the inspected specification describes a HandCash prototype whose earlier authentication exchange is not presented as a complete conforming implementation. A specification, a prototype and an independently verified service are different kinds of evidence.

BSV businesses should compete over recovery that customers can actually use. Stable base rules and voluntary interfaces let independent implementations improve that service. The test is whether the promised independence survives the failure it was bought to address.