Data Infrastructure / Wallet Infrastructure

Applications built around blockchain history often rely on something that can appear almost invisible to the user: somebody maintains an index and answers questions about old transactions.

Enter an address, transaction ID or script hash into a service, and the relevant history appears. For wallet recovery, that availability can create an even deeper assumption—that possession of the private keys will always be enough to reconstruct what the wallet owns because some service will continue searching the full blockchain for it.

BRC-234 — A Shared Schedule for Reducing Free Blockchain Index Coverage, proposed by Ty Everett on October 21, questions whether that assumption can remain sustainable indefinitely.

The proposal does not call for blockchain history to disappear, require index providers to delete their full indexes, or change BSV Blockchain consensus rules. Instead, BRC-234 proposes a voluntary schedule under which participating index providers could progressively narrow the amount of historical TXID, address and script-hash coverage they guarantee to provide for free, while making those limits predictable to wallets, applications and users.

The underlying issue is economic as much as technical. Maintaining increasingly large, universally searchable historical indexes has a cost, and BRC-234 asks whether applications should continue designing themselves around the expectation that somebody else will absorb that cost indefinitely.

Private Keys Are Only One Part of Recovery

The proposal begins from a distinction that can easily be missed.

A private key establishes the authority to spend an output. It does not, by itself, tell a wallet which outputs exist.

A user restoring a wallet therefore needs more than the ability to derive a signing key. The wallet also needs to discover the relevant transactions and outputs associated with that key—or retain enough transaction information from earlier activity to know what should be spent.

Historically, applications can outsource much of that discovery by asking an index service for all transactions associated with an address or script and reconstructing the wallet from the result. That approach is convenient, but it also makes wallet recovery dependent on an indexing service continuing to maintain comprehensive historical search coverage.

Project Babbage summarized the concern more sharply when announcing BRC-234: too many applications operate under the assumption that private keys alone are sufficient for coin recovery.

BRC-234 attempts to make the other dependency visible.

Reducing the Free Guarantee, Not Banning Full Indexes

The distinction between indexing and guaranteed free indexing is central to the proposal.

BRC-234 defines what it describes as a minimum free-service guarantee. A provider following the schedule could still maintain a complete blockchain index, continue offering broader historical searches without charge, provide paid indexing, or serve businesses and applications that fund their own indexing infrastructure. Specialized services could likewise retain whatever history their users require.

None of those possibilities is prohibited.

What changes under the proposal is the assumption that every participating provider should indefinitely guarantee comprehensive historical TXID, address and script-hash queries as a free public service.

That makes BRC-234 less a proposal to remove data than a proposal to establish clear service boundaries around access to indexed data.

A Shared Contraction Schedule

Rather than allowing providers to reduce coverage unpredictably, BRC-234 proposes a common schedule.

The current draft defines 27 progressively more restrictive stages, anchored at block 1,000,000. Movement through those stages would depend on both calendar time and cumulative transaction-volume thresholds.

The first calendar eligibility point occurs six months after the anchor, while the final scheduled eligibility point extends to 78 months. Transaction volume also matters: if the specified cumulative volume has not been reached, a stage can be delayed, while the actual progression does not necessarily need to move mechanically through every intermediate stage.

The proposal also makes activation deterministic. When the conditions for a transition are met, the target is frozen, followed by a waiting period based on accepted-chain median time before activation on a subsequent accepted block.

The purpose is predictability.

Applications should be able to know in advance when a particular form of historical lookup may stop being part of the guaranteed free baseline rather than discover the change only when a recovery attempt fails.

Not All Transactions Are Treated the Same

The proposed schedule also distinguishes newer transaction formats as coverage narrows.

From stage 13, TXID-filtered operations under the proposed contract would require the accepted transaction version to equal version 1 in addition to satisfying the applicable TXID-prefix filter.

Older transactions are not thereby made invalid, nor does BRC-234 change whether they exist in blockchain history. The distinction concerns which transactions remain inside the provider’s guaranteed filtered-query service as that service contracts.

Providers offering broader indexing could continue supporting older formats independently.

Wallets Would Need to Preserve More Knowledge

The larger implication falls on applications and wallets.

If comprehensive historical searching cannot be assumed forever, software needs another way to know what belongs to the user. That can mean preserving transaction records when transactions occur, maintaining the evidence required for Simplified Payment Verification, keeping wallet state and derivation information, obtaining history from another service whose retention policy meets the application’s needs, or paying for broader archival and index access where that service has economic value.

BRC-234 does not prescribe one universal recovery architecture. Instead, it attempts to make continued dependence on indefinite free chain scanning an explicit design decision rather than an invisible default.

That difference matters.

A wallet that deliberately chooses a long-term archival provider understands its dependency. A wallet that assumes an address-history endpoint will always exist may not discover the dependency until years later, when recovery is actually required.

Accounting Guarantees Remain

The proposal is not simply a timetable for providers to return less information. It also defines accounting requirements intended to prevent a filtered ledger from silently losing track of outputs after they have been admitted.

The current proposal allows optional output and balance operations to account for every confirmed spend of admitted outputs through stage 12.

From stage 13 onward, the baseline accounts only for qualifying TXID spends, while a provider may retain known-spent outputs in order to avoid presenting obsolete holdings or spendability information.

