A standard is an invitation,
not a throne.

BRC-100, ElectrumSVP, SPV, and the curious belief that an open system requires everyone to ask permission

Common foundations can support different routes.

There is a particular sort of revolutionary who tears down a gate, congratulates himself on liberating the road, and immediately begins selling permission to walk along it. In software, he usually calls this an ecosystem.

Bitcoin attracts this character with remarkable consistency. People discover a distributed system, praise its openness, and then become terribly anxious when someone distributes the work differently. They welcome experimentation until an experiment chooses a different interface. They celebrate competition provided it occurs inside their preferred architecture. They declare themselves enemies of central planning, then demand a planning meeting before anybody writes a wallet.

We should be able to do better than that.

BRC-100 is useful. ElectrumSVP is useful. Simplified Payment Verification is useful. Different arrangements of wallets, servers, indexes, proofs, applications and specialist services can be useful. There is no obligation to pretend that they solve identical problems, carry identical risks or perform equally well. There is, however, every reason to let people build them, compare them and discover what actually works.

The problem begins when a recommendation acquires the manners of a commandment.

A developer may say, “This is the interface my application supports.” A business may say, “These are the conditions under which we provide our service.” An engineer may say, “I think your design will fail, and here is the measurement that explains why.” All of those are legitimate positions. None confers ownership of the space in which everyone else is allowed to think.

My position is straightforward. Keep the underlying Bitcoin rules stable. Let applications compete above them. Publish standards that reduce friction. Make implementation choices explicit. Test claims against workloads that matter. If your architecture cannot cope with the business you hope to attract, improve it, narrow its promise, or accept the consequences. The world does not owe your database a quieter afternoon.

And please stop confusing decentralisation with a collective obligation to adopt the same shopping list.

1. Start by putting the names on the right things

The BRC-100 discussed here is the BSV wallet-to-application interface. It should not be confused with similarly numbered token projects elsewhere. Nor should every argument about wallets be turned into an argument about tokens. A number is a convenient label; it is a poor substitute for reading the specification.

The BRC-100 specification defines a vendor-neutral interface through which applications request wallet operations. Its methods cover transaction actions, output management, public keys, signatures, encryption and certificates, alongside network and wallet information. Examples include createAction, signAction, listOutputs, getPublicKey and proveCertificate. The interface also specifies request origins, permissions-related parameters and a binary calling convention. It is an agreement about communication across an application boundary, not a replacement for Bitcoin transaction validation.

That distinction immediately clears away a great deal of theatrical disagreement. An application interface is one layer. A wallet’s internal storage is another. Its way of finding transactions is another. The evidence it checks before accepting a payment is another. Its backup arrangements, deployment model and business obligations are others again.

These choices interact, but interaction is not identity.

A restaurant menu and a kitchen inventory system both concern dinner. It would still be a mistake to hold a conference on which one should replace the other. Much of the wallet debate has precisely this flavour, although the catering is generally worse.

The BRC-100 introductory site describes a common application-facing language while allowing wallets to differ in user experience, storage and services. It also warns developers to check actual implementation support and permissions behaviour. Those are sensible qualifications. An interface name does not make every implementation interchangeable in every circumstance.

ElectrumSVP, meanwhile, names a specific BSV desktop wallet. SPV names a verification approach. Asking whether we should use “BRC-100 or SPV” therefore needs clarification before it deserves an answer. One concerns how an application asks a wallet to do something; the other concerns how a client evaluates certain blockchain evidence. A design can involve both.

The same discipline applies to ElectrumSVP. A server-assisted wallet arrangement is not automatically incompatible with an application-facing wallet interface. Whether a particular combination works depends on implementation, network rules, supported operations and trust boundaries. It cannot be decided by arranging the acronyms into rival football teams.

Once these layers are separated, the interesting questions become available. Which service performs which job? Who pays for it? What can the client verify? What can a provider conceal? What happens when the provider disappears? How much state must move when the customer leaves?

Those questions are worth an engineer’s time. Tribal pronunciation exercises are not.

2. What a good standard buys us

I am not making an argument against standards. I am making an argument serious enough to deserve them.

A well-designed interface reduces the number of special arrangements people must negotiate before they can transact. If every application needs a different wallet integration, each new relationship brings additional engineering, testing, maintenance and security review. A common boundary can turn repeated invention into reusable work.

