A Shared Schedule for Reducing Free Blockchain Index Coverage

Abstract

This BRC proposes a shared schedule for reducing the transaction, address and script-based data that participating BSV mainnet indexers guarantee to provide free of charge. Providers may retain complete indexes and offer broader free or paid access. Transaction validity and ownership remain unchanged.

The schedule is anchored to block 1,000,000 and defines 27 increasingly restrictive stages. Time and transaction-volume thresholds determine eligibility for each stage. Each actual transition also requires a waiting period measured as 14 days of accepted-chain median time. Intermediate stages may be skipped. The first and final calendar gates occur six and 78 months after the anchor; activation can occur later.

Free coverage depends on progressively narrower filters. An existing address can lose its coverage at the first transition. Previously admitted outputs survive later funding-transaction restrictions only while their lookup identifier remains eligible.

From stage 13, transaction eligibility also requires the serialized transaction version to equal 1; every other version is excluded just as a failing TXID prefix is. This applies to free TXID lookup, address/script history, new ledger admissions and baseline spend accounting. Previously admitted outputs remain subject to grandfathering.

From stage 13, the baseline output list and reported amount may include outputs already spent, including spends known to the provider. These results do not establish current holdings or spendability.

The intended outcome is to move applications toward direct transaction delivery, retained wallet records and explicitly funded indexing services. Users who retain only a seed may face costly or unavailable recovery through their former service. The proposal does not guarantee individual customer notification, alternative-provider availability, migration readiness or economic savings.

Scope — a minimum free-service guarantee. This profile applies only to the free offerings a provider identifies as participating. Paid services, privately funded indexes and broader complimentary services are not subject to its contraction schedule unless the provider separately elects to apply that schedule to the offering. The progressively shrinking subset is a minimum coverage guarantee, not a ceiling on indexing or access: providers need not delete records, stop maintaining comprehensive indexes or refuse queries outside it. This is a proposed free-service transition profile, not an industry-wide restriction on BSV indexing infrastructure.

The objective is to end dependence on an indefinitely subsidized comprehensive public service, not to eliminate transaction discovery. Paid comprehensive indexing, direct transaction delivery, wallet-owned history and specialized overlays are legitimate long-term arrangements, including in combination. A smaller guarantee reduces contractual obligations; lower indexing workload and actual operating savings depend on implementation and funding. Migration also costs users and application operators time and resources.

What changes for users

An index is a service that helps find transactions and outputs. This proposal narrows the data a participating service promises to make available for free. It covers lookup by transaction ID, address and script hash, together with optional output-list and balance operations. A provider chooses which operations to offer under the profile.

Voluntary adoption is a provider decision. Customers of an adopting provider may need to change applications, preserve records, buy broader coverage or migrate. Adoption requires no separate customer opt-in, but receiving the filtered ledger requires explicit selection under section 8.2. Section 8.3 strongly recommends advance provider notice and an export opportunity while leaving providers final authority over their service commitments; no alternative provider is guaranteed.

The guarantees differ by operation:

Existing addresses and earlier payments

Existing addresses and scripts receive no permanent exemption. For example, an otherwise valid address beginning with 1K fails the stage-1 address filter. Its free address-ledger guarantee ends at that transition even if its outputs were admitted earlier. A missing guarantee does not mean a zero balance, lost ownership or an invalid transaction.

Grandfathering has a narrower meaning: previously admitted outputs remain in the accounting rules when a later prefix or version filter excludes their funding transactions, provided their address or script identifier still qualifies. A payment may therefore disappear from current free transaction history while its admitted output remains in the ledger. Retrieval/history caps likewise do not permit an offered ledger to drop old admitted outputs.

The change at stage 13

Through stage 12, an offered ledger accounts for every confirmed spend of an admitted output. From stage 13, its baseline accounts only for spends whose version is exactly 1 and whose transaction IDs pass the rule in force when they confirm. It omits a nonqualifying spend even when the provider has verified that spend elsewhere; additional validated debits belong in a separately described enhanced service.

The reason for changing the spend rule is monitoring cost. Even a small set of admitted outputs can be spent by transactions anywhere in the TXID space. Detecting every such spend requires whole-network spend observation, or an upstream service providing equivalent complete outpoint notifications. Narrowing funding admission alone does not remove that responsibility. From stage 13, a provider can instead maintain the ledger from a complete qualifying-TXID stream, potentially receiving and processing far less transaction data if filtering happens upstream. Section 8.1 still requires completeness and recovery for that stream; this BRC does not supply the transport or eliminate upstream processing costs.

Wallets choosing to keep admitted-output accounting accurate through this limited service must arrange for every spend of those outputs to confirm as version 1 with a TXID matching the spend block's filter, usually by grinding transaction candidates. This is why the spending TXID matters as well as the funding TXID. It is a condition of relying on the ledger, not a transaction-validity rule, and cannot be inferred from a positive total. Delayed, delegated or altered transactions can defeat that reliance; section 7.3 states the conditions and limitations. Applications needing authoritative unspentness should use validated wallet records and appropriate spend-status services, or a stronger indexing contract that covers every relevant spend.

Excluding even independently known nonqualifying spends keeps baseline results identical across providers using the same accepted chain and snapshot. It also means an up-to-date baseline can contain spent outputs. Waiting for synchronization need not correct the difference. The explanatory term filtered ledger total refers to this accounting result, which is neither an upper nor a lower bound on actual holdings.

Free archival lookup and reliable balance services are separate products: finding a transaction proves neither complete history nor current unspentness. Providers can offer retrieval/history under this profile while supplying balances under a stronger contract. The filtered ledger's usefulness is limited to its stated accounting rules; explicit selection does not turn it into a general wallet balance.

Existing API formats and field names may remain only subject to section 8.2's consumer safeguards: documentation or continued use alone cannot authorize replacing promised unspent outputs with the filtered ledger. Applications that rely on complete history or current unspentness may need different behavior or a different service.

Timing and communication

The schedule defines 27 possible restrictive stages, not 27 guaranteed gradual transitions for each user. An actual transition can skip stages. The volume thresholds measure transaction volume, not migration readiness.

For each actual transition, the sequence is:

Both calendar and volume gates pass → freeze the target stage → wait 14 days of chain median time → activate in the accepted block following the block that reaches the deadline.

This is an activation waiting period, called a notice round in the algorithm and reference data. It does not depend on provider announcements or guarantee 14 elapsed days of warning. Late adoption does not restart it, and a replacement chain can contain an already completed period when first observed. Separately, section 8.3 strongly recommends at least 30 elapsed days of advance provider notice before planned reductions of existing customer guarantees, with provider discretion to withdraw sooner. That recommendation does not change the common chain stage.

The technical rules below define the exact filters, accounting and recovery obligations. Appendix A contains the full schedule; Appendix B connects the migration responsibilities to implementation sources.

Terms used in this proposal

Motivation and rationale

Reliability, funding and responsibility

Applications need an explicit plan for retaining or recovering the records they depend on, including who funds that responsibility. Comprehensive transaction history accumulates as transactions accumulate. Address and script indexes add output records, spend state, query work, replication, bandwidth and recovery costs. An operator, sponsor, customer or another participant bears those costs even when a query is free.

The concern is indefinite reliance on coverage whose continued funding and responsibility have not been secured. Charging, sponsorship and cross-subsidy can support comprehensive services, including free products. The author considers those legitimate arrangements. This proposal does not establish that every free index is unsustainable or that every index's costs grow exponentially.

A seed restores signing authority. Recovering the information needed to use that authority also requires retained records or a service capable of reconstructing them. Those records can include outpoints, transaction bodies, derivation instructions, spend state and validation evidence. Applications built around previously available services can incur substantial development, migration and recovery costs when coverage changes. Those costs are part of this proposal's tradeoff.

