# BRC-186: Thoughts on UTXO-Driven Applications and Private Overlays

Ty Everett (ty@projectbabbage.com)

The practical problem is keeping an application's view up to date as transaction-output data arrives from several sources and changes over time. Consider Tempo, a music application, querying three hosts for songs. One replies immediately, another takes five seconds, and the third is offline. The listener should be able to browse the first host's songs while the second is still responding, see the later results join the catalogue, and see subsequent edits or withdrawals reflected. If the listener disconnects, the application needs to catch up when they return. It also needs to make clear that the unavailable host's collection is missing.

A lookup treated as one finished answer leaves these problems for the application to solve. Waiting for every host delays useful results; stopping after the first response can omit later contributions. Repeating the query does not by itself explain how to handle duplicates, changes to previously returned outputs, or updates missed during a disconnection. The same difficulties arise with an editable post or a private conversation, even though the records mean different things.

The proposal is a reusable component inside the application that receives output information as it arrives, evaluates its evidence, remembers its sources, and helps the application update its view and recover after interruptions. This is what the essay calls an application runtime: shared state-management machinery for incoming output information. Tempo still defines what a song listing means; a social application defines what a post means. They can share the work of tracking outputs and changes while retaining their own application rules. Progressive results and resumable live updates are the intended behavior from the first useful version.

Tempo also illustrates a separate problem: coordinating public listings and payments with private information needed to use what was purchased. Its separate key-server design makes the application combine catalogue lookup with another service that releases the song's decryption key. In the proposed nearer-term design, the seller's overlay holds that non-public information. Browsing remains free, while an authenticated, paid lookup returns both the listing's transaction evidence and the listener's decryption capability. This gives the private-overlay part of the proposal a concrete purpose: replacing that separate key-server dependency through reusable overlay interfaces, with authorization and purchase recovery defined alongside them.

These application problems sit at the outer edge of the arrangement described in [Thoughts on the Mandala Network](./0090.md). Transactions flow inward through specialized services toward transaction processors, and information about them flows outward to the people deciding what to do next. This essay follows that flow at the application end, explaining how the shared components relate before their interfaces are specified.

This is a conceptual proposal. It brings together existing capabilities and proposed extensions so their relationships can be discussed before their detailed contracts are settled. It does not introduce a wire format, change an existing BRC, or claim that the complete system is already implemented. In particular, the application runtime, resumable live interfaces, purchase covenant and private submission results described below still need specifications and implementation work. The purpose here is to give those pieces a clear place in people's minds, with enough shared language to design them independently and fit them together later.

An output is a useful starting point because it gives us a definite object to discuss. It belongs to a particular transaction, has an output index, holds a quantity of satoshis, and has a script describing how it can be spent. The transaction identifier and output index together form its outpoint; while it remains unspent, it is a UTXO. Once created, those bytes do not change. What changes is whether the output has been spent, what evidence we have about it, and how an application interprets its relationship to other outputs. Bitcoin's fixed protocol provides the common transaction and spending rules beneath these applications; application protocols give particular outputs additional meaning.

An editable post, for example, can be represented by a succession of outputs. An authorized edit spends the output representing the current revision and creates another representing its successor. The post has an identity that survives the edit, although its current outpoint changes. Other designs may express changes through separate events or several related outputs. The application protocol decides which transitions represent edits, who can make them, and how to identify the same post across revisions. A spend alone says that an output was consumed. Whether that means a post was edited, a permission was withdrawn, or a purchase was made depends on the protocol using it.

Scripts and overlays take different parts of this work. A script can constrain a spending transaction according to conditions the Bitcoin network can evaluate. A topic manager decides how a transaction and any permitted accompanying information affect a particular overlay's records. A lookup service makes those records useful to callers. The submission and lookup relationships are already established by [BRC-22](../overlays/0022.md) and [BRC-24](../overlays/0024.md). An overlay's decision to admit an output does not add a consensus rule to Bitcoin, and a script cannot directly consult a private server merely because an application depends on that server. Any external fact used in a spending condition needs a defined representation and verification mechanism.