Consider a small business building a service that charges for individual pieces of information. Its developers should be able to concentrate on the information, the customer’s task and the commercial experience. They should not have to become experts in every wallet vendor’s private vocabulary before collecting a payment. An interoperable interface can make the business easier to launch and easier to move between suppliers.

There is also a benefit on the other side. A wallet developer can implement a documented contract and reach applications without negotiating a bespoke arrangement with each one. That creates room for competition in reliability, accessibility, security, support and design. Standardisation can therefore increase diversity where diversity is useful, by reducing accidental differences where they merely waste money.

This is the attractive case for BRC-100. It deserves to be made plainly, without wrapping it in a threat.

The strongest advertisement for a standard is a developer who adopts it because yesterday’s difficult integration becomes tomorrow’s routine operation. The weakest advertisement is a developer who explains that alternatives must be discouraged because otherwise people might choose them.

There is a difference between confidence and territorial anxiety. Good engineering rarely needs to disguise the latter as the former.

Suppose two wallets implement the same application interface. One might be designed for an individual who values a simple local experience. Another might serve a business that needs controlled access, operational records and integration with existing systems. A third might specialise in a constrained device. An interface can help these products meet applications without demanding that their internals become identical.

Whether each product fulfils its promises must still be tested. The standard does not personally answer the telephone when a customer loses access. It does not repair a corrupted backup or determine whether a permission prompt is intelligible. It cannot make a careless implementation careful by association.

That is why conformance and quality should be discussed separately. Conformance asks whether an implementation fulfils a specified contract. Quality asks a wider set of questions about how well it serves its users. A product can satisfy an interface and still be a poor product. Another can serve a specialised need well while choosing a different interface and accepting the integration cost.

There is nothing scandalous about this. Standards are instruments of coordination. Their value comes from what they enable, not from how effectively their supporters can make disagreement embarrassing.

Use the standard. Improve the documentation. Build the test suite. Make switching easier. These are productive activities. Announcing that everyone has already agreed is considerably less productive, especially when several of them have not.

3. The word “must” needs an address

Technical specifications need precise obligations. If an implementation claims to conform, certain behaviours must follow. Without that discipline, interoperability becomes a pleasant fiction maintained by people who have not yet tried connecting their products.

The important question is where the obligation applies.

“If you implement this interface, you must encode this field correctly” is an engineering requirement. “If you want to participate in this commercial service, you must meet these conditions” is a contractual requirement. “If you build anything on Bitcoin, you must adopt our preferred application architecture” is a much larger claim, and the first two do not establish it.

The argument often slips between these meanings so smoothly that its author appears not to notice. A rule within a voluntary standard becomes a rule over everyone who might have chosen something else. A compatibility requirement becomes a claim to jurisdiction. A useful document puts on a ceremonial hat.

No such promotion should occur without challenge.

There are legitimate reasons for a company to limit what it supports. Every interface has costs. Every additional compatibility path creates obligations. No application developer is required to support every experimental wallet, and no wallet vendor must accept every suggested extension. Freedom to build includes freedom to decline an integration.

It also includes freedom to compete with the person who declined it.

The distinction matters because an open market cannot be maintained through a rule that everyone must make everyone else’s product succeed. That would be collective dependency with a fashionable logo. Businesses can cooperate, publish interfaces, share libraries and form commercial relationships. They can also go their separate ways.

Nor does freedom from compulsory adoption imply freedom from criticism. If a developer rejects a mature interface without a good reason, others may reasonably question the expense. If a proprietary design makes exit difficult, customers should examine the consequences. If an alternative increases operational risk, that should be explained in detail.

Criticism is most useful when it names the mechanism. Show the additional round trips. Show the missing export format. Show the recovery failure. Show the cost of rebuilding the index. There is no need to declare a rival morally impure when a reproducible test will do.

A developer who wants adoption should persuade. A developer who wants interoperability should specify. A developer who wants exclusivity should admit that this is what is being requested.

The confusion is not a minor matter of tone. It changes the incentives of the entire conversation. Under persuasion, a standard earns use by reducing costs. Under compulsion, its supporters can spend their effort raising the cost of refusing it. Those are different businesses.

I prefer the first. It produces better software and considerably fewer sermons.

4. ElectrumSVP deserves an accurate description

ElectrumSVP is the BSV wallet at electrumsv.io, an independently maintained continuation of ElectrumSV. The project, the network and the documentation matter; a shared ancestor is not a licence to exchange one product’s claims for another’s.