Completeness is a separate trust question. An index can omit payments or spends, lag, or report incomplete amounts. An inclusion proof authenticates a returned transaction; it does not establish complete address history or current unspentness. Independent providers can improve resilience, but agreement does not prove the absence of correlated omissions. Direct delivery and retained, validated evidence reduce discovery dependencies while leaving chain, availability and conflict-detection responsibilities in place.

Why shared filters, and what they cost

The proposed mechanism is a common sequence of nested eligibility filters that becomes progressively harder to satisfy. Its interoperability benefit is a portable eligibility rule: an application can satisfy the applicable identifier and funding-TXID predicates once for a given stage, rather than targeting different eligibility rules at each participating provider offering that family. Retrieval remains subject to each provider's declared history scope and limits. It need not obtain a separate identifier allocation from each provider. A replacement provider can reconstruct the same admitted ledger from accepted history under the same rules. These properties can simplify provider substitution, comparison and shared feed tooling without registration, per-key allocation or a common customer database.

A provider might voluntarily participate to offer a recognizable minimum free tier, reuse filtering and recovery tooling, or give customers a common transition path while funding broader coverage separately. Those are proposed incentives, not evidence of adoption or a reason every provider should join. Shared rules do not share the bill or guarantee that a participating business will remain viable.

Ordinary pricing can fund an index, and quotas can constrain demand. Per-provider quotas remain useful, but an application's remaining allowance at one provider says nothing about its eligibility at another, and query limits alone need not reduce the data indexed or monitored. A shared subset provides a common coverage boundary that can also be used for upstream filtering. The particular prefixes are arbitrary; their value here comes from agreement on a public, testable rule, not from any inherent merit of the selected records. This profile prefers that portability and selective-processing opportunity when a provider wants to contract its minimum free guarantee. It does not establish that arbitrary subsets are generally fairer, cheaper or more useful than quotas, sponsorship or comprehensive paid access.

Providers may combine the profile with paid tiers, declared history limits and ordinary access limits. Different retrieval limits can still leave providers with different available archives; shared eligibility does not promise identical records, capacity or availability.

Grinding consumes resources without compensating the index provider. The author accepts that disadvantage as part of the transition. Later stages are intentionally impractical for ordinary legacy use, making direct delivery, retained records or paid indexing preferable in the author's assessment. This is a policy judgment, not a measured optimum or a prediction of future prices and search speeds.

Four different economic effects need to be distinguished:

• Contractual obligations: the minimum free coverage shrinks whether or not the provider changes its infrastructure.
• Indexing workload: an operator may maintain fewer indexed records and, after stage 12, monitor only qualifying spends. Receiving a complete filtered feed can reduce downstream bandwidth and processing; filtering locally after receiving every transaction does not save that inbound bandwidth. Upstream services still perform and fund the broader work needed to supply the feed.
• Operating savings: avoided storage, replication, processing and bandwidth costs depend on architecture, retained archives, feed prices and workload. A shared backing index for free and paid products may remain comprehensive. A smaller guaranteed subset does not imply proportional storage or total-cost savings.
• Migration costs: application changes, exports, backups, grinding, replacement services and recovery impose costs on users and operators. Lower costs for the free provider can shift work and expense elsewhere rather than reduce the total.

The profile supplies no fixed operating budget or hard traffic bound. Qualifying traffic can grow, many outputs can be batched into one qualifying transaction, and grandfathered ledgers still require state. Selective monitoring is the intended opportunity, not a measured saving or proof that this transition is the least costly option.

The intended endpoint is that essentially no ordinary use depends on this free product. A provider may then close it or offer paid access, subject to its service commitments. Version 1 retains fixed final filters and contains no mandatory shutdown stage. Providers may continue broader complimentary services or sell access to earlier stages or the whole keyspace. Sustainable comprehensive services remain a successful outcome.

Evidence and policy choices

BSV's SV Node storage guidance described approximately 12 TB of block data and 350 GB of chainstate in January 2024, with performance-sensitive UTXO storage distinct from cheaper block storage. The association's May 2024 report reported over 3.6 billion processed transactions. These are dated scale observations, not current explorer-index measurements or forecasts of savings. Historical records accumulate; UTXO-set size can rise or fall as outputs are created and spent.

Blockchair's June 2022 operator account described large-block transfer, duplicated explorer databases, disk/development costs and too little BSV API demand to cover them. Its later support response confirmed limiting full public BSV support on 2022-11-07. Node-version and database problems were also involved. That experience supports concern about service continuity; it establishes neither a universal technical ceiling nor an optimal transition mechanism.

The anchor, six-month initial runway, 78-month final calendar gate, 10% interval growth and volume milestones are proposed policy parameters. Raw transaction count relates directly to the number of full-index TXID entries, while byte size, output count, query load and hardware also affect cost. Generated traffic counts toward the volume gate but cannot advance the calendar gates. Neither gate measures customer readiness.

Review should assess the mechanism alongside its alternatives and user costs. Version 1 retains a deterministic baseline that can include known-spent outputs, with explicit consumer selection and provider transition recommendations in sections 8.2–8.3. The recommended 30-day provider period is a proposed policy parameter, not a measured optimum. Time and volume gates do not establish migration readiness or economic savings.

Migration and recovery

Applications can reduce discovery dependencies by receiving relevant transactions directly, preserving their records and proofs, and paying for services they still need. Purpose-built overlays maintain data for their topics; they still need storage, synchronization and recovery. Paid comprehensive indexes remain a legitimate choice for explorers, exchanges, researchers, auditors and historical recovery. Exchange security, accounting, liquidity and operational requirements remain separate responsibilities.

Before withdrawing a dependency, an application operator should inventory its transaction retrieval, history, proof and spend-status calls, identify who will supply each required function, and test the replacement. Existing open-source building blocks do not establish that a particular deployment has migrated. The pinned Toolbox defaults still include explorer-backed services; Appendix B documents those dependencies and the limits of the available implementation evidence.

The migration responsibilities are:

An owner returning with only a seed has no guaranteed free reconstruction outside the current keyspace. From stage 13, even an in-scope filtered ledger cannot establish actual unspentness. Backups, counterparties or historical providers may enable recovery, but this BRC cannot promise that a suitable provider exists, retains all needed records or offers an affordable price. Operators should facilitate exports and migration before withdrawal. Missed migration can make recovery more costly or unavailable through the former service without changing consensus ownership.

This proposal contracts only its defined free index families. Node validation, headers, transaction broadcast, proof acquisition, known-outpoint spend checks and double-spend handling remain necessary for relevant use cases. Archives, bulk historical block delivery and old-proof services may remain valuable and charge for their work; this BRC sets no retirement rules for them.

Specification

The numbered sections and Appendix A.1 define the profile. MUST, MUST NOT, SHOULD and MAY state requirements and recommendations for services voluntarily claiming conformance, including their conformance evidence. Guidance for owners and applications describes conditions for relying on a guarantee; it adds no transaction-validity or query-permission rule.

A provider MUST identify the free index families and operations it offers under this profile. Conformance means availability of the required data and fulfillment of its defined accounting guarantees. The profile defines coverage and accounting, while leaving wire formats, interface conventions, delivery methods, internal databases and commercial prices to providers. Section 8.2 collects the interface and documentation rules.

Free means the advertised scope is obtainable without paying for that query or purchasing a broader indexing entitlement. Providers MAY require authentication and publish reasonable access, rate and resource limits. They MUST disclose those limits and MUST NOT use them to conceal the effective absence of the claimed service. Paid priority, bulk delivery and broader coverage are separate offers. This profile supplies no unlimited-bandwidth commitment, arbitrary historical-proof entitlement or availability SLA.

1. Canonical keys and independent query families

The profile applies to BSV mainnet. MTP(B) is the median Unix timestamp of accepted block B and its ten immediate ancestors. H0 = 1,000,000 and T0 = MTP(H0) define the UTC anchor. Publication dates and forecasts do not supply T0. Before the accepted chain reaches H0, the profile is inactive and historical admission uses unrestricted stage 0.

The representations below define the coverage predicates. Providers may map native request identifiers to them internally, subject to section 8.2.