Overlays also differ in the collections they are supposed to maintain. [BRC-183](../overlays/0183.md) calls an overlay strict when its rules require hosts serving the same topic, rules version and scope to agree on common logical state at the same chain checkpoint. It calls an overlay federated when the rules permit different, potentially overlapping collections. An artist may serve their own songs, while a label serves songs from several artists. Both can be answering correctly even when their catalogues differ. An application benefits from combining those contributions; expecting every provider to return the same answer would erase the reason for asking several of them.

Both models can share transaction formats, topic interfaces, discovery, authentication, payment, and synchronization mechanisms. The Graph Aware Sync Protocol, [GASP](../transactions/0076.md), is compatible with both. It helps participants exchange the transaction graphs they intend to share; it does not require every federated host to carry everybody else's collection. Block-anchored mechanisms such as [BASM](../overlays/0136.md) address a more specific agreement over confirmed topic history. Provider synchronization and application synchronization are related, but they are different jobs. Two servers exchanging graphs does not by itself tell a returning phone which changes it missed.

The application can learn about an output through several routes. An overlay might return it in a lookup. A wallet might report it through a basket query. Another participant might send it through a message box, a direct connection, or an NFC exchange. These routes differ in availability, privacy, and the claims they make, but much of the work after receipt is shared. The application needs to identify the output, obtain and evaluate relevant evidence, remember where it came from, and decide what the observation changes. It should not need a different state engine for each way of receiving the same transaction.

The application runtime introduced above has the central job of maintaining knowledge about outputs. It sits above the [BRC-100](../wallet/0100.md) wallet interface and reuses the SDK's transaction and evidence facilities. Learning about an output does not mean taking custody of it, adding it to a wallet basket, or authorizing a payment. The wallet remains responsible for the operations the application explicitly requests through the wallet boundary. An application can browse a public catalogue before connecting a wallet, and a connected wallet does not give every incoming record permission to cause an action.

The first component in that runtime is a source adapter. It knows how to talk to one kind of source and turn what it receives into observations with provenance. Provenance means retaining which provider or peer supplied something, in response to which request, under what access scope, and with what authentication. The next components assemble transaction evidence and evaluate it against the application's selected chain view and policy. [BEEF](../transactions/0062.md) supplies an existing format for carrying transaction and proof material. The runtime should use that foundation, rather than invent another transaction format or accept a provider's claim that something is verified as a substitute for checking it.

The runtime then needs a durable knowledge store and a way to reconcile new observations with what it already knows. Transaction bytes, proof material, source claims, and the conclusions drawn from them have different lifetimes. The bytes of an identified transaction remain the same, while its reported chain placement or the application's assessment of its spend status may change. Remembering both the evidence and the circumstances of an assessment makes it possible to revise a conclusion when a dependency arrives, a conflict appears, or the chain reorganizes. Reusing already checked transaction material can avoid repeating work across receipts, while retaining the context in which those checks were valid. A conclusion should be explainable and revisable without pretending the earlier observation never happened.

Three identities help keep this manageable. An outpoint identifies an output within a particular Bitcoin network. A receipt identifies an occasion on which a source supplied information. An application object identifies the song, post, conversation event, or other thing the application is discussing. Two providers can supply two receipts about one output, while several successive outputs can represent one continuing application object. Deduplicating the output is useful, but discarding all later receipts would lose new evidence and possibly different private context. The first provider to respond does not acquire the right to define every subsequent interpretation of that output.

Several questions also need separate answers. We may have seen an output without having enough evidence to verify its transaction history. We may have verified that history without knowing whether the output remains unspent. We may know about a spend without yet knowing whether the application accepts the claimed successor. A provider may have removed a record from its catalogue while another still serves it. A previously useful assessment may have become stale. Combining all of these into one word such as “verified” or “final” makes the application harder to reason about. Unknown, pending, conflicting and stale are useful states to represent honestly. An unconfirmed transaction can inform a provisional view; a protocol that permits non-final amendments needs to explain their relationship separately, rather than letting the most recent arrival silently replace an earlier transaction.