The ElectrumSVP repository identifies the current release as 0.2.0 and lists SPV transaction and UTXO verification, BREAD verification and export, header verification and recovery, local proof-data handling, multiple accounts, multisignature support and coin control. Those are the maintainers’ stated capabilities, not a claim that I have independently audited the release or measured its performance.

The website describes a desktop wallet with control over keys, accounts and selected outpoints. That is a concrete product to examine, not an abstract villain summoned whenever somebody wishes to sell a different architecture. A wallet deserves criticism for what it actually does, not for what an unrelated project’s FAQ happens to say.

Its 0.2.0 release notes describe BREAD—Blockchain Referenced Evidence and Data—and explain that available Merkle-proof data can be read from the local SQLite database instead of repeatedly requested from servers. They also describe additional header-integrity checks and recovery, and JSON proof export. For unconfirmed transactions, the notes describe anchoring to a recent confirmed transaction with available proof data where possible, with the hop count reported.

That last distinction deserves more than a hurried adjective. Evidence connecting an unconfirmed transaction to a confirmed ancestor is not confirmation of the unconfirmed transaction itself. The account of an ancestry path and the account of a transaction’s inclusion answer different questions. We should preserve that distinction when comparing designs, rather than turning the word “verified” into a universal solvent.

Local evidence can also change where work happens. Reusing a proof already held by the wallet is different from asking a server to supply it again. That observation suggests useful tests: which objects are retained, when they become invalid or stale, what happens after a reorganisation, and how the wallet recovers when some expected evidence is unavailable. These are evaluation questions, not a declaration that I have run those tests or found a particular defect.

Likewise, evidence concerning one transaction does not by itself establish that a service returned every transaction relevant to a wallet. An inclusion claim, a completeness claim and a current-spendability claim should not be bundled together simply because a user interface has only enough room for one reassuring colour. Anyone comparing implementations should identify the exact evidence behind each claim.

The virtue of an open project is that such questions can become specific. Name the release, examine its source and documented behaviour, state the configuration, and test the workload. A benchmark about another wallet does not become an ElectrumSVP benchmark by changing the heading. Nor does a protocol family establish that every implementation has the same privacy properties, recovery behaviour or capacity.

There is room for ElectrumSVP, for its continued development, and for other BSV wallet arrangements. There is room for application interfaces that cooperate with them where somebody actually implements the connection. There is room for different evidence-delivery models. None of this requires pretending that a BRC-100 integration already exists in a particular wallet merely because integration would be desirable.

An architecture earns confidence by making its dependencies legible and surviving the tests that matter. It does not earn it by inheriting the reputation, limitations or website of a different product. The correct response to useful work is to examine it seriously—and then allow the next useful piece of work to compete.

5. SPV is a method, not a talisman

Section 8 of the Bitcoin white paper describes verification using block headers and a Merkle branch rather than requiring the user to process entire blocks. It also states the dependence on the network’s honest majority and discusses a weaker position when an attacker controls the network. The proposal should be read with those qualifications, not converted into a slogan promising that a small proof answers every possible question.

There is a discipline to asking what a proof proves.

A transaction’s inclusion in a particular block is one proposition. The acceptance of that block within the relevant proof-of-work chain is another. Whether a payment remains exposed to a conflicting spend is another. Whether a token’s application rules were followed is another. Whether the person presenting an invoice has a legal right to collect it is another still.

These propositions can be connected by a system. They should not be collapsed by vocabulary.

The ElectrumSVP release notes distinguish locally available proof data from evidence requested over the network. Neither that distinction nor an ancestry anchor should be inflated into a claim that every transaction has been confirmed or every possible conflict excluded. Verification has an object, a time and a set of assumptions; the label cannot do their work.

A receipt is valuable because it provides evidence of something definite. Its usefulness declines when it is advertised as evidence of everything.

For application designers, the practical task is to write down the acceptance policy. What must be supplied before a payment is treated as received? Which checks occur locally? Which services provide additional information? What happens if headers are stale, evidence is missing, a provider is unavailable or the chain view changes? How does the application represent uncertainty to the customer?

These questions should be answered before the attractive animation is commissioned.

A low-value interaction may rationally use different commercial safeguards from a high-value transfer. That is a business decision to justify, not a reason to redefine the underlying proof. The software should preserve the distinction between “we verified this evidence” and “we are willing to accept this residual risk.” Both can be legitimate statements. Combining them into “verified” deprives the user of useful information.