A P2PKH address MUST be a canonical, checksum-valid mainnet Base58Check encoding of version byte 0x00 and a 20-byte public-key HASH160. Its output script is exactly 76a914{20-byte public-key hash}88ac. The checksum is the first four bytes of double-SHA256 of version plus payload. Validate decoded length, version, checksum and canonical re-encoding; do not fold case or trim whitespace. Other script templates are outside the address family but may use the script-hash family.

The script coverage key is RIPEMD160(SHA256(S)), where S is the exact serialized locking-script byte string. This hashes the whole script, not a public-key hash extracted from it. Its canonical display is 40 hexadecimal characters in digest-byte order, most significant bit first, without byte reversal, 0x, padding, truncation or whitespace. All locking-script templates may use this family. A matching digest does not establish that its script can be spent or that a caller controls it.

Providers MUST apply this predicate to the script's coverage key, rather than apply the hexadecimal-7 rule directly to an unrelated native identifier. For h = SHA256(S), the coverage key is RIPEMD160(h) over the 32 digest bytes, not their hexadecimal text. Restore a reversed-SHA256 representation to digest-byte order first. These mappings need no script preimage from the caller. Other identifiers may use an established internal script mapping; a digest cannot simply be truncated or relabeled. Providers MUST establish and document the script/key relation for data claimed within coverage.

A TXID's canonical display is 64 lowercase hexadecimal characters without whitespace or 0x. Leading-bit tests use conventional big-endian display order, not a little-endian internal buffer. Native representations may be mapped internally.

leadingBitsMatch(validatedHex, repeatedDigit, requiredBits):
  t = lowercase(validatedHex)
  whole = requiredBits // 4
  partial = requiredBits % 4
  if t[0:whole] != repeatedDigit repeated whole times: return false
  if partial == 0: return true
  return (hexValue(t[whole]) >> (4-partial)) ==
         (hexValue(repeatedDigit) >> (4-partial))

txidMatches(txid, stage) = leadingBitsMatch(txid, "9", TXID_BITS[stage])
transactionMatches(tx, stage) =
  txidMatches(tx.txid, stage) AND (stage <= 12 OR tx.version == 1)
scriptHashMatches(h, stage) = leadingBitsMatch(h, "7", SCRIPT_BITS[stage])

Address and script-hash queries are independent alternatives: neither requires the other family's identifier predicate. Each also requires transactionMatches for the funding transaction for generalized history and admission. TXID lookup requires transactionMatches and returns the complete transaction, with no address or script redaction. A provider supporting only one family MUST NOT imply that it offers the others.

The script-hash family includes generalized public lookups exposed through raw-script queries or alternative identifiers. A change of representation does not exempt equivalent script-based discovery. Private wallet records, topical overlays and separately offered broader services retain their own contracts. A wallet's authenticated list of transactions received directly is outside this contraction profile.

From stage 13, providers MUST apply the exact tx.version == 1 condition together with the TXID-prefix predicate. tx.version is the version field decoded from the accepted serialized transaction, not this specification's version or an address version byte. Every other value, including values greater than 1, fails transaction eligibility even when the TXID prefix matches. Stages 0–12 impose no additional transaction-version restriction. This rule applies to coinbase transactions as well. Current retrieval/history uses the current stage; ledger admission and debits use the event stage as specified in section 7. It does not change consensus validity, the volume counter, or separately offered broader services.

2. Filters and search-work matching

Stage 0 permits all valid keys. Appendix A.1 specifies the exact identifier predicates and volume thresholds for stages 0–27. Address rules constrain a literal prefix and, where shown, an explicit set of characters at the next position. TXID and script-hash rules constrain leading bits toward repeated hexadecimal 9 and 7 respectively.

Let N(s) be the exact number of 20-byte public-key HASH160 values whose mainnet Base58Check addresses satisfy stage s. SCRIPT_BITS[s] is the smallest nonnegative integer b for which N(s) * 2^b >= 2^160. Under uniform-hash models, the resulting mean script search work is at least the address mean and less than twice as large. The table's bit counts are normative; exact N(s) counts are in the machine-readable schedule. Base58 characters are not treated as equiprobable.

Some stages tighten the address filter without changing the TXID-prefix filter; stage 13 adds the version condition even though its TXID bit count is unchanged. The final address prefix is 1ChickenNugget; the final TXID prefix is thirteen 9s. The final script rule requires 75 leading bits: eighteen 7 digits followed by 6 or 7. These search-work relationships do not imply equal CPU costs for key derivation, usable-script construction and valid-transaction generation.

3. Exact calendar and volume eligibility

Cumulative transaction volume is a transaction count, not a monetary amount or data size. V(B) counts non-coinbase transaction entries in the currently accepted chain from block H0+1 (1,000,001) through B, inclusive. Block H0 (1,000,000) contributes zero. Each non-coinbase entry contributes exactly one, regardless of transaction version, TXID prefix, inputs, outputs, byte size, transferred value, fees or eligibility for this profile's services. It is not a count of distinct identifiers in a provider's database. Coinbase transactions can qualify for queries and admission under the applicable rules but never increment this counter.

The counter includes transactions during the initial runway and every activation waiting period. It never resets at a stage transition, provider adoption or restart. Table thresholds are absolute totals since the anchor, not additional transactions required at each stage. Mempool transactions, rejected transactions and orphaned blocks contribute nothing. No additional confirmation-depth requirement applies: the accepted tip's transactions are included. On reorganization, remove contributions from removed blocks and add those from the replacement accepted branch; the total may decrease. If the anchor changes, section 5 requires recomputation.

For each accepted block B after the anchor:

V(H0) = 0
V(B) = V(B.parent) + numberOfNonCoinbaseTransactions(B)

Counters MUST NOT overflow or lose integer precision; the schedule requires more than 32 bits.

Providers MUST disclose the provenance and verification/trust assumptions of their counts. Headers alone do not establish cumulative transaction volume. Reliance on a count service is a dependency, not header-only verification. A version-1 or prefix-filtered transaction feed alone cannot establish this all-version, unfiltered count. Providers MUST obtain complete non-coinbase block counts across all versions and prefixes, directly or through a disclosed count-service dependency, and bind them to the accepted block hashes and ancestry. This separate counting dependency remains after stage 12; it does not require the ledger provider to receive every transaction body.

Set G = T0 + 6 calendar months and E = T0 + 78 calendar months, both added directly from T0 in UTC, preserving time of day and clamping to the target month's last day. Define:

w(i) = 11^(i-1) * 10^(26-i), for i = 1..26
W    = sum(w(i), i=1..26)
D    = E-G, in integer seconds
T(1) = G
T(s) = G + ceil(D * sum(w(i), i=1..s-1) / W), for s=2..27
candidate(B) = highest s with MTP(B) >= T(s) AND V(B) >= VOLUME[s],
               or 0 if none qualifies

The 26 post-runway intervals grow by approximately 10% after whole-second rounding. These are eligibility intervals, not empirical chain-growth estimates or guaranteed dwell times. Both gates must pass in the same accepted view. Insufficient volume can delay any stage indefinitely. A candidate is not an active stage: section 4 adds a fresh activation waiting period to each actual transition.

4. Activation waiting periods and following-block activation

A notice round is the algorithmic state for an activation waiting period. It freezes a target stage, accepted triggering block and deadline exactly 1,209,600 MTP seconds after that block's MTP. It starts automatically; publication, acknowledgment, provider participation and local timers are not preconditions. All conforming providers at the same accepted tip MUST derive the same round and historical stages.

The 14-day interval uses accepted-chain median time. It guarantees neither individual notification nor 14 elapsed wall-clock days of warning. Customer communication and provider-specific service changes are addressed separately below and in section 8.2.

Initialize stage 0 with no pending round at H0. Process accepted blocks parent before child:

stage(B)   = stage(B.parent)
pending(B) = pending(B.parent)

