Minerva

Specification

Minerva Channel Protocol

Version 0 (draft). Revisions to this specification are published as explicitly numbered versions. Conforming implementations state the version they implement.

Abstract

This protocol defines open, decentralized channels: continuously playing, synchronized video streams whose lineup is decided by costly, on-chain signals. Every viewer of a channel sees the same item at the same position, because channel state is derived deterministically from public blockchain data. Any party can run an indexer (an overlay host), recompute the exact same queue, and serve the same network. No host is privileged.

A channel is a mineable token. Creating a channel deploys a BSV-21 fungible token gated by a proof-of-work mint contract (POW20). Every interaction with the channel — programming a video, voting, commenting, chatting — is a token action carrying the interaction's data in the same transaction:

The transition between phases is emergent: when no mintable supply remains, the only valid token action left is a transfer. No mode switch exists anywhere in the protocol.

The same channel serves screens and phones together: a venue's big screen — a theater, a bar TV, a jukebox display — renders the channel; the phones in the room act on it. Physical presence is proven by committing a rotating nonce, displayed on the screen, into the work.

1. Design principles

  1. One primitive. Every capability of the system is a token action — a mint while supply remains, a spend once it is exhausted. There is no other way to act on a channel.
  2. Determinism. Two independent, conforming hosts presented with the same chain derive byte-identical channel state. Anything not derivable from confirmed chain data is explicitly non-canonical.
  3. Permissionlessness. Anyone may deploy a channel, mine any channel's mint phase, host an overlay, or implement a client. The protocol grants no party — including its authors — a privileged path.
  4. Costly signals. Influence over a synchronized, shared lineup must be expensive to fake. Work and tokens are the only inputs to ordering; identity multiplies nothing — splitting one miner into many identities splits no hardware.

2. Channels

2.1 Genesis

A channel is created by deploying a BSV-21 token whose minting is gated by a POW20 proof-of-work contract.

2.2 Display names

Display names are metadata, not identity. Names are normalized to lowercase a–z, 0–9, and hyphen; all other characters are stripped. The first valid deploy claiming a normalized name owns that name; later claimants are addressable only by channel ID.

2.3 Ownership authority

The owner's key signs moderate actions (§3.4) and receives owner-side settlement (§4). A channel whose owner never moderates behaves as a fully open channel. Transferring the deploy inscription to a provably unspendable address makes moderation permanently inactive and owner-side settlement unclaimable: a deliberately ownerless channel.

3. Actions

An action is a single transaction containing (a) a valid token operation on the channel's token and (b) a data payload (a MAP envelope) describing the interaction:

app       = minerva
version   = 0
type      = video | vote | comment | message | playback | moderate
channel   = <channel ID>
tx        = <target txid>        (vote/comment targets)
…type-specific fields

3.1 Mint-phase actions

While mintable supply remains, an action is a POW20 mint whose solved preimage commits to the action: the channel ID, the action type, the target (if any), the current presence nonce when the channel requires one (§6), and the actor's key. Committing the action into the work makes work non-reusable — it cannot be stockpiled, transplanted to another target, or performed by a party that cannot observe the presence nonce. Minted tokens go to the actor.

3.2 Spend-phase actions

When mintable supply is exhausted, an action is an ordinary BSV-21 transfer carrying the same payload. The transfer's outputs are the settlement (§4).

3.3 Action types

typeEffect on channel state
videoAdds an item to the channel's running queue. The act of adding is itself a costly signal: the action's own work (or spend) is the item's initial queue weight. The queue is managed by the protocol — clients submit actions; only the derivation in §5 orders them.
voteAdds the action's work (or spent tokens) to the target item's queue weight.
commentThreads under the target item. No effect on queue weight.
messageLive chat in the channel. No effect on queue weight.
playbackRenderer clock events — play, pause, skip, complete (§5.3).
moderateOwner-signed only: excludes a queue item (§3.4).

Direct messages between users are person-scoped, not channel-scoped, and are outside channel-token mechanics.

3.4 Moderation

A moderate action signed by the current owner key excludes a target item from the channel's queue. Hosts apply exclusions deterministically — they are ordinary admitted actions, ordered canonically like everything else.

4. Settlement (spend phase)

What recipients do with received tokens — resell, give away, reward — is economics, not protocol: any holder may do anything with their tokens.

5. Deterministic state derivation

5.1 Canonical and provisional state

Canonical state is computed from confirmed transactions only, totally ordered by (block height, transaction index within the block). Rules that depend on mempool arrival order ("first seen") are forbidden in canonical derivation: they are not reproducible across nodes.

Hosts may layer unconfirmed actions on top as provisional state for live user experience. Provisional state is non-authoritative, is labeled as such wherever exposed, and converges to canonical state on confirmation.

5.2 Queue weight and order

An item enters the queue with its originating video action and leaves the queue when it completes playback or is excluded by moderation. Re-queueing a played item requires a new video action. For each queued item i:

weight(i) = work/tokens of i's originating `video` action
          + Σ work of admitted mint-phase  vote actions targeting i
          + Σ tokens of admitted spend-phase vote actions targeting i

Mint-phase work is measured in difficulty-weighted valid solutions. Where a channel's history contains both phases, one difficulty-weighted solution at the deploy's mint difficulty counts equal to the deploy's per-mint reward in tokens. The queue is ordered by descending weight; ties break by the canonical order of each item's earliest contributing action, earlier first.

Because items are consumed when played, weight cannot pin an item permanently: support spent on an item is spent on one play.

5.3 Advancement and position

The playing client — the renderer: a TV, a jukebox screen, any player — is the channel's clock. It posts playback actions whose payloads carry a millisecond timestamp. On a canonical complete (or an owner-signed skip), the channel advances to the item with the highest current weight.

Playback position is derived, not streamed: position equals elapsed time since the timestamp of the governing play event. Any client computes "what is playing now, at what offset" without contacting a renderer. A channel with no playback events holds its queue, displaying the top-weighted item as up next; playback begins when a renderer posts play.

6. Physical presence

Channels may declare a presence policy in their deploy metadata. For presence-gated channels, the renderer displays a rotating epoch nonce, typically embedded in an on-screen join QR code, and commits each epoch's nonce on-chain under the renderer or owner key. Actions claiming presence commit the current nonce into the work preimage (mint phase) or payload (spend phase), making presence claims verifiable after the fact by any host.

The declared policy sets the weight of non-present actions: full, reduced by a stated factor, or zero. It is part of admission and applied deterministically.

This is what prevents remote hardware from programming a venue's screen: work that cannot reference the nonce displayed in the room carries no presence weight there.

7. Supply lifecycle

A channel's economic life has two emergent phases:

Supply, per-mint reward, and difficulty are fixed at deploy and are part of the channel's public metadata.

8. Conformance and versioning

9. Worked example (informative)

A bar deploys a channel (supply 1,000,000; reward 100 per mint) and puts its screen on TV mode, displaying the join QR with the current presence nonce. Guests' phones perform short proof-of-work bursts as votes; each valid mint commits (channel, song, nonce, key) and pays the guest 100 tokens. The screen advances on each canonical complete to the top-weighted item. The owner key excludes one entry. Guests leave holding the channel's token — early regulars accumulate a stake in the venue's channel. Years later, supply exhausted, the same channel runs in spend phase: votes pay the people who programmed the songs; programming fees pay the venue.

Appendix A — Operator commitments (non-normative)

The protocol above binds every host equally. Separately from it, Minerva — the protocol's first host and reference operator — publishes the following commitments about its own participation. They bind Minerva only; other hosts and participants owe nothing here.