BRC-183

A Framework for Strict and Federated Overlays

When people build networks that track and share Bitcoin transaction data, some expect every server to hold the exact same records and agree on one answer, while others expect servers to legitimately hold different, overlapping collections. Without a shared way to say which kind of network you are building, developers argue past each other or build sync and lookup logic that assumes the wrong guarantee. This standard names the two patterns so a protocol can say plainly which one it is.

Ty Everett24 Sept 2026changed 25 Sept 20267 min read

Reference for an AI

Everything an assistant needs to answer questions about BRC-183 accurately, including what it depends on.

Why: Overlay networks built on Bitcoin transaction data can either require all hosts to agree on one common state or allow hosts to hold different, legitimately non-identical collections, and without a name for each pattern, protocol authors and implementers end up assuming the wrong one.
What: BRC-183 is a definitional framework that names two overlay network models, Strict Overlays where hosts converge on common state, and Federated Overlays where hosts may hold different valid collections.
How: A topic's protocol documentation declares itself Strict or Federated, states the scope of the state or collection the term applies to, and its Lookup Service documentation clarifies whether answers from different hosts are meant to be identical or merely complementary.

What this lets you do

Label a topic as Strict or Federated so implementers know what to expect
Reason about whether lookup answers from different hosts should match or merely complement each other
Combine strict and federated components in one system, such as federated discovery over several strict registries
Avoid mistaking a race for identical bytes as proof that a query was answered completely or correctly

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

The specification

Read the original

Abstract

Overlay remains the general term for topic-oriented networks and services that interpret, track, exchange, and query Bitcoin transaction data under application-defined rules. Within that general category, this document names two models:

Strict Overlays, where the topical rules define a common state on which participating hosts are expected to agree.
Federated Overlays, where the topical rules permit hosts to maintain different, potentially overlapping collections and contribute different valid results.

The purpose is a shared vocabulary, without assuming that every overlay has the same replication, ordering, or lookup guarantees. Topical protocol rules and Topic Manager documentation should explicitly identify which model they describe.

Motivation

Two useful architectures are often discussed under the same name.

In one, every host follows the same rules to derive the same state from blockchain data. Missing a relevant transaction is something to reconcile. Comparing state commitments and competing to return the same answer are natural activities in that system.

In the other, hosts contribute different collections under a common protocol. An independent musician might host only their own albums, while a record label hosts a larger catalogue. When an application asks for songs for sale, both hosts can return valid, useful results without returning the same set. Their differences are part of the application model.

Scope

This is a framework and definitional document. It does not prescribe a new protocol, establish new wire formats, or change the requirements of existing BRCs. It does not attempt to settle the design of synchronization, completeness proofs, lookup schemas, payment markets, or facilitator negotiation.

The definitions describe a topic's intended behavior, without certifying implementations or automatically classifying existing topics.

Definitions

Overlay

An Overlay organizes application-relevant Bitcoin transactions, outputs, and associated data according to topical rules. In the UTXO-based architecture of BRC-22 and BRC-24, Topic Managers determine admission and lifecycle behavior, and Lookup Services answer questions about the resulting data.

The general term does not itself imply that every host stores every relevant record, that every lookup has one canonical answer, or that all data used by the application is public and on-chain.

An ordinary web endpoint is not automatically an overlay. In the music example, the overlay relationship comes from participants using a common topical protocol to interpret and exchange Bitcoin-backed records.

Strict Overlay

A Strict Overlay is an overlay whose topical rules define a common state that all conforming hosts serving the same topic, rules version, and scope are expected to agree upon at the same chain checkpoint.

The characteristic model is on-chain, deterministically ordered state: hosts apply the prescribed rules to blockchain data and converge on the same result. A host's personal catalogue preferences or local arrival order do not define a different, equally valid version of that common state.

“Agree” describes the intended state, not instantaneous synchronization. Hosts can lag, be offline, or temporarily observe different unconfirmed transactions. Such differences are matters for synchronization and the topic's own rules, rather than permission for permanently different state.

Common logical state does not require identical databases or imply byte-for-byte identical lookup responses. Those details belong to the topic and lookup specifications. Strictness also does not introduce a new consensus mechanism among overlay hosts.

Federated Overlay