Completeness has a scope as well. A provider may finish answering a query about its own catalogue without claiming to know every song in the world. A wallet may finish returning a page without promising that several pages form one unchanging snapshot. Several providers repeating the same assertion do not establish that they are independent or that no relevant output was omitted. Evidence of a transaction's creation does not by itself prove present unspentness, and agreement about response bytes does not prove that a query was answered completely. Markets such as [BRC-178](../overlays/0178.md), where providers compete to supply the same canonical payload, address a different question from paying for complementary catalogue contributions. A particular replicated object in a federated system can still be the subject of a same-answer query. The application needs to know which question each piece of evidence or economic arrangement can actually answer.

Application state emerges through a projection: the application-owned interpretation that turns accepted output knowledge into records people use. A music projection creates catalogue entries; a post projection follows revisions; a conversation projection interprets authorized events and membership changes. The shared runtime supplies evidence, changes and their context. The projection supplies domain meaning. It should be possible to rebuild that interpretation from retained information, or to explain when additional history must be retrieved. Enough ancestry to verify a transaction is not always enough history to understand the application object it belongs to.

A transaction can consume old outputs and create several new ones in the same state transition. Presenting these as one coherent change helps prevent an application from briefly showing both revisions as current or treating the disappearance of the old one as an unexplained deletion. The application still defines its conflict rules. Network arrival order is not a universal ordering of edits, and a live transport cannot settle which participant had authority to change a shared document. Likewise, replaying a stored change should not send another payment or repeat an external action. Interpretation and explicitly authorized effects need separate boundaries.

Progressive ingestion makes this model useful before every source has finished. If one artist's catalogue responds quickly and another responds later, the listener can start browsing the first while the second is still arriving. Progress can also happen within a single provider: records can move from storage, through evidence preparation, to the client in bounded portions. These are two different opportunities for improvement. A client receiving complete responses from several hosts progressively does not establish that any individual host can stream its own answer. Each capability needs an honest description.

Work continues after receipt, too. A query can have finished collecting while evidence remains queued for verification, and a verified record can still await application history. The runtime therefore needs to distinguish collection progress, processing progress and live continuity. Resource limits belong throughout this process: bytes, queued observations, dependency retrieval, verification work and retained history all consume finite resources. Reaching a limit means the result is partial or deferred under that budget. It does not mean an output is invalid or that an empty answer has been established.

Live updates extend the same learning process over time. The difficult part is connecting the initial view to subsequent changes without losing anything in between. A capable source can establish a position in its own change history, provide a view associated with that position, and replay later changes. If a post is edited while the initial view is being delivered, the client needs the edit to appear in that view or in the replay. A stream that happens to remain open is not enough to make that promise.

A resumable relationship needs durable memory on both sides of the handoff. The source retains the history it promises to replay, and the client saves accepted observations together with its recovery position. Repeated delivery is ordinary; accepting the same event again should not duplicate the effect. If history has expired, authorization has changed, or the source has rebuilt its state, an explicit reset can require a fresh view. Quietly skipping a gap would make the application appear current when it is not. Each provider's position describes that provider and query scope; it is not a global clock for all overlays.

Progressive initial results and resumable live updates belong together in the first useful version of this foundation. A person opening an application wants both a useful view promptly and a view that continues to make sense afterward. Older or simpler sources can still contribute finite observations, provided their limits remain visible. A disconnected source makes some knowledge stale; it does not erase what was learned. Source withdrawal, a Bitcoin spend, application deletion and loss of access are separate events, even when a particular interface responds to several of them by hiding an item.

These relationships should survive changes of transport and storage. HTTP, a framed stream or a message channel carries observations; a database retains them; a user interface presents the application's interpretation. None of those choices should own the definition of an output or an edit. Authentication must survive the choices as well: a scheme that authenticates only a complete response does not automatically authenticate an early portion of a streamed response. Detailed specifications will need to settle compatible framing, authentication, recovery and capability negotiation. This essay leaves those decisions open while identifying the promises they need to preserve.

A private overlay adds another dimension. Here, a private overlay means a system in which an overlay node holds non-public information. That is independent of whether the topic is strict or federated. It is also different from a public service storing ciphertext that only clients can interpret. The two privacy models can coexist, but the parties entrusted with secrets are different. A music seller holding a content key and a conversation host holding opaque encrypted events should not be treated as the same trust arrangement.