if pending(B) exists AND MTP(B.parent) >= pending(B).deadline
                     AND candidate(B.parent) >= pending(B).target:
  stage(B) = pending(B).target
  pending(B) = none

process transactions in B using stage(B)
compute V(B), MTP(B), and candidate(B)

if pending(B) is none AND candidate(B) > stage(B):
  pending(B) = {
    target: candidate(B),
    triggerHash: hash(B), triggerHeight: height(B),
    startedAt: MTP(B), deadline: MTP(B) + 1209600
  }

Every block uses one event stage, including for funding and spends. A notice trigger cannot apply a new rule to its own transactions. Even the block first reaching the notice deadline uses the old rule; its accepted child activates the frozen target. The event stage is stage(B), not candidate(B.parent).

Higher eligibility during a pending round MUST NOT silently change its target or shorten its waiting period. After activation, a higher candidate may start a new round in that same block, with its own fresh 14-day deadline. Direct jumps remain permitted: when a round starts with candidate 17 and active stage 0, it announces a direct contraction to 17. It need not activate the skipped intermediate stages. If target 5 was already frozen when candidate 27 becomes eligible, the algorithm first activates 5, then opens a new round for 27. This prevents a newly eligible, more restrictive rule from borrowing an older target's waiting period.

The calendar table's 78-month value remains the final eligibility gate. With all volume thresholds met on time, the earliest final activation is no earlier than E + 14 MTP days, in the accepted child of a block reaching that notice deadline. Volume delays, a preceding pending round and block arrival can extend that. Actual contraction times may differ substantially from the nominal table intervals.

For a verified accepted tip B, the network is in a notice round exactly when pending(B) exists. Its remaining chain time is max(0, pending(B).deadline - MTP(B)). Zero remaining seconds means that the deadline has been reached but activation still awaits the following accepted block; it does not close the round or apply the target to the deadline-reaching block. If activation opens a higher-target round in that same block, that new round is the pending state. An unknown or unverified chain view cannot establish that no round exists. These are algorithmic facts, not required status fields or projected wall-clock activation dates.

A reorganization MUST recompute rounds solely from the replacement accepted history. An orphaned trigger contributes no elapsed time to a different replacement round. Conversely, a replacement branch may already contain its trigger, deadline-reaching block and activation child when first observed: its prescribed stage is then already active. Providers MUST NOT restart or extend the round from local discovery, demand that anyone published a notice while that branch was unknown, or carry an orphaned round into the replacement history. For example, a replacement branch with a target-5 trigger at MTP 2035-04-20T00:00:00Z, deadline-reaching block at 2035-05-04T00:00:00Z and accepted child uses stage 5 in that child, even if first learned on May 10. Recovery gaps require unavailable responses under section 5, not a different stage or a new notice clock.

A provider joining the profile uses the common current stage and reconstructs admissions and spends using their historical stages. Entry does not start a separate waiting period. Providers MUST document adoption of the schedule and guarantees; separate customer commitments remain their responsibility. Reorganizations, restarts and late adoption create no retroactive publication obligation.

Consistent with section 8.3's transition recommendations, operators SHOULD contact users early, communicate each pending target and assess awareness using request-distribution logs. No announcement guarantees that dormant users receive a message. Intentional latency changes or other business policies MUST be disclosed and cannot justify an availability claim the provider does not deliver.

5. Accepted-chain authority and recovery retention

The currently accepted mainnet chain is the sole authority for H0, its MTP anchor, volume, notice rounds, stages, funding admission and spend-accounting effects. Rejected side branches have no effect. A reorganization MUST undo orphaned rounds and activations as well as transactions, then replay the replacement branch from a verified common ancestor. A replacement branch may lower the stage, remove a pending round, change which spend-accounting mode governed a transaction, or change funding admission. If H0 changes, recompute all dependent state; if the chain no longer reaches it, the profile is inactive. The same accepted chain produces the same algorithmic stage and event-stage history for late joiners and existing providers.

Caches and durable checkpoints MUST bind hashes, ancestry, anchor, volume, active stage, pending round, query watermarks and ledger/watch state coherently. Heights, highest-ever stages and observed orphaned events cannot substitute for accepted ancestry. A restart MUST verify its checkpoint and replay/backfill any missing history before complete claims. Audit records about rejected branches may remain but MUST NOT affect current results.

Providers SHOULD retain enough durable recovery information for at least 100 accepted descendants of the event that made it unnecessary for the active view. For retirement at accepted block R of height H, that recommendation protects it through H+99; H+100 is the earliest removal consistent with that minimum, subject to longer needs. Use the effective activation block for contraction, the event block for a spend-state replacement, and the accepted entry snapshot for a late adopter withdrawing existing coverage. For retrieval-cap retirement, use the accepted snapshot in which the record first leaves the promised retrieval scope. Record hashes and verify ancestry: orphaned blocks, side-branch heights, wall-clock time and cached highest-seen heights do not age the recommendation. If R is orphaned, re-establish any retirement decision from the replacement history.

The recommendation covers affected history records, previous output/admission/spend state, per-block undo material and coherent checkpoints. An equivalent compressed or recovery-only representation is sufficient. Operators MAY keep data indefinitely or choose a different retention policy based on their risk assessment; they MUST publish the chosen minimum, any departure from the recommended 100 blocks and its recovery implications. The analogy is the 100-block coinbase maturity constant, not a proof of finality or an estimate of reorganization probability. This is neither a compulsory purge at 100 blocks nor a promise that deeper reorganizations cannot occur.

Data still needed for live promised coverage MUST remain available, including grandfathered output state. Providers MUST NOT destroy the only usable data needed by an in-progress recovery while continuing to claim that recovery is supported. They are responsible for their own retained data or verified reconstruction arrangements. If a reorganization broadens coverage, reconstruct all newly required records within the declared retrieval/history scope and all admission/spend state needed by an offered ledger, including records predating the fork or H0. Restore the spend mode required by each historical block. Retrieval caps do not excuse missing ledger recovery state. A rollback from 13 to 12 can require backfilling spends previously outside the filtered feed. Until required state is verified, affected coverage is unavailable: use existing failure/availability mechanisms rather than assert a complete miss, zero balance or accurate UTXO state. Recovery has no specified duration or availability SLA.

6. Free query coverage and commercial extensions

For a generalized funding/history record in the current free view:

txidEligible(tx, s) = transactionMatches(tx, s)

addressRecordEligible(address, tx, vout, s) =
  tx.outputs[vout] pays exactly the canonical P2PKH script for address
  AND addressMatches(address, s) AND transactionMatches(tx, s)

scriptRecordEligible(scriptKey, tx, vout, s) =
  HASH160(tx.outputs[vout].lockingScript) == scriptKey
  AND scriptHashMatches(scriptKey, s) AND transactionMatches(tx, s)

Within the provider's declared retrieval/history scope, TXID lookup covers every qualifying accepted-chain transaction. Address/script-hash history covers every qualifying funding/output record. Without a declared cap, the scope is genesis through the declared indexed-through block. History here does not promise all incoming and outgoing activity. A valid hit's identifier and claimed accepted confirmation must be verified; a complete absence claim concerns only the declared scope and snapshot.

Providers MAY declare historical windows or record-count caps for retrieval/history. They MUST document the affected operations, retained range or selection rule, record-count unit, ordering and tie boundaries where relevant, and interaction with stage filtering, advancing snapshots and reorganizations. The newest 1,000 matching records and all matches within the newest 1,000 blocks are different promises. Records selected by the declared rule MUST remain freely obtainable. Missing ingestion inside the rule is a coverage failure, not an additional cap.

These caps do not limit an offered output/balance ledger. Providers MUST account for all admitted outputs while their query key remains eligible, including older grandfathered outputs whose funding transactions are no longer retrievable. Dropping old outputs or reporting only recent deposits cannot satisfy that guarantee. A provider unable to maintain the ledger may offer retrieval/history alone.

