> For the complete documentation index, see [llms.txt](https://bsv.brc.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bsv.brc.dev/overlays/0183.md). # A Framework for Strict and Federated Overlays Ty Everett () ## 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](/overlays/0022.md) and [BRC-24](/overlays/0024.md), 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](/overlays/0022.md) submission, [BRC-24](/overlays/0024.md) lookup, BEEF transaction data, [BRC-64](/overlays/0064.md) history, [BRC-87](/overlays/0087.md) naming, and [BRC-88](/overlays/0088.md) SHIP/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](/transactions/0076.md), 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](/overlays/0136.md) 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](/overlays/0178.md) 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](/overlays/0101.md) 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 * [BRC-22: Overlay Network Data Synchronization](/overlays/0022.md) * [BRC-24: Overlay Network Lookup Services](/overlays/0024.md) * [BRC-62: Background Evaluation Extended Format (BEEF) Transactions](/transactions/0062.md) * [BRC-64: Overlay Network Transaction History Tracking](/overlays/0064.md) * [BRC-76: Graph Aware Sync Protocol (GASP)](/transactions/0076.md) * [BRC-81: Private Overlays with P2PKH Transactions](/overlays/0081.md) * [BRC-87: Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services](/overlays/0087.md) * [BRC-88: Overlay Services Synchronization Architecture](/overlays/0088.md) * [BRC-101: Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements](/overlays/0101.md) * [BRC-136: Block-Anchored Overlay Synchronization via Block-Aligned Sparse Merkle Trees (BASM)](/overlays/0136.md) * [BRC-178: Race-Settled Collection Markets for Overlay Lookups and Message Boxes](/overlays/0178.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://bsv.brc.dev/overlays/0183.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.