The existing overlay architecture already contains the core of this private pattern. A submitter can supply off-chain values alongside transaction BEEF. Those values can participate in topic evaluation and the notifications used to maintain lookup state. A lookup can return context alongside the BEEF for a relevant output. This was explicitly developed in the [private-overlay implementation work](https://github.com/bsv-blockchain/overlay-services/commit/29361ad7ed24e474636488e9eb87511b8d97bf8d), and the transport pieces appear in BRC-22 and BRC-24. The useful mental model is a node combining public transaction evidence with additional information it is authorized to hold and selectively disclose. [BRC-81](../overlays/0081.md) describes a particular earlier private-overlay proposal; it is not the definition of this broader capability.

Those channels provide a place for private information, but they do not by themselves establish who may publish it, how it survives a restart, or who may retrieve it. The operator needs protected storage and a trustworthy request context identifying the caller and any verified payment or other authorization. The topic or service decides what that authorization permits. A valid public transaction does not authorize every person who can copy it to receive a secret associated with it. Nor does BEEF automatically authenticate the meaning of arbitrary context bytes carried beside it.

The same separation continues at the client. Public output evidence can enter the shared knowledge process, while a private-result handler checks the recipient and acquisition bindings, unwraps the permitted secret, and stores it in the correct account context. Two responses about the same listing may have very different access rights. General caches, public live feeds and ordinary graph synchronization are not destinations for buyer-specific keys. Authorized replication of a seller's private state is a separate arrangement from synchronizing its public transaction graph. This gives private overlays a reusable role without assuming that every host discovered for a topic should receive the same secrets.

We can now follow the Tempo example through these components. Imagine two independent artists publishing through different hosts, with a label serving an overlapping catalogue from another location. The listener combines their public listings and sees new releases and changes as they arrive. Encrypted music can be stored and retrieved through content systems such as [UHRP](../overlays/0026.md) and [CHIRP](../overlays/0167.md). The catalogue helps people discover a song and its seller; content hosting supplies the encrypted bytes; the seller controls an authorized acquisition. These roles may share an operator, but their interfaces need not require one central platform.

The nearer-term Tempo design replaces the separate key server with a private overlay. The artist publishes a compatible song listing and supplies the associated decryption material privately to the selected seller or its authorized replicas. The seller checks the association and retains the private material durably. Catalogue browsing remains free. When the listener chooses a song, the application makes an authenticated purchase lookup to that seller, with payment through [BRC-105](../payments/0105.md). The response contains the listing's BEEF and private context giving the listener the decryption capability needed to play it. The listing does not need to be spent for each sale in this phase.

[BRC-101](../overlays/0101.md) supplies the conceptual direction for advertising facilitators with authentication and payment capabilities. Its composite URL negotiation is explicitly aspirational, so the near-term arrangement can use an explicitly selected HTTPS facilitator with the required authentication and payment behavior. Discovering several catalogues is one operation; buying from a selected seller is another. Combining public search results should not quietly purchase the same song from every responding host. The listener's choice of seller, asset and terms is part of the acquisition.

An acquisition also has a life beyond the request that initiated it. A payment may succeed while the response is lost, or the listing may change while the buyer is completing the purchase. The seller needs a durable association between the accepted terms, the buyer, the payment and the recoverable result. The buyer needs to recover that same acquisition without another charge. Current catalogue membership is not the whole record of an earlier purchase. Replacing a key server therefore includes preserving access, purchase evidence, royalties and outstanding obligations, as well as moving key delivery into the overlay interface.

The longer-term Tempo design moves the purchase payment into the listing's spending rules. A new kind of listing output represents a continuing right to sell the song. Its script acts as a covenant, constraining the transaction that spends it and the replacement output that transaction creates. Any listener can exercise its purchase route by submitting a purchase-order transaction that records the acquisition, recreates the listing in a successor output, and places exactly the song price more satoshis in that successor than were held in the consumed listing. The listener supplies the additional funding and transaction fees. Seller control is expressed through the contract's preserved terms and any administrative authority; this purchase route does not require obtaining a fresh seller signature for each listener.

For example, a listing holding one satoshi with a song price of one thousand satoshis would continue as a listing holding one thousand and one satoshis after a purchase. Another purchase would continue it with two thousand and one. The song remains available while proceeds accumulate along the listing's lineage. The exact script, lineage checks, buyer binding and transaction construction still need to be specified and proved. This is a proposed replacement token model, not a description of the current Tempo listing script.

The listener first discovers a current listing through the same free catalogue process. Their wallet then participates in constructing and funding the purchase transaction, which spends that listing under its purchase route. The listener submits the transaction evidence to the same seller's private overlay, this time through the topic-submission side. The topic manager evaluates the proposed transition, and the service applies its declared admission and release policy. Payment is now represented by the covenant transition. There is no additional song purchase hidden in a paid lookup, although a separately disclosed service fee could be a separate agreement.

Ordinary topical submission already returns STEAK, the Submitted Transaction Execution AcKnowledgment. The proposed private submission result adds POTATOES: Private Overlay Topical Admittance-linked Transactional Outward Evidentiary Secret. In the music example, the secret is the decryption capability for the song the listener has just purchased. You get potatoes back with your steak on private-overlay submits. The name is playful, but the distinction is useful: STEAK describes topical admission, while POTATOES provides a private result associated with that admission and authorized for a particular recipient.

POTATOES belongs at a generic private-response boundary, rather than making the overlay engine understand songs. Another application could use the same relationship to deliver a document key or another capability released by an accepted transaction. A future response specification would bind that result to the operator, topic, transaction, application object and authorized recipient. The buyer's entitlement cannot be a public transaction ID that any observer can replay. The existing STEAK response is not an open bag for arbitrary new fields; an extension needs negotiated behavior that preserves existing clients and exposes the appropriate private receipt to the caller.

Admission and delivery need a recoverable relationship. Before releasing a secret, the service should have committed the relevant admission and acquisition association under its stated durability policy. It may have to report that admission succeeded while private delivery remains pending. After a lost response or restart, the recipient should be able to recover the same result, even if later buyers have already spent the successor listing. Historical replay, index rebuilding and graph synchronization must not be mistaken for new authorizations to release secrets. Public history and a protected acquisition record have different audiences and retention needs.

The service must also explain when it considers the transaction sufficiently accepted to release an irreversible secret. Local validation, processor acceptance and block confirmation are different observations, and STEAK does not mean that a transaction has been mined. A key released under an early acceptance policy cannot be recalled after a conflict or reorganization. More fundamentally, the covenant can enforce the paid transition without forcing an unavailable seller to send an off-chain key. Preflight checks, key commitments, recovery and authorized replicas can address parts of the problem, but this design does not by itself establish trustless atomic exchange of payment for a secret. “Evidentiary” describes the result's verifiable relationship to the admitted transaction and recipient, not a claim that the acronym removes those limits.

A single continuing listing also creates a natural concurrency question. Two listeners can discover the same outpoint, but both competing spends cannot become the accepted continuation. The application needs to resolve an uncertain first attempt before treating a retry against a newer listing as another purchase. Live updates reduce stale discoveries without removing that race. One possible administrative route would let the seller split a right-of-sale lineage into several independently purchasable outputs, giving concurrent listeners different outpoints to use. That is parallel sale capacity, not an assertion that only a fixed number of copies of the music exist.

Other possible administrative routes would merge current outputs from the same lineage while preserving their aggregate value, or distribute accumulated proceeds to artists and band members. A merge must account for every predecessor once; several separate checks against the same successor are not a substitute for conserving the total. A payout needs defined authority, recipients and any reserve needed to keep selling. Price updates or retirement would have their own rules and would preserve earlier acquisition obligations. These routes remain choices for separate specifications and review. The basic purchase concept establishes recreation and the exact price increase without pretending to settle every administrative design.

Content licensing is another component with its own meaning. A person holding encrypted bytes, a seller holding a key, an operator entitled to receive payment and a party authorized to grant a license may be different participants. [BRC-170's Locked Content Header](../apps/0170.md), or LCH, supplies existing concepts for assets, authority, offers, buyer licenses, key delivery and acquisition recovery. Tempo should build on those where applicable. A key in lookup context is not automatically an LCH license, and an overlay's willingness to admit a transaction does not establish the seller's authority over the music.

The two Tempo phases need explicit relationships to the selected licensing profile. A BRC-105-funded lookup could carry an LCH license and key grant while preserving the signed request, accepted terms and settlement semantics. A covenant that accumulates proceeds in a listing is a different settlement arrangement from immediate BRC-29 outputs to the payees, so that phase needs a separately specified LCH acquisition and settlement profile. [BRC-369](../peer-to-peer/0369.md) also addresses keyed content and conditional release; its mechanisms are related work, not an automatic protocol binding to POTATOES. Reusing established parts means preserving their guarantees and defining how they connect, rather than treating similarly named results as interchangeable.

Media delivery remains separate from all of this. Retrieving and authenticating encrypted song segments, seeking within a track and decoding audio are content and player responsibilities. Streaming those bytes is a different process from streaming changes to a catalogue's UTXOs. A foundation for application state should accommodate both without becoming an audio player. The nearer-term private-overlay purchase also need not wait for every licensing feature or the later covenant. Each phase can establish a useful, well-defined relationship while leaving room for the next one.

Private conversations exercise a different part of the same foundation. In a system such as Convo, participants may receive encrypted messages promptly through a message box and reconcile them with durable encrypted records afterward. An immediate notification and an accepted durable event are different observations. Membership changes, writer authority, key epochs and access to earlier history belong to the conversation protocol. A transport recovery position cannot decide whether a late message belongs before or after a membership change. Presence and typing indicators may remain ephemeral signals without being forced into a UTXO representation. The common runtime helps with evidence, provenance and recovery while respecting those domain and privacy boundaries.

An editable post is a smaller place to demonstrate the complete cycle: publish, discover, edit, interact, disconnect and catch up. Several providers can overlap, one can respond slowly, and a client can join while a revision is changing. A richer social application such as BlockIt can then exercise several related kinds of state together. These examples are useful because they force reusable components to serve different meanings. The music catalogue should not become the universal application schema, and the conversation's group coordination rules should not become a requirement for every overlay lookup.

Coordination among operators is a further, separate concern. An operator may ask peers to review a discovery advertisement, temporarily suppress it, or consider evidence about a service. Such a request is attributable advice unless a specific authority arrangement says otherwise. Each recipient applies its own policy. Removing an advertisement from a local result does not spend its UTXO or rewrite common admitted history. Keeping that distinction visible allows discovery policy, restoration and audit to develop without turning application ingestion into an implicit power to delete another operator's state.

The durable foundation is in the agreements between these responsibilities. Source adapters supply observations; evidence components evaluate transaction material; a knowledge store preserves what was learned and why; application projections give it meaning; private handlers process authorized non-public results; wallets carry out explicitly requested actions. Server-side topic managers, lookup services, private stores and delivery services have corresponding boundaries. Capabilities describe which guarantees an implementation actually offers. Two modules become meaningfully interchangeable when they handle the same recorded scenarios, failures and recovery cases consistently, not merely when their TypeScript method names happen to match.

Within the TypeScript stack, this points toward a small application-layer core with optional adapters, reusing the SDK, overlay and authentication/payment components where those responsibilities already live. Particular databases, transports, user-interface frameworks and domain models can then evolve independently. Detailed BRCs can specify the agreements that independent parties need to share: output observations and assessments, incremental lookup and resumable changes, private publication and lookup results, admission-linked private delivery, and particular application or licensing profiles. Reference implementations, independent consumers and reproducible multi-host examples can test those agreements before they are called stable. No single proposal needs to settle every layer at once.

The resulting application participates in the same inward and outward flow as the wider Mandala Network. People express an intention through an application and wallet. Transactions change the outputs under Bitcoin's rules. Overlays recognize the changes relevant to their topics, and services make public evidence and authorized private results available. Applications learn progressively, retain enough context to recover, and translate that knowledge into the next useful view or action. The protocol beneath them remains fixed, while the surrounding components can specialize, be replaced, and be combined in ways that preserve a clear account of what each one knows and promises.