At activation, the guaranteed free keyspace contracts immediately. Outside it, this BRC guarantees no free result. Published coverage MUST make clear that failure to obtain an out-of-scope record does not establish global absence. Broader paid or complimentary services have their own eligibility, entitlement and completeness contracts. Physical retention or extra service does not extend this profile's minimum guarantees automatically.

Providers MAY retain a complete index, share one database across products, or retain broader stages. There is no deletion, data-layout or separate-database requirement. At stage 13, current retrieval/history also excludes records of earlier transactions whose version is not 1, even if their TXIDs still match. Section 7's grandfathering preserves admitted ledger state from such funding transactions while the query key remains eligible; providers may still return retained records under a separate historical or broader service.

7. Output lists and balances

Offering an output/balance operation under this profile is optional. Once a provider claims such an operation, it MUST make the canonical baseline available. A provider MAY claim retrieval/history conformance while offering a ledger only under a separate broader or enhanced contract, provided its claims distinguish those operations.

7.1. Admission, grandfathering and identifier scope

An output is admitted when its funding transaction and the relevant family's query key pass the event stage of the funding block. Pre-activation history uses stage 0. Historical admission uses that block's stage, not the stage when a provider discovers the output. Address admission does not imply script-hash admission or vice versa. Nonqualifying deposits add no covered value and do not affect other admitted outputs.

Admitted metadata MUST survive later funding-TXID restrictions while needed by the ledger: retain the outpoint, amount, exact script/key relation, funding confirmation/admission stage and applicable spend state. An output list MAY identify a grandfathered funding TXID outside current generalized retrieval coverage. Current filtered history can therefore be empty while the ledger has positive value.

The query key itself is not grandfathered. When its address or script hash fails the current filter, the free ledger promise ends. That is not a zero-balance claim. Active indexing/watch obligations may stop subject to the published recovery policy. A reorganization restoring eligibility requires verified historical reconstruction before the guarantee resumes. Nonqualifying spends do not permanently disqualify an address or script, and a later qualifying deposit needs no key reset.

7.2. Stages 0–12: complete confirmed-spend accounting

Providers offering output/balance operations MUST account for every accepted confirmed spend of an admitted output, irrespective of the spending TXID or transaction version. Complete outpoint notifications may suffice without retaining every spending body; a qualifying-TXID feed alone does not. A nonqualifying spend debits only the admitted outputs it consumes. Spending an ignored deposit does not debit the admitted ledger.

With complete admission and spend accounting through one accepted snapshot, the remaining outputs may be described as covered UTXOs and their integer-satoshi sum as a covered balance. Ignored deposits remain excluded, so this is not necessarily the key's total balance. Coinbase maturity and other spending restrictions are distinct from unspentness and MAY be reported separately.

7.3. Stages 13–27: the canonical filtered ledger

From stage 13, the baseline removes an admitted output only when its confirmed spending transaction has version exactly 1 and passes the TXID-prefix rule for the spend block. A nonqualifying spend is excluded from baseline accounting even if the provider has independently verified it. Extra validated debits belong in a separately described enhanced view. This makes baseline output membership and amount deterministic for a given family, key and accepted snapshot.

Providers MUST observe the complete qualifying-TXID stream and debit every admitted output consumed by an accepted qualifying spend, including grandfathered outputs. Use the spend block's event stage, never the current stage applied retrospectively. A historically qualifying debit remains a debit after later tightening. Every transaction in a block uses that block's stage, with dependencies processed in valid transaction order.

The baseline guarantees indexed TXOuts and their filtered ledger total. It can include spent outputs. The total can be below actual holdings because deposits were excluded, or above them because spends were excluded; it is neither a reliable upper nor lower bound. Providers MUST document this reduced guarantee and MUST NOT advertise it as unconditional current unspentness or proof of spendability. Existing API names are governed by section 8.2.

A baseline has no obligation to discover nonqualifying spends. An unconfirmed transaction is not a confirmed debit; expose mempool observations separately. Naming an input is insufficient without validated accepted-chain spend evidence.

The divergence can accumulate through repeated circulation. Suppose a key has an admitted 100-satoshi output. After stage 13, a nonqualifying transaction spends it back to the key as 99 satoshis, paying 1 satoshi in fees. The baseline retains the old 100 and ignores the new 99. A qualifying transaction spends the ignored output back to the key as 98 satoshis after another fee. The new output is admitted, but its input was never in the ledger: the total can now be 198 while only 98 is actually unspent. Repeating with a nonqualifying spend to 97 and a qualifying spend to 96 can produce a total of 294 while only 96 remains unspent. These illustrative amounts prescribe no viable fee rate or construction. No coins are created; the example shows why the total does not measure holdings, solvency or spending capacity.

For an owner to rely on this ledger as the actual unspent subset of its admitted outputs, every transaction spending an admitted output must confirm with version exactly 1 and a TXID qualifying at its spend block's stage from stage 13 onward. This includes pre-signed, delegated and delayed transactions. Funding admission likewise depends on the final confirmed funding TXID and, from stage 13, version exactly 1. A matching template, signed candidate or broadcast TXID cannot establish coverage if the accepted serialized transaction has a different, nonqualifying TXID. Transaction versions, scripts, signature-hash modes and signing/serialization workflows must be compatible with the intended reliance. These are conditions of coverage, not requirements for transaction validity or permission to query.

The SV Node 1.2.0 Chronicle release notes describe relaxed malleability restrictions for transaction versions greater than 1 and preserved restrictions for version 1. This is one reason the profile requires version = 1 from stage 13: relaxed restrictions for higher versions introduce additional ways a transaction's serialized bytes and TXID can change, undermining reliance on a ground prefix. Version 1 alone is not asserted to prevent every form of malleability. Parties need to evaluate the final-transaction requirement for their complete workflow. Equivalent payment intent or authorization does not replace the predicate or add monitoring obligations for indexers.

The second reason is delivery simplicity. BRC-80-style multicast addressing places the transaction version before the TXID prefix. Fixing the version to 1 lets providers express post-stage-12 transaction interest within one version namespace and narrow the prefix subscriptions as stages advance, rather than subscribing to the same prefixes across multiple version namespaces. This can simplify group membership and selective delivery; it does not establish deployed transport, stream completeness or measured savings. Appendix B.2 explains the remaining transport limits.

Owners cannot establish that every spend qualified from a positive filtered total. Before selecting outputs or treating an amount as holdings or solvency evidence, clients should establish actual spend status using their validated records or appropriate status checks. This is advisory client guidance, not an additional provider obligation or query condition. Targeting a narrower forthcoming filter or paying a higher fee may help a transaction qualify when confirmed; neither guarantees confirmation time.

The canonical baseline applies historical admissions, all confirmed spends in stages 0–12, and only qualifying-TXID confirmed spends in stages 13–27. Complete results for the same family, key and accepted snapshot MUST have identical membership and amount regardless of optional information held by providers. A provider MUST NOT silently substitute an enhanced result for the baseline it claims to offer.

An enhanced service MAY start with the same admissions and apply additional validated nonqualifying spends. Its published guarantee MUST distinguish it from the baseline and describe the extra observations and their completeness. It MUST NOT resurrect baseline debits or add ignored deposits while claiming the same admission coverage; broader admissions require a separate contract under section 6. Enhanced results can differ between providers. A known-spent output retained in a baseline remains an indexed TXOut, never an unspentness guarantee.

Partial extra observations do not establish complete unspentness. A service making that stronger claim must separately document and satisfy its stronger observation contract. Baseline comparisons require the same profile, family, key and snapshot; enhanced comparisons also require matching extra-observation contracts and evidence. For a promised consistent multi-part result, newly learned extra spends must not silently change later parts: preserve the original result or use the existing failure/retry mechanism.

7.4. Transitions, historical snapshots and reorganizations

