BSV · Overlay Services
Why, what, and how.
A reason, a definition, and an analogy of five landmarks for how Bitcoin transactions get indexed, found, and kept in step.
Why
Why overlay services exist
A scaled BSV blockchain handles too many transactions to query directly. Block explorers can't keep up; even pool-side indexes can't index everything every app might want to ask about. Instead, the network grows specialized indexes, each one focused on a specific category of transactions, run by whoever cares about that category. Those specialized indexes are overlay services.
What
What is an overlay service?
An overlay service is a custom index over Bitcoin transactions.
The operator picks which transactions matter, organizes them, and answers queries about them. Whether anyone else can find the index is up to the operator.
How
A country of specialty archives
A country has many specialty archives, each devoted to a single kind of record. The same five things happen at every one of them, and those five are the whole story.
The Land Deed Registry
Records property transfers across the county.
The Birth Certificate Office
Records vital statistics for every citizen.
The Tax Records Office
Records assessments, payments, and arrears.
The Court Records Archive
Records case filings, motions, and rulings.
↓ The five concepts
Concept 01
01
tm_*
Topic Manager
The Registrar at the Intake Window.
Citizens bring documents. The Registrar checks format, signatures, subject. Valid filings are admitted. Invalid ones are returned at the counter.
Each archive runs its own Registrar with its own admission rules. There is no shared Registrar between archives. The Land Deed Registry's rules are not the Birth Certificate Office's rules.
Concept 02
02
ls_*
Lookup Service
The Clerk at the Reference Window.
Citizens come with questions. The Clerk searches the filing cabinets and returns matching records.
The Clerk reads from the same cabinets the Registrar fills, but they are different jobs at different windows. One admits. The other answers.
Concept 03
03
SHIP
The Intake Directory
The master directory of every Intake Window in the country.
When a new archive opens, the operator files a SHIP notice: "We accept land-deed filings here."
Anyone (citizens, other archives, apps) can ask SHIP "who accepts land-deed filings?" and get back the list of Intake Window addresses.
SHIP is itself an archive, with its own tm_ship and ls_ship. Every archive in the country keeps a copy of SHIP's filings.
Concept 04
04
SLAP
The Reference Directory
The master directory of every Reference Window in the country.
When the same archive opens, the operator files a second notice at SLAP: "We answer land-deed queries here."
Anyone can ask SLAP "who answers land-deed queries?" and get back the list of Reference Window addresses.
SLAP is itself an archive too. Same shape as SHIP, different role.
Concept 05
05
GASP
Peer Sync
How operators of the same topic keep their filing cabinets in agreement.
Multiple counties can each run their own Land Deed Registry. GASP is the protocol they use to keep their cabinets in agreement. When a deed is admitted at one Registry, GASP propagates it to peer Registries that have opted into syncing that topic.
Per-topic. tm_land_deed operators sync their tm_land_deed sets with each other. They never sync tm_land_deed with tm_uhrp. Different topics never cross.
Opt-in. Each operator decides per topic: sync with every SHIP-discovered peer, sync with named peers only, or don't sync at all.
Every overlay is an archive with two windows. Writers go to Intake, readers go to Reference. SHIP is the directory of Intakes. SLAP is the directory of References. The directory is itself an archive that every archive keeps a copy of.
One more thing
Overlays don't have to be public.
An overlay service is fundamentally an index over a slice of the chain. Indexes can be private just as easily as they can be public.
An operator can:
- Run a topic manager and lookup service without publishing SHIP or SLAP. Invisible to the federation.
- Encrypt the PushDrop payload. Observable on-chain but not interpretable.
- Require authentication on the lookup window. Visible URL, restricted answers.
- Sync only with named peers. A closed federation.
From the federation's view, these archives don't exist. From the chain's view, they look like ordinary transactions. The directory layer is opt-in by design.
The framework, in five lines
- 01 tm_* A Topic Manager admits transactions matching a specific rule.
- 02 ls_* A Lookup Service answers queries against what was admitted.
- 03 SHIP SHIP tells the world where the Topic Managers live.
- 04 SLAP SLAP tells the world where the Lookup Services live.
- 05 GASP GASP keeps same-topic operators in agreement, when they opt in.