SPV also does not dictate a single discovery mechanism. The question of how a client obtains relevant transactions is distinct from the question of how it verifies supplied evidence. A sender may provide information directly. A specialist service may help locate it. A wallet may use an index. Different arrangements can be combined where their assumptions are compatible.

This is precisely why the argument should remain open. There are multiple tasks to allocate, and the allocation can change as workloads, tools and commercial requirements change. The base rules can remain stable while the service architecture improves.

We do not advance the discussion by awarding one acronym custody of the entire problem. We advance it by identifying the work and deciding where it is best done.

6. Proof-carrying payments and the work somebody still has to do

BEEF provides a useful example of a different emphasis in information delivery. BRC-62 specifies a transaction package that can include ancestry and Merkle paths, working back through unconfirmed dependencies to confirmed anchors. It assumes an independent source of block headers. This allows relevant evidence to travel with the transaction rather than requiring every recipient to reconstruct everything through a general-purpose search service. The format alone does not establish that an output has never subsequently been spent; the specification itself separates that issue from packaging and validation.

That is a promising direction to explore. It should be explored with the same honesty demanded of every other approach.

Moving information delivery to the transaction’s participants can reduce some kinds of repeated discovery. It may also introduce requirements for retention, exchange, repair and availability. Someone must have the evidence. Someone must supply it. Someone must handle the case in which a device was lost, an intermediary disappeared or an expected dependency was not retained.

Architecture does not abolish work. It assigns it.

This is an excellent reason to compare architectures carefully. It is a poor reason to declare one arrangement beyond comparison. A service that efficiently handles evidence for a particular business may be extremely valuable. Another business may prefer a different combination of storage and retrieval. The relevant question is whether each can fulfil its promises at an acceptable cost and risk.

Consider a merchant processing a large number of small purchases. The merchant may want predictable evidence packages and bounded validation costs. A business managing long-lived contractual records may care more about durable retrieval and reconstruction years later. A developer serving intermittent devices may prioritise recovery after long periods offline. Those requirements overlap, but they are not identical.

There may be a common interface across several such products. There need not be a single internal architecture.

We should also avoid an easy rhetorical trick: comparing one system’s complete operating burden with another system’s most attractive component. A proof format can be compact while its surrounding recovery service is expensive. An index can make queries fast while its maintenance consumes substantial resources. A local application can seem independent while relying on an irreplaceable external source for critical information.

The honest comparison includes the entire obligation, especially the parts that appear after something goes wrong.

A customer does not care that the elegant component worked beautifully while the omitted component made the money inaccessible. Customers have an unfortunate habit of evaluating the service they purchased rather than the diagram its designer intended them to admire.

There is room for direct exchange, specialist storage, indexing, proof services and combinations that have not yet been built. The point of an open system is to discover which combinations people value enough to support. We should be trying to make that discovery easier.

7. Decentralisation does not require a committee for every application

A distributed system does not acquire its value by making every participant perform the same task. Division of labour is not a regrettable impurity introduced by commerce. It is often the reason a system can serve more than its inventors.

Some businesses can specialise in infrastructure. Others can specialise in applications. Some users want detailed operational control. Others want a service that behaves predictably and can be replaced when it does not. A successful network can accommodate these differences without requiring a universal lifestyle.

The collective interpretation of decentralisation gets this backwards. It imagines that independence is achieved when everybody agrees on the same approved arrangement, and that dissent threatens the independence of the whole. This is a remarkably elaborate way to rediscover conformity.

The problem becomes especially visible when application developers treat their own convenience as a constitutional principle. A familiar tool is useful. A mature library is valuable. An existing integration represents real investment. None of these facts establishes that new entrants must organise their businesses around preserving the incumbent’s assumptions.

If your service depends on every other service limiting its ambitions, the dependency belongs in your business plan. It should not be smuggled into everyone else’s obligations.

My argument for a stable underlying Bitcoin protocol is an argument for predictability at the shared foundation. Businesses should not have to rebuild their assumptions whenever someone wants a different application design. That stability can support vigorous experimentation above the foundation. It does not require every application to look alike.

Think of a reliable system of measurement. Its usefulness does not depend on every workshop producing the same chair. A common measure allows different workshops to cooperate, compete and discover new uses. Confusing the measure with the furniture catalogue would defeat much of the purpose.

Application interfaces can provide additional shared measures. People may agree on them because they make cooperation easier. Others may propose alternatives or build a specialised arrangement. Each choice should be assessed at the level where it operates.