Stage 13 changes the observation promise for every still-admitted output, including grandfathered outputs. Providers may stop the whole-network spend watch while maintaining the qualifying stream. Outputs admitted from any transaction version before stage 13 MUST remain subject to the same grandfathering and debit rules while the query key remains eligible. Debits established during stages 0–12 MUST remain debited, including spends by other transaction versions. New qualifying funding can still be admitted; ignored deposits remain excluded.

A ledger snapshot MUST be on the accepted chain and complete for its claimed admission and spend-observation scope. A missing qualifying-stream interval after stage 13 is a coverage gap, not permission to omit required spends. Backfill before claiming a complete filtered ledger. A stages-0–12 watch gap likewise prevents a verified covered balance. Missing data is unavailable, never a fabricated zero. Published guarantees MUST distinguish intentional stage-13 exclusions from ingestion failures.

Providers MAY offer older verified snapshots. For an as-of result, distinguish the current accepted tip B from the snapshot Q, which MUST be B or its accepted ancestor. The stage at B determines the key's current free eligibility; an older snapshot cannot restore an excluded key. The stage at Q determines the historical accounting guarantee. Admissions and required spends MUST be complete through Q, with no later effects included. Current coverage requires observations through the current tip.

A still-eligible key can have a covered balance as of block Q from stages 0–12 even when the current stage is 13 or later. That establishes unspentness only through Q. Snapshots from stages 13–27 retain the filtered guarantee. Existing delivery context or documentation MUST unambiguously associate historical results with their snapshot and distinguish them from current data. If delivery cannot do so, an old result cannot substitute for promised current availability. A reorganization removing Q invalidates its accepted-chain guarantee.

8. Availability conformance and service commitments

For each claimed family and operation, providers MUST make the required data freely available within its defined scope. TXID retrieval and history completeness are relative to declared caps. An offered output/balance ledger must maintain all admitted state and required spends, including grandfathering, the stage-13 boundary and rollback, independently of those caps. Required data cannot be silently omitted while claiming completeness. Coverage calculations and amounts MUST retain integer precision internally.

During an ingestion or recovery gap, affected data is unavailable until verified reconstruction. Providers MUST NOT advertise complete coverage or fabricate an empty result, zero amount or current-unspentness guarantee for that gap. Outside-scope data has no availability guarantee under this profile even when retained or commercially available. A provider MUST NOT advertise live conformance while permanently withholding required in-scope data. A policy guaranteeing no data for an advertised operation is withdrawal, not a resource cap.

8.1. Feed completeness and dependencies

For every claimed operation, providers MUST publish how they establish completeness. The contract MUST identify source roles, provenance and trust assumptions; accepted-chain/confirmation validation; transaction-version and filter coverage; continuity and gap detection; historical backfill and reorganization reconciliation; and the basis of completeness watermarks. It MUST distinguish locally verified complete blocks from a filtered source's assertion of completeness, or describe another method used. Dependencies can be replaced; documenting them promises neither a particular vendor nor a permanent endpoint.

A completeness watermark is an accepted block hash/height through which all required observations in the declared scope have been accounted for without a known gap. It is not simply the highest block seen, last matching confirmation, heartbeat or count of matches. A block with no qualifying transactions still needs a completeness basis. Silence, a header and a returned transaction's inclusion proof do not establish that no matches were omitted. Providers relying on a trusted filtered source MUST disclose that residual trust.

Coverage MUST include every accepted block and transaction version relevant to the claimed interval, including qualifying coinbase transactions. Historical replay MUST use historical event-stage filters and spend modes; a present narrower feed cannot establish completeness of an earlier broader interval. Stages 0–12 require admissions across all transaction versions and every spend of admitted outputs. Stages 13–27 require version-1 qualifying admissions and version-1 qualifying spends of admitted outputs, including outputs grandfathered from other funding versions. A version-1 feed can cover the post-stage-12 transaction scope, but cannot reconstruct earlier all-version intervals or satisfy a reorganization below stage 13 without the necessary broader backfill. Retrieval caps do not limit ledger completeness. Extra enhanced observations have a separately disclosed scope/watermark, and their gaps cannot silently alter or invalidate the baseline.

Providers MUST document detection of discontinuity or source failure, resumption/backfill, and reconciliation of source checkpoints with accepted block hashes after reorganization. No cryptographic omission-detection mechanism is supplied here: the contract must disclose dependence on correct upstream gap reporting. A known gap, unresolved fork identity or missing required interval forbids a complete claim beyond the last supported watermark. Return unavailable for an affected snapshot or an explicitly historical verified result under section 7.4. A gap wholly after a historical snapshot need not invalidate that earlier result.

These requirements do not restore whole-network spend monitoring after stage 12. An indexer may use processors, filtered feeds or another documented source arrangement whose upstream services perform broader processing. It must establish the promised scope under its disclosed assumptions, without independently retaining or scanning every nonqualifying transaction. Providers MUST document their completeness/watermark policy and known limitations.

8.2. Interfaces, documentation and withdrawal

Providers may retain existing APIs, identifiers and delivery formats subject to the consumer safeguard below. This BRC prescribes no particular endpoint, method, request parameter, response field, header, error code, pagination scheme, view selector, revision identifier, watermark API or machine-readable status interface. No provider's format defines conformance. Variables, classifications and JSON keys in the reference data describe calculations and decoded test state, not a wire contract. Script identifiers may be mapped as specified in section 1 without changing native encodings or adding scripts/coverage keys to responses.

Providers MUST obtain explicit consumer selection of a clearly identified filtered-ledger contract before delivering post-stage-12 baseline results. That contract MUST state that results can include known-spent outputs and do not establish current holdings or spendability. Documentation alone, continued use of an existing operation, or a provider's unilateral contract update is not selection. Existing field names may remain within the selected contract, but an operation previously promising unspentness MUST preserve that guarantee or report unavailable to consumers who have not selected the filtered contract, subject also to section 8.3. Providers MUST NOT advertise the filtered baseline as unconditional current unspentness. Clients may need different behavior, independent verification or a stronger service.

A provider MUST document its adoption of profile version 1, offered families and operations, schedule, retrieval/history limits, version-1-only transaction eligibility and reduced accounting after stage 12, enhanced services and recovery/completeness policies. Existing documentation and communication channels suffice. Per-response labels and new interfaces are not required; transition notices follow section 8.3. Service tiers, agreements or delivery context may distinguish baseline, enhanced and historical results, but MUST NOT substitute a different guarantee for the one advertised. Internal checkpoints and delivery consistency must support the actual promise.

Providers may use existing failure/retry mechanisms for unavailable data. Historical results must meet section 7.4's snapshot distinction. The absence of a prescribed response format does not permit false completeness, fabricated zeroes or unsupported current-unspentness claims.

Provider-specific closure, paid-only conversion, operation withdrawal and changes to retrieval/history caps remain provider decisions, subject to existing customer commitments and the recommendations in section 8.3. Providers MUST cease claiming guarantees they no longer deliver. These decisions do not alter the common stage or notice rounds. Adoption does not oblige perpetual service; while a provider claims the profile, its advertised scope must satisfy the applicable guarantees.

8.3. Provider transition recommendations

Providers are strongly encouraged to give customers ample opportunity to migrate. Before a planned reduction of an existing customer's coverage or accounting guarantee, providers SHOULD give at least 30 elapsed 24-hour days of advance notice through existing customer communication channels. This includes adoption, stage-driven reductions, ending complete spend accounting and excluding other transaction versions at stage 13, narrower retrieval/history caps, paid-only conversion and withdrawal. Notice SHOULD identify the affected operations and scope, earliest effective UTC date, resulting guarantees and costs, and export/migration instructions. Multiple future reductions MAY be announced together if each scope and earliest date is specified. Announcement does not guarantee individual receipt.

During that period, providers SHOULD preserve prior customer guarantees and offer export of relevant records they hold in a documented usable format, subject to authentication, privacy and disclosed resource controls. This recommendation does not call for reconstructing records outside the prior commitment or maintaining a universal archive. If a common stage activates earlier, providers SHOULD continue the prior guarantee as a separately described broader service until the announced date. When interruptions prevent service or exports, providers SHOULD extend the opportunity and communicate a revised date where practicable. Providers MUST NOT delay the common stage or label a broader result as its canonical baseline.

