28 standards
Scanning the whole chain to find one application's data does not scale, so an overlay watches for the subset that matters and answers questions about it. Standards here cover running one, federating several, and keeping a private one private.
Also searched as overlay networks, overlay service, topic manager, federated overlay, private overlay, CHIP, index.
An index that watches the chain for the subset of transactions one application cares about, grouped under a topic. It exists because scanning the whole chain for your own data does not scale.
Open in the glossary28 standards, spread across 4 of the 12 topics.
Apps that show Bitcoin-derived data (like a music catalogue or a task list) often pull information from more than one source: an overlay network, a wallet's own storage, or a direct message from another peer. Without a shared discipline, an app ends up treating whichever source answered first as the single truth, so later corrections, competing hosts, or spends get silently lost or wrongly overwrite each other. This leaves developers unsure how to combine "someone claims this output exists" with "this output is actually verified on-chain" without conflating the two.
Filed under Applications
Watching the chain is the main subject of these 5.
Some ways of tracking blockchain state require every participant to see every transaction, which stops working as volume grows. This argues that indexes watching only the slice they care about are both safer and able to scale.
Different Bitcoin-based apps use the word "overlay" for two very different setups: one where every server is supposed to agree on the exact same data, and one where servers legitimately hold different, non-matching collections. When people conflate these, it becomes unclear whether a mismatch between two servers is a bug to fix or just two valid, different answers.
Early designs for tracking and coordinating transaction-based state tended to assume everyone needed to see everything, which does not match how most real applications actually share data. Teams building on top of transaction outputs had no shared way to think through when to keep an overlay open to everyone versus restricted to a known set of participants, so designs ended up copying patterns that did not fit their actual trust or privacy needs. This leaves developers without a clear mental model for choosing the right shape of network for their application.
Apps that show Bitcoin-derived data (like a music catalogue or a task list) often pull information from more than one source: an overlay network, a wallet's own storage, or a direct message from another peer. Without a shared discipline, an app ends up treating whichever source answered first as the single truth, so later corrections, competing hosts, or spends get silently lost or wrongly overwrite each other. This leaves developers unsure how to combine "someone claims this output exists" with "this output is actually verified on-chain" without conflating the two.
Free blockchain explorer lookups (finding a transaction or checking an address's history by typing its ID) feel like a permanent utility, but someone pays in storage, bandwidth and recovery costs for every address and transaction they index forever. Apps and wallets that rely entirely on a provider's free lookups have no warning if that provider decides to narrow what it indexes for free, and no shared playbook for what "narrower" would even mean. This proposal gives providers a common, predictable schedule for shrinking free coverage, so apps can plan ahead instead of being surprised.
These are about something else, and deal with watching the chain on the way.
Finding your own application's data on the blockchain means either scanning everything or trusting somebody else's index. This defines how to submit transactions to a service that tracks only the subset you care about, and how it reports back what it accepted.
An index that watches part of the blockchain is only useful if you can find one, and relying on a single index is a single point of failure. This describes how such services announce what they track, so clients can discover several and survive one going offline.
Submitting data to an index is half the job; getting it back out again is the other half. This defines how a client asks such a service what it is holding and receives an answer it can verify for itself.
Referring to a file by a web address breaks the moment that address stops working. This lets a file be named by its contents instead, with any number of hosts advertising that they hold a copy.
Applications constantly need somewhere to keep small pieces of state, and doing that on chain usually means inventing a scheme per project. This standardises a simple named-value store: a public one others can discover, and a private one held in the wallet.
An index that only keeps current data cannot answer questions about how something got to be the way it is. This extends the index to retain the spent history as well, so past states remain queryable.
An index does not have to build its view purely from what is written on chain. This shows how one can track ordinary payments privately, keeping the interesting details off the public record.
Independent implementations picking their own names for the same index or query will not interoperate. This proposes naming conventions so a name means the same thing wherever it appears.
Indexes need to find each other and stay in step, and doing that ad hoc leaves gaps. This defines how they announce what they track and what they answer, and how they synchronise once found.
Talk about a decentralised web rarely says concretely what the pieces are or how they fit. This sketches one: wallets, indexes, browsers and payments, and where each belongs.
Discussions of network design tend to jump straight to mechanisms without saying who is doing what. This lays out a three-layer picture, with processors at the core, indexes in the middle and ordinary users at the edge, as a shared vocabulary for the rest.
Once the layers of the network are named, the next question is which pieces of a transaction belong to which layer. This works through where outputs, indexes and scripts sit and how they relate.
Index advertisements were assumed to contain a plain web address, which rules out reaching a service any other way. This allows other kinds of address so a service is not tied to one way of being contacted.
A tool that deploys an application needs to know its pieces, and every project describing that differently means the tooling only works on projects it was written for. This fixes the shape of that description file.
Distributing a new token fairly means finding work worth doing rather than work that only burns electricity. This ties minting to proof that real indexing work was performed.
An index cannot easily prove it has seen everything relevant in a block rather than most of it. This gives a per-block summary that makes completeness checkable rather than assumed.
If you know a domain runs some kind of overlay service, there was no standard place to find out where to actually send requests for it. You'd end up guessing at conventions like an api. subdomain, or asking around, with no way to be sure you weren't just hitting the wrong host. This gives a domain one clear file where it states, service by service, which URL to use.
Pulling a large, constantly changing list of overlay results used to force a choice between getting a stable view that quickly goes stale, or watching live updates and losing track of what you already saw if your connection dropped. There was no safe way to read the current state of something and then keep watching it change without missing an update that happened during a disconnect. This gives a reader a consistent starting snapshot plus a way to pick back up exactly where it left off, even after going offline.
Apps that talk to overlay services had no standard way to ask a host "what can you actually do, and on what terms" before sending data. Without that, a client either guesses a URL and hopes, or every integration invents its own private handshake for things like private lookups or proposing a transaction that isn't finished yet. This makes it possible for a client to discover exactly which services and payment or auth rules a host supports, and to safely work with draft transactions that are not yet final.
Some data on the blockchain world needs to stay private until someone pays for it, like a song's decryption key, but the usual way overlay servers share and index information assumes everything is public and copied everywhere. Without a clear contract, a seller has no safe way to accept payment, hold a secret key in reserve, and reliably hand it over, especially if a network hiccup happens between "paid" and "delivered". This makes it possible to run a paid catalogue where buyers always eventually get what they paid for, even after crashes or lost responses.
Imagine paying for a digital item, like a song, over a payment network: the network can confirm the payment landed, but has no built-in way to also hand over the thing you paid for only once that payment is genuinely and exclusively yours. Without a clear process, a seller could claim a payment is accepted but never deliver, deliver to the wrong person, or leave a buyer stranded if something fails partway through. This gives buyers and sellers a dependable, replayable sequence for locking in terms, submitting payment, and releasing the purchased secret only to its rightful recipient.
When a wallet or app stops endorsing an advertisement, or a root decides it no longer wants to show one, there has been no shared, attributable way to ask a server to stop serving that one specific record without pretending to be a global ban or an on-chain spend. Without it, roots either ignore stale or withdrawn ads forever or quietly drop them with no record of who asked or why, and restoring one later is guesswork.
A token can change hands hundreds of times, and each new holder is expected to check the token's full history back to its creation to be sure it is real. For a long-lived token that check gets slower and more expensive every time it trades, to the point where a wallet on a laptop simply cannot do it fast enough. This makes it possible to hand a newcomer a single small proof instead of the whole history, while still letting them verify it themselves rather than trust whoever gave it to them.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic