Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Network & Protocol

Not every overlay network is supposed to contain the same information.

A newly proposed BRC attempts to make that distinction explicit.

Proposed BRC-183, A Framework for Strict and Federated Overlays, introduces two terms for application-specific overlay networks that may use much of the same BSV infrastructure while expecting very different behavior from participating hosts.

The proposal remains open for review and is documentation-only.

It does not introduce a new wire format, change an existing overlay protocol or require current applications to behave differently.

Its purpose is simpler: give developers a shared vocabulary for describing what kind of agreement an overlay actually expects.

Strict overlays aim at common state

The first model is called a Strict Overlay.

In a strict overlay, the topical rules define a common state that participating hosts serving the same topic, rules version and scope are expected to derive.

If two hosts process the same confirmed blockchain history under the same rules, they should eventually agree on that state.

That does not mean every server must be synchronized at every instant.

One host may temporarily lag behind. Another may be offline. Two services may see different unconfirmed transactions for a period.

Those are synchronization differences.

The intended confirmed state remains common.

This model is appropriate when an application needs participants to agree on something like a registry, ownership state or another deterministically derived view of blockchain records.

The proposal is careful not to turn this into another consensus layer.

A strict overlay does not create a new consensus mechanism between overlay hosts. The underlying Bitcoin transactions remain governed by BSV Blockchain rules, while the overlay’s topical rules determine which records matter to that particular application and how they are interpreted.

Federated overlays can legitimately disagree

A Federated Overlay starts with a different assumption.

Hosts use a common protocol, but they are allowed to maintain different collections.

The proposal uses a music catalogue as a simple example.

An independent musician might operate a service containing only their own releases.

A record label might publish a larger catalogue containing many artists.

Another provider could curate something different again.

If an application asks those services what music they have available, the answers do not need to be identical.

Each host may return a valid contribution from the collection it actually maintains.

The difference is not a synchronization failure.

It is part of the design.

An application may query several federated hosts and combine their results, select among them or use each provider for a different purpose.

There may be no single complete catalogue that every participant is expected to reproduce.

Federated does not mean permissioned

The terminology could easily be misunderstood.

“Federated” here does not mean that a central organization approves who may participate, nor does it imply weaker transaction verification.

Individual records can still be independently verifiable against BSV Blockchain.

The federation refers to permitted differences in the collections being offered, not to trusting those hosts as authorities over the underlying transactions.

A host can also make stronger promises about its own collection.

For example, a service might claim that it carries the complete catalogue for one publisher. It would still be expected to satisfy that promise.

What the federated designation removes is the assumption that every other host must carry exactly the same catalogue.

Both can use the same infrastructure

This is where the distinction becomes useful architecturally.

Strict and federated overlays do not necessarily require separate technology stacks.

Both can use existing overlay components such as BRC-22 transaction submission, BRC-24 lookup services, BEEF transaction data, transaction-history tracking, standardized naming and service discovery.

They can also use the same SDKs, synchronization tools and validation libraries.

Even the Graph Aware Sync Protocol can be used in either model.

The difference lies in what the application expects the participants to synchronize.

In a strict overlay, synchronization tends toward one common application state.

In a federated overlay, peers can synchronize the records they intend to share without creating an obligation for every host to maintain the same collection.

That means the infrastructure can remain common while the data model changes.

Some existing BRCs naturally lean toward one model

The proposal also helps clarify how some existing overlay work should be interpreted.

BRC-136, which deals with block-anchored overlay synchronization and confirmed topic history, fits naturally with the strict model because its assumptions revolve around deterministic admission and common state.

BRC-178, which explores services competing to deliver the same canonical payload, is also naturally associated with situations where an equivalent answer is expected.

A federated discovery service has a different problem.

If several publishers are contributing different catalogues, the application may want all of those distinct answers rather than having providers race to supply one supposedly canonical result.

Neither design is better in the abstract.

They solve different application problems.

One system can use both

The proposal also avoids forcing an entire application into one category.

One host can serve both strict and federated topics.

A larger system could also combine the models.

For example, an application might discover several independent registries through a federated network while each individual registry internally operates as a strict overlay whose participating hosts agree on its state.

The useful question is therefore not:

Is this application strict or federated?

It is:

For this particular topic and scope, are participating hosts expected to converge on the same state, or are different collections intentionally valid?

That expectation should then be stated in the Topic Manager and lookup-service documentation.

Terminology can prevent architectural confusion

Proposed BRC-183 is unusual because it does not attempt to add another capability to the BSV stack.

It attempts to make existing architectural choices easier to describe.

That can still matter.

If one developer uses “overlay” to mean a network of replicated services that should all agree, while another uses the same word for a group of independent publishers intentionally serving different datasets, the two may disagree about synchronization, completeness and correctness even though both designs are valid.

The strict/federated terminology separates those assumptions.

Applications can continue sharing the same public BSV Blockchain foundation, transaction formats and overlay tooling while defining different expectations for the information maintained above that foundation.

The proposal remains open and may change through review. Its number and wording should therefore be treated as provisional until accepted.

But the distinction it introduces is already useful:

some overlay networks are designed to agree on the same state; others are designed to let independent participants contribute different valid collections.

Knowing which one an application intends is part of defining the application itself.

Source: Proposed BRC-183 — GitHub pull request

Update — September 25, 2026