Providers retain final authority over the guarantees they offer. Commercial requirements, security concerns or operational constraints MAY justify shorter notice, earlier withdrawal or an earlier end to export access, subject to separate customer commitments. Departing from these recommendations does not by itself prevent conformance. Providers SHOULD promptly communicate the affected scope, effective date and available migration options; truthful availability claims and section 8.2's consumer-interface safeguards remain mandatory.

Historical explorer lookups (non-normative)

Providers are free to continue hosting historical address and transaction information, including records outside the current filtered keyspace. An explorer may retain its pre-adoption index, add records from the filtered subsets it supports, and continue displaying any retained record. Broader historical or current services retain their own terms under section 6. The examples below are illustrative; they introduce no required API, error format, archive or additional conformance condition. In this section, SHOULD expresses a strong recommendation only.

Historical and new transaction lookups

A person searches for a historical TXID and receives its retained record. After several stages, that same record may still be returned even though its TXID no longer meets the current prefix rule. Contraction does not require the explorer to hide it. Records retained from earlier filtered stages can likewise remain available as history.

For a new accepted-chain transaction, an explorer indexing only its retained history and supported filtered subsets returns the record when its TXID meets the applicable prefix rule (sufficient leading 9s and any partial-bit constraint), its version is exactly 1 if the current stage is 13 or later, it is within the advertised retrieval scope, and indexing is complete. If a completed search finds no record across retained history and any applicable supported filtered subset, the explorer can return:

ERROR — The TXID you are looking for was not found in this system, either because it is not present in the historical index or because it is not part of any filtered subset supported by this system.

This error describes the system's search scope, not proof that the transaction does not exist on chain. An ingestion or recovery gap still calls for an unavailable response under section 8.1 rather than a fabricated miss. Providers offering broader coverage may return additional records under that service's own contract.

Current and historical address lookups

A currently eligible address can show the latest data supported by the offered operation, identified by its indexed-through snapshot. From stage 13, a baseline filtered ledger still has section 7.3's reduced guarantee; current indexing does not make that result a complete unspent balance.

An address no longer tracked can instead show retained historical data with a prominent warning, for example:

This address expired from current filtered coverage as of [UTC date, activation block height/hash]. Showing retained historical data through [snapshot date/block]. Later activity may be missing.

Here, expired means that the address prefix ceased to qualify, not that the address became invalid or ownership changed. The exclusion date comes from the accepted activation block's MTP expressed in UTC, rather than the nominal schedule. If tracking continued under a broader service, show its actual data cutoff separately. Reorganizations can change the exclusion event or restore eligibility; the archive should reflect that accepted history. This broader archive does not restore the address's current free-profile eligibility. Historical results and amounts should identify their as-of snapshot, using the distinction explained in section 7.4, and should not be presented as current holdings.

Historical-data providers SHOULD continue offering lookup of retained pre-adoption address and transaction data and give ample notice, preferably following section 8.3's recommended period, if that facility is to be retired. Providers retain discretion over retention, pricing and retirement; this recommendation guarantees neither a complete archive nor perpetual free access.

Implementations and conformance evidence

No implementation of this contraction profile, measured saving or provider adoption is asserted by describing existing migration infrastructure. Reference implementations should calculate exact gates, notice rounds, all three identifier predicates and the stage-dependent transaction-version condition, admitted ledgers and spend modes, with coherent accepted-chain rollback and truthful responses.

The machine-readable schedule fixes stages, exact volume/bit values, transaction-version requirements, address-space counts and calendar weights. The conformance vectors exercise encoding boundaries, script HASH160 mapping, block-derived volume accumulation and reorganization recounting, calendar clamping, notice/deadline/following-block behavior, frozen targets, direct jumps, rejected/orphaned triggers, grandfathering, exact version eligibility, current-history exclusions, both spend modes and their reorganization boundary. Synthetic decoded effects are not signed mainnet transactions or block proofs; raw-hash predicate fixtures do not assert known spendable script preimages.

Run the standalone vector verifier with python3 opinions/media/0234/verify_vectors.py from the repository root. It checks the mathematical tables and synthetic examples using standard-library code with RIPEMD160 support; it does not contact the network or certify a deployed indexer.

A provider's implementation evidence MUST include same-tip stage agreement across independent starts, undo/replay of notice and ledger state, complete historical reconstruction when coverage expands, all-spend accounting through stage 12, version-1-only eligibility and qualifying-spend debits from stage 13, preservation of earlier all-version admissions/debits and replay across that boundary, truthful availability/accuracy claims, recovery gaps and the configured retention policy. Scalar stage calculation alone is not evidence of index-service conformance. Operators SHOULD exercise migration, exports, loss of a provider and restoration before withdrawing coverage.

Appendix A: Filters, schedule and expected search work

A.1. Normative filters and volume thresholds

This table is normative. Stage 0 permits all valid keys. Address brackets list explicit allowed characters at one position; the preceding text is literal and the remaining characters are unconstrained. Script-hash patterns display the leading-bit rule toward repeated 7. One bit admits [0-7], two bits [4-7], three bits [67], and four bits 7. TXID bits match repeated 9 in conventional display order. The transaction-version column is an additional condition on every TXID-filtered operation: “any” adds no version restriction to accepted transactions; 1 requires exact equality.

A.2. Informative calendar and search-work estimates

Activation requires both gates, a fresh 14-MTP-day waiting period, and the following accepted block. Gate and Interval below are approximate nominal months relative to T0, calculated as 6 + 72 times the exact post-runway cumulative weight fraction; eligibility dates themselves use section 3's calendar endpoints and integer-second formula. They are not activation times. Stage 0 has unrestricted keys and zero post-anchor volume. The first six months are a separate runway.

Patterns constrain only the prefix of a valid full key. Address ranges use ordered Base58 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz; hex ranges use hexadecimal order. The explicit address sets and bit counts in Appendix A.1 are authoritative; sections 2–4 define their calculation and activation.

Expected key trials assume uniform public-key HASH160 and counted valid Base58Check encodings. Expected script trials assume uniform script HASH160 with a usable script; expected TX trials assume independently generated valid transaction candidates, restricted to version 1 from stage 13. Changing the version does not supply an extra search factor; other versions simply cannot qualify at those stages. These are means, not work limits, runtime claims or evidence that every arbitrary script can be varied safely.

The final address mean is about 3.3249e22 candidate keys, script mean 2^75 = 37,778,931,862,957,161,709,568 candidate scripts, and TXID mean 2^52 = 4,503,599,627,370,496 valid transaction candidates. They are distinct operations. A transaction candidate may require re-signing. Qualifying script generation must preserve the intended spending conditions; a qualifying digest alone is not a spendable output.

An address or script can be ground once and reused while transaction candidates are varied. Do not multiply these columns as the cost of that staged strategy. A user needing both address and script-hash coverage for the same P2PKH output must satisfy both independent key predicates; the separate means do not estimate that combined search. Grinding/reuse/targeted traffic can invalidate uniform-traffic storage projections. Previously admitted outputs do not need their historical funding TXIDs changed; later spend observability follows the spend block's stage and the two-mode contract.

A.3. Parameter-selection note

The terminal strings are arbitrary and carry no cryptographic privilege. Repeated 9s and 7s are recognizable; Chicken Nugget is the name of the author's sister's kitten. The author states that no qualifying infrastructure was prepared in advance. These public predicates allocate no registrations or exclusive access to chosen participants. Their origin supplies no economic justification for the schedule; the policy tradeoffs are stated in the rationale.

Appendix B: Migration implementation references

These references describe migration building blocks and their limits; they do not certify an implementation of this contraction profile.

B.1. Transaction delivery, validation and recovery