The proposal also addresses what it calls funding-TXID grandfathering.

Applications that need stronger assurance about whether an output has been spent may require enhanced services rather than relying solely on the progressively narrower free baseline. That again separates basic availability from stronger commercial or application-specific guarantees.

Existing Promises Cannot Quietly Disappear

BRC-234 also includes consumer safeguards.

A provider should not move an existing user into the proposed filtered-ledger model merely because the provider has adopted the BRC. According to the draft, an application or user would need to opt into a clearly identified filtered-ledger contract before receiving the later-stage baseline service.

If a service previously promised stronger spend-status guarantees, those promises must either be preserved or the provider must clearly explain that the customer is moving to a different service model.

The proposal does not specify a particular API or user-interface design for obtaining that consent. Its concern is that the change should not happen invisibly.

Providers Can Still Leave the Schedule

Participation itself is voluntary.

The proposal says providers should retain the ability to withdraw for commercial, operational or security reasons. BRC-234 currently recommends at least 30 days of notice, together with usable exports and preservation of prior guarantees where appropriate.

That reinforces what the proposal is—and what it is not.

It is a coordination framework among participating service providers, not a consensus rule compelling every blockchain-indexing service to behave identically.

Historical Explorers Can Continue

BRC-234 explicitly separates the proposed free-service contraction from historical-explorer use.

A provider can continue allowing lookups for transactions that fall outside its current wallet or application filtering guarantees. The proposal recommends continued pre-adoption historical lookup and adequate retirement notice rather than assuming that every old transaction must suddenly become inaccessible.

In other words, a transaction falling outside a future guaranteed free wallet-index service does not mean that the transaction has disappeared from BSV Blockchain. It means the responsibility for locating and serving that history may move elsewhere.

That distinction is particularly important for users.

Blockchain permanence and free searchable indexing are not the same service.

The Economics Behind the Proposal

The rationale section of BRC-234 describes the proposed shared schedule partly as a coordination mechanism.

If one provider reduces costly free indexing while every competitor continues providing it without charge, users can simply move to another provider and the industry-wide incentive to change remains weak. A common voluntary timetable reduces that coordination problem.

At the same time, the draft is careful not to claim proven savings. Provider adoption, measured operational savings, migration readiness and deployment of future transport concepts are not established by the proposal.

The included verifier checks the schedule calculations and synthetic fixtures; it does not prove that the economic assumptions are correct or that service providers will actually adopt the model.

That limitation is important because BRC-234 is presently an argument about how infrastructure could evolve, not evidence that the transition has begun.

What Changes for Recovery

The most useful way to understand BRC-234 may be through a recovery scenario.

Imagine a user returns years later with the correct private keys.

Under a traditional full-index assumption, the wallet can hand derived identifiers to a public indexing service and ask:

What transactions belong to these keys?

The service searches years of blockchain history and returns the answer.

BRC-234 questions whether application developers should assume that such a comprehensive query will always be available freely.

An alternative wallet architecture preserves the information needed for recovery closer to the transaction itself. The wallet retains records of what it received and the relevant transaction evidence, counterparties pass transaction data directly, backups preserve wallet state rather than only a seed phrase, and specialized indexes remain available where historical discovery itself is the service being purchased.

That is a considerably different recovery model.

Private keys remain indispensable, but the information describing what those keys control also becomes something worth preserving.

A Broader SPV Direction

The proposal therefore sits alongside a wider architectural discussion occurring around BSV Blockchain.

Simplified Payment Verification assumes that users can receive transaction information and proofs directly rather than independently reconstructing every payment relationship from a universal blockchain scan.

BEEF and related transaction-proof formats similarly make transaction evidence portable between applications, while wallet-storage work increasingly recognizes that a wallet contains useful state beyond a mnemonic.

BRC-234 approaches the same direction from another side: the economic sustainability of the infrastructure that has historically made full-chain discovery easy.

If free universal indexing becomes less comprehensive, applications have a stronger incentive to retain and exchange the specific transaction information they actually need.

That does not eliminate indexing; it changes what indexing is expected to provide by default.

Still a Proposal

BRC-234 is currently open as Pull Request #348 in the BSV Blockchain BRC repository and has been marked ready for review.

The proposal establishes no provider adoption, requires no current index service to follow its schedule, removes no blockchain data and changes no consensus rule. Nor does the PR establish that its proposed economics or timetable will ultimately be accepted.

Those boundaries matter because the proposal deliberately discusses a future reduction in something users may currently take for granted.

For now, it is a proposed framework for making that transition predictable if service providers eventually decide that unlimited free historical indexing is no longer sustainable.

Developer Context

BRC-234 was proposed by Ty Everett.

Everett has authored and contributed to numerous BRC specifications around wallet infrastructure, overlays, payments and application permissions, including work associated with:

• BRC-26 — Universal Hash Resolution Protocol
• BRC-29 — Simple Authenticated BSV P2PKH Payment Protocol
• BRC-73 — Group Permissions for App Access
• BRC-100 — Unified Wallet-to-Application Interface
• BRC-184 — Optional Metadata Registries and Their Stewardship

Source Links

BRC-234 — Pull Request #348

Project Babbage — BRC-234 Announcement

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 21, 2026