This does not mean consensus rules are optional. An application that produces an invalid transaction cannot demand acceptance because its designer has an independent spirit. Freedom above a protocol is freedom to construct within its valid capabilities, not freedom to make incompatible assertions about what the protocol accepts.

The boundary is therefore quite practical: respect the base rules, state the application rules, and let products compete. Do not rewrite the foundation to subsidise one application. Do not turn an application convention into a prohibition on another valid use of the foundation.

That arrangement leaves plenty of room for vigorous disagreement. It simply asks disagreement to do useful work.

An open system leaves room for different designs to meet the world.

8. Mandala, alternatives, and the right to try

The Mandala approach I have discussed belongs in this conversation as an alternative way of thinking about the arrangement of participants and services. It should be considered on its architecture and tested on its merits, alongside other proposals. Invoking its name does not establish that a present implementation has achieved a particular capacity, and I am not asking anyone to accept it on that basis.

The principle applies to my own preferences as much as to anyone else’s.

If I advocate an arrangement, I should explain what it does, why I think it will work and what evidence would change that assessment. If someone builds a different arrangement and serves customers well, the achievement does not become invalid because I would have drawn the diagram differently.

There is something rather embarrassing about demanding freedom for an idea and then treating the freedom of competing ideas as a procedural defect.

The menu of legitimate experiments is broad. A developer might choose a common wallet interface with specialist back-end services. Another might prioritise direct delivery of transaction evidence. Another might build an efficient query service for a defined customer population. Another might develop a local-first application with explicit recovery arrangements. Others may combine pieces in ways that are not obvious today.

These are categories of design choices, not endorsements of every product that uses the language. A design still needs a threat model, an operating model and an explanation of its limits. An experiment deserves the opportunity to produce evidence. It does not deserve a certificate of success before the evidence arrives.

That is also what I mean when I say these approaches can all be good. They are legitimate directions for engineering and commercial discovery. I do not mean that every implementation is equally secure, every deployment has the same capacity or every claim should be accepted without examination.

One design may win a particular market. Another may fail entirely. A third may supply a component that becomes more useful than the original product. People may discover that an apparently elegant abstraction hides expensive dependencies, or that an unfashionable service is remarkably efficient when operated properly.

We should want those discoveries.

Compulsory uniformity suppresses information. If everyone must use the same arrangement, we learn less about the alternatives. If a successful product cannot be challenged without a campaign about community loyalty, its weaknesses become expensive to discuss. That is bad for customers and eventually bad for the product itself.

Open experimentation has costs, including failed experiments. The alternative has costs too, including failures that persist because nobody was allowed to compete with them. One should be particularly suspicious when the people advocating uniformity send the second bill to someone else.

Let people try. Ask them to explain. Require honest claims. Then see what survives contact with customers.

9. Scale is not a popularity contest

A system does not become scalable because many people endorse it. It becomes scalable, for a specified workload, because its resources and architecture can sustain the required work while meeting the relevant service commitments.

This is less glamorous than declaring a movement. It has the advantage of being testable.

The first question is what is being counted. Transactions received, transactions validated, transactions stored, payments acknowledged and customer operations completed are different events. A service can count one quickly while delaying another indefinitely. If a benchmark omits the expensive step, the omission should be in the headline rather than the footnotes.

The second question is what the workload looks like. A quiet demonstration with a small history says little about a heavily used service with years of retained data. Uniformly random requests may conceal hot spots. A warm cache may conceal expensive misses. A test with no failures may conceal a recovery process that overwhelms the system precisely when customers need it most.

The third question is where the bill goes. An application can appear efficient because a provider absorbs work elsewhere. A server can appear cheap because its storage, bandwidth or support has been subsidised. A wallet can appear effortless because nobody measured the cost of reconstructing state after a failure.

There is nothing inherently wrong with outsourcing or subsidy. There is something wrong with mistaking either for proof that the underlying cost disappeared.

Suppose an application receives ten times as much business. Which costs rise approximately with that demand? Which rise faster? Does each new transaction trigger a bounded amount of local work, or an expanding search through unrelated history? Can a busy customer delay everyone else? Can the system shed load without corrupting its accounting? Can it explain a timeout without creating a duplicate payment?

Those are the questions that determine whether growth is a commercial opportunity or an elaborate method of self-destruction.