The Bitcoin white paper, particularly sections 7 and 8, describes storage reclamation and verification with headers and Merkle branches, including dependence on honest network behavior and the need to handle invalidity alerts. The author favors SPV and direct exchange as a scalable end-user configuration. This BRC does not claim that inclusion proves current unspentness, that archival data becomes unnecessary to everyone, or that every business must run the same wallet implementation.

An implementer can build the following path from open specifications and source. These are distinct responsibilities, each of which needs operating resources:

1. Construct and deliver the relevant transaction. Use BRC-29 and BRC-42 where applicable. A BRC-100 sender constructs with createAction, preserves the transaction and remittance/derivation metadata, and delivers them to the recipient or its chosen durable inbox. A receiving wallet uses internalizeAction to validate and retain its relevant outputs. An offline recipient needs durable delivery and retry/reconciliation; future address scanning cannot be assumed to remain available.
2. Carry and validate evidence. BRC-62 BEEF, BRC-95 Atomic BEEF and BRC-67 describe transaction/ancestry/SPV handling. Preserve the bytes and required parents/proofs; verify identifiers, scripts, amounts and Merkle paths against the accepted header chain. Missing evidence must be obtained from the counterparty, retained store or an explicitly supported retrieval service. BEEF is not a promise that an arbitrary missing body can be recovered for free.
3. Broadcast and track the submitted transaction. Arcade's implemented Teranode integration submits transactions, follows network lifecycle events, registers tracked transactions for proof delivery and exposes status/callback interfaces. Submission acknowledgement is not confirmation or finality. Applications must reconcile later acceptance, rejection, conflicts, proofs and reorganization state.
4. Acquire and preserve proofs. Arcade's current API contract carries mined Merkle paths and chain/reorganization interfaces. Proof delivery is tied to tracked transactions and configured upstream Merkle Service availability. The Toolbox Arcade provider implementation validates returned paths against its chaintracker and falls through when tracked proof data is absent. A lifecycle store keyed by transactions it was asked to handle is distinct from a promise of universal historical TXID retrieval. Preserve received evidence so future arbitrary historical proof requests are unnecessary for ordinary recovery.
5. Track headers and accepted-chain changes. ChainTracks supplies bulk/live headers, validation and tip/reorganization interfaces. Header integrity, work, linkage, source trust and synchronization still require implementation. On a reorganization, invalidate orphaned confirmations/proofs, refresh evidence and reconcile transaction/output state. A stale header source cannot establish a current view merely because an old inclusion proof still hashes correctly.
6. Check and reconcile spend/conflict state. Known-outpoint UTXO/spend checks, broadcast conflict handling, double-spend detection/deconfliction and relevant notifications remain necessary. They are scoped to transactions and outputs the parties care about, not necessarily an all-address discovery database. Inclusion and token-lineage proofs do not establish current UTXO membership. Treat a missing response, lag or inconclusive rejection as unknown; do not free reservations or promise spendability without appropriate evidence.
7. Replicate and export wallet data independently of keys. BRC-38 defines portable per-user records, BRC-39 protects the file, and BRC-40 defines incremental storage synchronization. Toolbox storage code provides syncFromReader and updateBackups. Use complete, verified synchronization and consistent versioned backups. Replication can replicate deletion or corruption; it is not by itself an independent retained backup.
8. Restore with both authority and records. The wallet recovery guide separates root-key recovery, transaction/derivation records, product configuration and backup access. The portability implementation guide identifies real export/import helpers and limits, including consistency and provider compatibility. Restore into an independently controlled compatible store, reconcile proofs and spend state, and rehearse loss of the original device and provider. Neither a seed nor a BRC-39 file alone supplies both halves.

Purpose-built overlays receive transactions for their topics rather than discovering every payment on chain. The open Overlay Engine accepts submitted BEEF, applies topic admission and lookup rules and supports BRC-76 graph-aware synchronization; BRC-88 describes synchronization architecture. Operators still preserve relevant history, propagate spends/transitions and run their chosen storage and recovery processes. An overlay's topical index is not the universal free script-hash index this profile contracts.

Token protocols can require additional evidence: BRC-176 preserves token-specific parent bodies back to the applicable deploy/authority for BSV-21/1Color lineage. Ordinary Atomic BEEF's SPV-minimal omission rules are insufficient for that packet. Parties must retain the evidence required by the token protocol as well as ordinary Bitcoin validation data; a token-validity packet does not prove unspent status or global supply.

B.2. Implemented, deployed and planned capabilities

As of the research date, the pinned Toolbox, SDK, Overlay Engine, ChainTracks and Arcade sources implement these building blocks. A public July 2026 Storage–Arcade–Monitor integration report records a bounded mainnet run in which 29 transactions mined, received proofs and reached completed wallet-storage state, and also records later failed load attempts and corrective work. It establishes an exercised deployed path, not a throughput ceiling, universal wallet compatibility, successful recovery under every failure, or proof that all current dependencies have already migrated.

Current Toolbox service defaults still include explorer-backed raw transaction, script-hash history, proof and UTXO-status services. Configurability and open source do not erase those dependencies automatically. Deployments must inventory which operations rely on them, retain/deliver required records, and replace, self-operate or commercially fund necessary retrieval/status services before removing a fallback they still need. No particular vendor or endpoint is mandated by this BRC, and no present public endpoint is promised to remain free.

Conceptually, a future BRC-80-style delivery service could map a transaction version and TXID prefix to a multicast group or block of groups. For version-1 traffic, subscribing to the prefix selected by this profile would then express the corresponding delivery interest, rather than requiring each ledger provider to receive and discard the entire transaction stream. As the prefix narrows, the subscription could narrow with it. Providers sharing that interest could receive data over shared multicast distribution paths, reducing duplicate transmission on common links. BRC-83-style downstream proof completion could supply associated confirmation evidence. This is the post-stage-12 opportunity: consume qualifying funding transactions and qualifying spends, apply the ledger rules locally, and avoid whole-network spend monitoring. Savings depend on traffic distribution, subscription prices and actual transport deployment; they are not proportional guarantees. From stage 13, the profile's version-1 requirement confines ongoing transaction subscriptions to that version namespace. Earlier all-version history still needs broader sources for reconstruction or a reorganization below stage 13. Transaction delivery or inclusion proofs alone cannot establish stream completeness; accepted-chain reconciliation and gap recovery remain necessary under section 8.1.

BRC-83 describes hierarchical transaction/graph aggregation and downstream proof completion. BRC-80 describes version/TXID multicast subscription concepts. These are directions for further capacity and efficiency investment, not assertions that this exact profile's transport is already deployed. BRC-80's illustrative mapping carries 48 TXID bits; the final filter here needs 52, requiring broader-shard receipt and local filtering or a transport extension. Version/prefix subscription bindings, completeness, loss recovery and proof-distribution economics also need an actual binding. Planning can use implemented direct-delivery systems while treating those transport and completeness bindings as unfinished work.

References

• BRC-16: Pay to Public Key Hash
• BRC-29: Simple Authenticated BSV P2PKH Payment Protocol
• BRC-38: User Wallet Data Format
• BRC-39: User Wallet Data Format Encryption Extension
• BRC-40: User Wallet Data Synchronization
• BRC-42: BSV Key Derivation Scheme
• BRC-49: Users should never see an address
• BRC-62: BEEF Transactions
• BRC-67: Simplified Payment Verification
• BRC-76: Graph Aware Sync Protocol
• BRC-80: Improving on MLD for BSV Multicast Services
• BRC-83: Scalable Transaction Processing in the BSV Network
• BRC-88: Overlay Services Synchronization Architecture
• BRC-95: Atomic BEEF Transactions
• BRC-100: Unified Wallet-to-Application Interface
• BRC-125: PeerPay URI Scheme
• BRC-176: BSV-21 — Validity Proofs

External implementation references pin source revisions researched on 2026-10-20. A code revision, API document or integration report does not promise every deployment's current behavior. The historical operator evidence supports the stated cost concern without establishing a universal exponential growth law or guaranteed economic outcome.