Background Evaluation Extended Format (BEEF) Transactions
The core proof-carrying transaction container used by current implementations.
Shared application state
Run an overlay service
Admit only protocol-valid transactions, expose focused lookups, discover peers, and keep topic state synchronized.
Recommended sequence
Build the boundaries in order
- 01
Accept provable transactions
Use BEEF-family envelopes so validation material travels with the transaction.
- 02
Separate admission from lookup
Define topic-manager rules and lookup-service query contracts independently.
- 03
Preserve and find state
Track relevant history and use predictable service names and discovery advertisements.
- 04
Reconcile peers
Synchronize topic state and compare block-anchored completeness signals.
Take the next step
Turn the map into a working plan
The working set
Standards in this path
Atomic BEEF Transactions
Adds a single subject transaction to a BEEF package for portable verification.
Overlay Network Data Synchronization
Defines the admission side of an overlay: which outputs belong to a topic.
Overlay Network Lookup Services
Defines the query side of an overlay: how clients find outputs and related state.
Overlay Network Transaction History Tracking
This document proposes a solution for tracking transaction histories within UTXO-based overlay networks by extending the BRC-22 submission result model to identify which spent topical coins should be retained for history and by extending BRC-24 lookup behavior to return BEEF that preserves source-transaction ancestry. This allows clients to traverse the life
Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
This document proposes standardized naming conventions for topic managers in BRC-22 and lookup services in BRC-24 to ensure clarity, interoperability, and uniformity across different implementations. The goal is to provide consistent and easily understandable names that facilitate efficient communication and integration between overlay network nodes and serv
Overlay Services Synchronization Architecture
This document outlines the Overlay Services Synchronization Architecture, detailing the Services Host Interconnect Protocol (SHIP) and Services Lookup Availability Protocol (SLAP). These protocols enable efficient peer discovery and data synchronization across UTXO-based overlay networks. This BRC defines the components, interactions, and responsibilities of
Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
Status This document is currently aspirational rather than descriptive of the interoperable behavior implemented by bsv-blockchain/ts-sdk . Current resolver and broadcaster implementations: expect concrete host base URLs in SHIP and SLAP advertisements, use https: in production, allow plain http: only for the SDK's local preset, and do not currently negotiat
Block-Anchored Overlay Synchronization via Block-Aligned Sparse Merkle Trees (BASM)
Adds block-anchored comparison points for overlay topic completeness.
This path is guidance, not a new protocol or maturity designation. Check each BRC’s upstream status note, normative language, and implementation section before shipping.
Editorial policy →