I want Bitcoin businesses to plan for substantial scale. That is a design ambition and a demand for evidence, not a claim that every implementation has already demonstrated every imaginable load. The ambition should make us more exacting about tests, not less.

If your system breaks when the underlying network is used more heavily, that is a limitation of your system to investigate. It does not automatically establish that the network must be restrained to protect your implementation. Other businesses may have made different investments and chosen different approaches.

The customer is not obliged to remain small so that your first design can remain correct.

There is a certain grandeur in insisting that a global system must preserve the comfort of a single database. There is rather less engineering in it.

10. A practical examination, without the incense

Here is how I would make the discussion useful. Take the rival arrangements seriously enough to test the same customer journey across them.

Begin with a new user. How is the wallet connected? What permissions are requested? Which identity information is exposed? Can the user distinguish signing a message from authorising a payment? What happens when permission is refused? A design that handles refusal badly has confused consent with a decorative screen.

Move to the first payment. Record what the sender supplies, what the recipient checks and what remains dependent on an external service. Separate the payment’s construction, transmission, acceptance and confirmation. Give each stage a clear status. If an application says “paid” while meaning “request queued,” fix the language before congratulating the interface.

Then remove something. Disconnect a service. Make an index stale. Delay a reply. Return an error after a request may already have succeeded. Restart the client. Repeat the operation. The system should either recover coherently or explain what is uncertain. Guessing more confidently is not recovery.

Next, increase history and traffic separately. A design may handle more simultaneous users but struggle with a larger retained history. Another may handle history well but suffer from a single busy account. Report both. Publish tail latency, failure rate and recovery behaviour, not just the most photogenic average.

Now change suppliers. Export what the user needs. Reconstruct the application elsewhere. Identify every element that cannot move, every dependency requiring the former provider’s cooperation and every condition that makes migration impractical. A promise of choice is much more persuasive after somebody has exercised it.

Finally, include the operational labour. How much expertise does the service require? What must be monitored? Which failures demand manual intervention? How do costs change when the people doing the work are paid a normal wage rather than thanked in a chat room?

This exercise could favour BRC-100 integrations in some respects, an ElectrumSVP-based service in others, a proof-carrying design in others, or a combination. The outcome should not be selected in advance.

There may also be no universal winner. A product serving a narrow commercial requirement can outperform a general arrangement on that requirement while being unsuitable elsewhere. That is ordinary specialisation. We should not apologise for discovering it.

The purpose of measurement is to replace vague superiority with bounded claims. “This arrangement meets these requirements under these conditions” is a useful conclusion. “We are the future” is usually the beginning of an investor presentation, and sometimes the end of a conversation about evidence.

Let the benchmark expose costs. Let the threat model expose assumptions. Let the migration test expose dependencies. That would be a refreshing change from asking whose supporters are more enthusiastic.

11. A standard earns its authority through exit

The ability to leave is one of the most revealing tests of an interoperability claim.

An interface may make joining easy while leaving remains difficult. That can happen for many reasons: missing records, incomplete exports, undocumented metadata, service-specific identities, inaccessible history or a recovery process that depends on the original provider. Some of these may be justified trade-offs. They should be visible before the customer discovers them during a crisis.

An open specification helps, but it does not automatically solve every problem surrounding the interface. A user can know how to make a request and still be unable to recover the state needed to make it elsewhere. A second provider can implement the same calls and still lack the information required to serve an existing account.

This is why a serious interoperability programme should include practical movement between implementations. Not a promise that migration is possible in principle, but a demonstration that a user can leave with usable information and continue the relevant activity.

The same expectation belongs on alternatives. A bespoke system does not become emancipating merely because it rejects the popular standard. It may create a narrower dependency with a smaller support team. The developer who describes every shared interface as tyranny should be especially careful not to replace it with a private arrangement from which nobody can escape.

Freedom is not measured by the number of standards you refuse. It is measured, in part, by the choices your users can actually exercise.

This gives advocates a constructive agenda. Document the boundaries. Publish conformance tests. Make permissions understandable. Explain what an export contains. Test recovery without the original service. State which claims concern the interface and which concern a particular product. Make the cost of switching low enough that customers stay because the service is good.

A standard that supports this kind of competition becomes stronger through use. Implementers can disagree about internals while meeting a common contract. Customers can compare providers. Failures can be diagnosed without treating every defect as a political attack on the specification.