A Federated Overlay is an overlay whose topical rules permit conforming hosts to maintain or expose different collections within a common protocol. Their lookup results may be complementary contributions rather than interchangeable copies of one answer.

Differences can reflect publisher coverage, subscriptions, curation, or other choices allowed by the topic. An application may query several hosts and combine or select their contributions. There need not be one complete network-wide catalogue or a single canonical response to a broad discovery query.

“Federated” describes permitted data diversity, not a requirement for permissioned membership or trusted operators. It does not weaken Bitcoin validation or topical validity rules. Different collections can contain individually verifiable on-chain records.

A host may still promise completeness for a particular collection. The federated designation does not excuse violating that promise; it simply does not imply a universal replication promise in the first place.

Using the Terms

Topical protocol rules and Topic Manager documentation adopting this framework should explicitly state Strict Overlay or Federated Overlay, and explain the state or collection to which the term applies. Associated Lookup Service documentation should make clear whether answers are intended to be equivalent or may differ by provider.

For example:

This topic is a Strict Overlay. Hosts serving the topic are expected to derive the same confirmed registry state under the topic's rules at a common chain checkpoint.

This topic is a Federated Overlay. Hosts may carry different publishers' music catalogues; lookup results describe the participating host's collection.

These are documentation examples, not a new metadata schema.

The distinction belongs to the topical protocol and its stated scope, not to a particular server, operator, or library. One host can serve both kinds of topic. A system can also combine them: for example, federated discovery over several independently strict registries. The guarantees of each component should be discussed separately.

Neither term is a quality ranking. Strict agreement is useful when an application needs common state; federated contributions are useful when legitimate participants have different datasets.

Relationship to Existing Work

Shared infrastructure

Both models can use BRC-22 submission, BRC-24 lookup, BEEF transaction data, BRC-64 history, BRC-87 naming, and BRC-88 [object Object]/SLAP discovery. They can share engines, SDKs, libraries, validation tools, and synchronization mechanisms without sharing every assumption about replication or query results.

In particular, the Graph Aware Sync Protocol (GASP), described in BRC-76, is compatible with both Strict and Federated Overlays. Peers can use it to synchronize the transaction data they intend to share; using the same synchronization mechanism does not require every host in a federated network to maintain the same collection.

A common schema or template can explain how to interpret a returned record in either model. It does not, by itself, require all hosts to return the same records. The design of such schemas is outside this document.

BRC-136: block-anchored synchronization

BRC-136 describes deterministic topic admission, block ordering, and commitments to confirmed topic history. Those assumptions fit the Strict Overlay model and provide a useful example of why the distinction matters.

Its topic-wide agreement model should not be assumed for hosts legitimately maintaining different federated catalogues. Conversely, declaring a topic strict does not require it to select BRC-136 as its synchronization mechanism.

BRC-178: race-settled collection markets

BRC-178 concerns hosts competing to deliver the same canonical payload. This is a natural direction for Strict Overlay lookups where the query defines an equivalent answer. It is a different problem from combining an artist's catalogue with a record label's catalogue, where different result hashes may represent legitimate contributions.

The distinction does not rule out paid federated services or racing to retrieve a particular replicated object within one. It identifies the assumption that needs to be stated: are hosts competing to supply the same answer, or contributing different answers?

A matching hash establishes agreement about bytes, not by itself that the intended query was answered completely or correctly. Similarly, a common state commitment does not automatically define a canonical lookup response. Establishing the expected answer, accepting a reference commitment, and evaluating completeness remain questions for the relevant topic, lookup, proof, and market specifications.

BRC-101: facilitators and capabilities

BRC-101 provides an extension direction for describing different facilitator and transport capabilities, including authentication and payment. A specialized collection market could be described through that framework in a separate specification.

The Strict/Federated distinction describes the data model; facilitator capabilities describe how participants interact. Neither implies the other. BRC-101 currently marks composite URI schemes as aspirational, so this document does not imply that current clients automatically negotiate them or allocate a new scheme.

Adoption

Topic authors can use these terms to make existing assumptions explicit. Substantive changes to a topic's behavior still belong in that topic's specification and normal versioning process. Calling a system strict does not make it synchronized, and calling it federated does not remove obligations it has already promised.

References

Was this helpful?