That last point deserves emphasis. A bug in an implementation is not automatically a defect in the interface. A defect in the interface is not automatically a reason to abandon standardisation. A rival’s success is not automatically a threat to the network. Keeping these distinctions clear makes improvement possible.

The alternative is a culture in which every technical criticism becomes a loyalty test. Such cultures tend to produce impressive quantities of reassurance. They are less reliable at producing repairs.

If a standard is good, let it compete honestly. If its implementation is excellent, let users discover that they prefer it. An open door should be an asset, not an existential threat.

12. Responsibility does not disappear when the architecture is fashionable

There is a temptation to hear “let systems fail” as permission to be careless. That is not my argument.

A business that accepts responsibility for users’ money, records or access must take that responsibility seriously. It should describe risks accurately, maintain appropriate safeguards and meet its obligations. Open experimentation does not excuse misleading customers, losing their information or pretending an untested mechanism is production-ready.

The freedom to choose an architecture comes with responsibility for the choice.

If a product cannot support its promised workload, its operators should fix the problem, reduce the promise, arrange an orderly migration or stop accepting business they cannot serve. They should not demand that the rest of the system remain unused so that their own limitations remain invisible.

That is the sense in which the consequences belong to the designer and operator. It is not an invitation to abandon customers after the experiment becomes inconvenient. The right to build is not a right to externalise every cost of building badly.

Nor should a successful competitor be required to subsidise every unsuccessful architecture. Cooperation can be commercially sensible and sometimes necessary. It should not become a permanent obligation to protect an incumbent from evidence that its assumptions were wrong.

A distributed system can support shared rules and differentiated responsibility. Those are compatible ideas. The rules define what participants can rely on; responsibility attaches to the services people actually offer. When the boundary is clear, firms can innovate without making every failure a crisis of the entire protocol.

This is another reason to resist the rhetoric of compulsory adoption. It encourages everyone to treat a particular service arrangement as a collective asset whose reputation must be protected. Then failures become embarrassing, criticism becomes disloyal and repairs arrive disguised as public relations.

I would rather have an ordinary commercial conversation. What did you promise? What happened? What did you measure? What will you correct? What can the customer do meanwhile?

Those questions are sufficiently demanding without adding ceremonial language about community destiny.

The builders who deserve confidence are the ones who can answer them. They do not need to claim that their interface is the only morally acceptable way to participate. They need to show that their system works, that its limits are understood and that its users are treated honestly when those limits matter.

13. Build something that deserves to be chosen

So use BRC-100 if it helps you build a better service. Implement it carefully. Test it against the wallets and applications you intend to support. Make the case for adoption through lower costs, better experiences and credible interoperability.

Use ElectrumSVP-based services where the relevant implementation and its assumptions meet your needs. Be accurate about discovery, privacy, omissions and verification. Improve the service rather than insisting that its name ends the argument.

Use SPV with a precise understanding of the evidence being checked and the assumptions surrounding it. Explore transaction packages, direct exchange, specialist services and different ways to deliver the information a customer requires.

Consider Mandala and other arrangements. Develop something new if you believe you can do better. Explain it well enough that other people can criticise it intelligently. Accept that a clever diagram is the beginning of the work, not the conclusion.

All these choices belong in an open field of experimentation above stable underlying rules. None requires pretending that implementation details are trivial. They are where most of the difficult work lives.

The useful standard reduces the price of cooperation. The useful service bears a cost more efficiently than its customer could. The useful proof establishes a definite claim. The useful benchmark reveals a limit before the limit damages someone’s business.

There is ample work for everyone in that list. We do not need to add the office of Supreme Guardian of the Wallet Interface.

What we need is the confidence to let different systems meet the world. Some will thrive. Some will change. Some will discover, rather abruptly, that their design was suited to a demonstration and not a market. That discovery may be unpleasant, but it is information. Suppressing alternatives will not make the underlying limitation disappear.

Bitcoin should not be reduced to a support mechanism for the preferred tools of its earliest application developers. Its usefulness lies in what people can build and exchange, including things the current enthusiasts did not anticipate and may not particularly like.

Keep the foundation dependable. Make the interfaces clear. Let people specialise. Let customers choose. Measure the consequences honestly.

A standard should open a conversation between systems. It should not close the conversation about how systems may be built.

If yours is excellent, people will have reasons to use it. Give them those reasons. If it cannot scale, improve it. If someone else finds a better arrangement, learn from it or compete with it.

The world will not stop while your architecture catches its breath.