Race-Settled Collection Markets for Overlay Lookups and Message Boxes

Abstract

This BRC specifies a client-judged payment market that lets a network of independent overlay hosts and message box servers compete to answer the same query. A client broadcasts an authenticated request, ranks responses by the time they actually arrive, and pays the fastest hosts that attest the same content hash. Payment is split across a configurable top-K set using Fibonacci weights so that second- and later-place hosts still earn, which keeps a long tail of operators viable and resists monopoly. A possession threshold on the content hash punishes hoarding: a host that withholds a message from its peers cannot collect, because too few independent attestations exist. Recipients need not hold BSV. The sender of a stored message MAY pre-fund a collection grant that the recipient spends at collect time. The same market applies to BRC-24 overlay lookups, BRC-33 message box collection, and other relay lookups whose result is a byte string that can be hashed.

This BRC does not replace a single trusted host. Applications that already trust one regulated operator MAY keep using one message box URL. This BRC is the interoperable economics layer for operators who want the same query to be answerable by any honest host in a set.

Copyright

This BRC is licensed under the Open BSV License.

Motivation

BRC-33 defines a store-and-forward message box addressed by identity key. BRC-34 and overlay advertisements let clients discover hosts. BRC-24 defines overlay lookup. BRC-41 and BRC-105 define how a single HTTP host can charge for a request. None of those standards specify how a set of hosts should be paid when all of them can answer the same query.

Two failures follow from that gap.

1. A single message box URL is a single point of failure and a single point of trust. If that host drops, swaps, or delays a message, the client has no competing supplier.
2. Hardening only the lookup path with overlay quorums, while still delivering the message to one URL, is incomplete. The destination remains a single server that can drop everything the quorum agreed about.

A fully on-chain mailbox avoids the single host but re-prices every message as a permanent inscription. A Byzantine consensus layer among hosts can agree on directory state, but hosts that are not miners have no native reward for honesty.

This BRC takes a narrower cut. The scarce resource is timely, verifiable delivery of a hashed payload. The client is the judge of arrival time because only the client observes arrival. Hosts are paid only when:

• the payload hash they attested is the hash the client accepted, and
• enough distinct hosts attested that same hash.

Hoarding is then self-defeating. Sharing a message with peers is what makes a host eligible to be paid. Racing to respond is what determines how much of the fee that host receives. BSV micropayments make a long-tail split practical: the twentieth responder can still be paid a fraction of a satoshi.

Identity keys are the account model. Every query is authenticated under BRC-103 so a host can attribute payment, reputation, and rate limits to a stable public key rather than an IP address or a cookie.

Scope

In scope:

• the query, attest, collect, and pay flow between one client and many hosts
• the content-hash attestation threshold
• the Fibonacci payout function and protocol floor fee
• sender-funded collection grants for empty-wallet recipients
• identity-key reputation for non-payment
• application of the market to BRC-24 lookups and BRC-33 message listing

Out of scope:

• the wire format of BRC-33 message bodies and BRC-24 output-list answers, which remain as defined in those BRCs
• host discovery, which remains BRC-23, BRC-25, BRC-34, BRC-101, and BRC-169
• identity binding of a human handle to an identity key, which remains BRC-52, BRC-68, and BRC-169
• on-chain inscription of message payloads
• a new consensus protocol among hosts

Terminology

Specification

Roles and trust boundary

A host is trusted only to store and return bytes. A client MUST treat host-advertised timestamps, ranks, and "I was first" claims as untrusted. Arrival time is measured on the client. A host signature is trusted only as a statement by that host's identity key.

A client that wants availability from a set of hosts MUST NOT depend on any one host being honest, live, or well-connected. The protocol remains useful with one host (t = 1, K = 1); that profile is the existing single-server model and is permitted.

Authentication

Every query, attestation, and collect request MUST be authenticated so that the caller's identity key is bound to the exact request bytes.

1. HTTP transports MUST use BRC-103 mutual authentication over BRC-104.
2. Implementations SHOULD use the @bsv/auth package, or an equivalent BRC-103 binding, so the identity key is present on every request without a side channel.
3. The authenticated identity key of the client is the account against which hosts apply rate limits and reputation.
4. The authenticated identity key of the host is the account that receives payout outputs and that is counted toward threshold t.

Replay protection follows BRC-103 session nonces. A host MUST reject an attestation or collect whose query identifier it has already settled.

Canonical payload hashing

The content hash is SHA-256(canonicalPayload).

Canonical encodings:

Hosts that disagree on canonicalization will disagree on the hash and will fail the threshold. Implementations MUST use the table above.

Query identifier

A client constructs a query object and a query identifier:

{
  "type": "message-list",
  "client": "<client identity key hex>",
  "hostSetHint": ["<optional host identity keys>"],
  "params": {
    "recipient": "<identity key hex>",
    "messageBox": "payment_inbox"
  },
  "maxFeeSats": 20,
  "floorFeeSats": 2,
  "threshold": 3,
  "topK": 5,
  "raceMs": 400,
  "expires": "2026-09-18T19:05:00.000Z",
  "nonce": "<32-byte hex>"
}

queryId is SHA-256 of the UTF-8 JSON query object with keys sorted lexicographically.

The client broadcasts the query to every host it is willing to pay. Hosts not listed in hostSetHint MAY still answer. hostSetHint is an optimization, not an allow-list, unless the client sets an implementation-defined policy flag strictHosts: true.

Phase 1 — Attest

A host that can answer the query returns an attestation without necessarily shipping the full payload.

Attestation payload

Attestation preimage, concatenated as UTF-8 with \n separators:

BRC-178 attestation
<queryId>
<host>
<contentHash>
<payloadSize decimal>

A host MAY attach the full payload in Phase 1. Clients MAY use an attached payload to start hashing immediately, but MUST still wait for the race window and threshold before paying.

Client ranking

1. Record the local arrival time of each syntactically valid attestation.
2. Discard attestations with an invalid signature, an expired queryId, or a host identity key that does not match the BRC-103 session.
3. Group remaining attestations by contentHash.
4. After raceMs from the first valid attestation, or sooner if t attestations for one hash have arrived and the client is satisfied, select the contentHash with the most distinct hosts. Ties break to the hash whose earliest attestation arrived first.
5. If the winning hash has fewer than t distinct hosts, the client MUST NOT pay. It MAY retry, widen the host set, or fall back to a configured single host.
6. Sort hosts that attested the winning hash by client-measured arrival time, ascending. That order is the race ranking.

Default parameters:

Phase 2 — Collect and pay

The client sends a collect request to the ranked hosts, or to any host that attested the winning hash. Payment is a single BSV transaction with one output per paid host.

Collect request

The payment object MUST be a BRC-105 x-bsv-payment JSON body (or the equivalent header on HTTP) whose transaction pays the ranked hosts.

Fibonacci weights

Let F_1 = 1, F_2 = 1, and F_n = F_{n-1} + F_{n-2} for n > 2.

Let k be min(K, number of ranked hosts that attested the winning hash).

The weight for rank i (1-based, 1 is fastest) is:

weight(i) = F_(k - i + 1)

The fee R is max(floorFeeSats, client-chosen fee, sender grant remainder) satoshis.

Let S = weight(1) + ... + weight(k).

payout(i) = floor(R * weight(i) / S)

Any remainder R - sum(payout) is added to payout(1).

Worked example, k = 5, R = 12:

Worked example, k = 3, R = 20:

Outputs use BRC-29 derivation. For ranked host i:

• counterparty is that host's identity key
• derivationPrefix is queryId
• derivationSuffix is the two-byte big-endian rank i

This binds each output to one query and one rank and prevents a host from claiming a different rank's output.

A client MUST create outputs only for hosts that attested the winning hash. A client MUST NOT pay a host that attested a different hash.

Host collect response

A host that accepts the collect returns the canonical payload whose hash is contentHash, plus a BRC-77 signature over queryId || contentHash || payloadSize.

The client hashes the received payload and MUST accept it only if the hash equals the committed contentHash. If the bytes do not match, the client treats the host as dishonest for reputation purposes and does not acknowledge a BRC-33 message against that host alone.

Because the payment transaction is already bound to queryId and rank, a client that received matching bytes SHOULD broadcast the transaction. Withholding broadcast after a valid collect is the non-payment attack discussed below.

Sender-funded collection grants

A recipient who has never held BSV still needs to collect. The sender of a stored message MAY attach a grant.

When calling BRC-33 sendMessage, the sender MAY include:

{
  "collectionGrant": {
    "satoshis": 20,
    "expires": "2026-10-18T00:00:00.000Z",
    "minThreshold": 3,
    "transaction": "<Atomic BEEF base64>"
  }
}

The grant transaction pays an output that the recipient's identity key can unlock under BRC-42 / BRC-29, using:

• protocol ID [2, "BRC-178 collection grant"]
• key ID equal to the message's messageId as a decimal string

The message box host MUST store the grant with the message and MUST release grant details to the authenticated recipient on listMessages.

At collect time the recipient (or their wallet) spends the grant into the Fibonacci payout outputs. The recipient does not need an independent BSV balance. If no grant exists, the recipient pays from their own wallet, or the collect fails with a payment-required error per BRC-105.

A grant MUST meet the floor fee. Senders MAY attach more than the floor to buy faster propagation: hosts SHOULD gossip messages with larger remaining grants first.

If a grant expires unspent, the sender's wallet MAY reclaim it. Hosts MUST stop advertising expired grants.

Anti-hoarding rule

A host is eligible for payout on a query only if it is one of at least t distinct hosts that attested the same contentHash for that queryId.

Consequences:

1. A host that receives a sendMessage and does not propagate it cannot form a threshold set by itself unless t = 1.
2. Propagation is therefore the path to eligibility, not an act of charity.
3. The client enforces the rule by refusing to pay when t is not met. No extra inter-host consensus protocol is required for this check.

Hosts SHOULD forward a newly stored payload to a random subset of advertised peers promptly. This BRC does not mandate a gossip wire format; BRC-34, BRC-23, and BRC-88 remain the discovery and sync substrates.

Honor, reputation, and optional query deposits

Micropayment amounts in this market are often too small to justify an on-chain dispute. The default profile is honor plus reputation:

1. Compliant clients always broadcast a valid payout transaction after accepting a payload whose hash matches the committed contentHash.
2. Compliant hosts always propagate payloads they intend to collect on, and always return those exact bytes on collect.
3. Each host MAY keep a local reputation score keyed by client identity key. A client that repeatedly collects and does not broadcast payment MAY be rate-limited, required to attach a query deposit, or refused.
4. Each client MAY keep a local reputation score keyed by host identity key. A host that attests a hash and then delivers different bytes, or that consistently misses the race window, MAY be dropped from hostSetHint.

Optional query deposit, for hosts that do not trust a client:

A host that delivered a matching payload and can prove non-payment MAY claim the deposit as compensation. Proof of non-payment is the existence of a completed collect transcript and the absence of the expected payout transaction in a subsequent window. This profile is OPTIONAL. Implementations that deal only in dust-sized fees SHOULD skip deposits and rely on reputation.

Floor fee

The network floor exists so a sender cannot starve collectors by attaching a zero grant.

• floorFeeSats MUST be at least 1.
• The recommended default is 2.
• Hosts MAY refuse to store or gossip a message whose grant is below the floor.
• Hosts MAY advertise a higher local floor. Clients treat the effective floor as the maximum of the protocol default and the floors advertised by the hosts they intend to pay.
• The floor MAY vary with payloadSize. A recommended schedule is 2 satoshis plus 1 satoshi per 1024 bytes of canonical payload, rounded up.

Bootstrapping (non-normative)

A new host set has no traffic and therefore no fees. An application treasury MAY pay a declining per-query subsidy to every host that produced a valid attestation included in a threshold set, for a fixed number of months. The subsidy MUST be disclosed. After the window, only race fees and grants remain. This BRC does not require a subsidy and does not specify a treasury.

HTTP binding

Hosts that already speak BRC-33 and BRC-24 keep those paths working. This BRC adds three routes, all BRC-103 authenticated:

A BRC-33 listMessages call MAY be answered as a message-list query class without a separate /brc178/query hop when the client includes the BRC-178 query fields in the existing body. Hosts that do not implement BRC-178 ignore those fields.

Payments ride BRC-105 headers:

• x-bsv-payment-version
• x-bsv-payment-satoshis-required on a 402 challenge
• x-bsv-payment on the collect request

Relationship to a single trusted host

An application that already trusts one regulated operator — for example a licensed stablecoin issuer that also runs the message box — MAY set t = 1 and K = 1 and ignore Fibonacci splits. That profile is compatible with this BRC and with today's BRC-33 servers. Moving from that profile to t = 3, K = 5 later does not require a new identity scheme. It requires only that additional hosts store the same payloads and that clients raise t.

Generalization

Any read that returns a deterministic byte string can use this market. Overlay lookups, UHRP host resolution, handle resolution side-channel records, and relay lookups are the same race: authenticate, attest a hash, wait for threshold, pay the fastest attesters, collect the bytes, verify the hash.

Writes (BRC-33 sendMessage, overlay ingest) are not raced for payment in this BRC. A write host MAY still charge a BRC-41 / BRC-105 ingest fee of its own. The collection grant is how the writer pays the future readers' hosts.

Examples

Example attestation

{
  "type": "attest",
  "queryId": "a4f1c2e8b0d65c1f9e3a7b2c4d8e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e",
  "host": "02c0b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3",
  "contentHash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
  "payloadSize": 184,
  "quotedFeeSats": 4,
  "attestedAt": "2026-09-18T18:59:01.233Z",
  "signature": "3045022100ab..."
}

Example collect ranking and outputs

Fee R = 12, k = 5. The client constructs one transaction with five BRC-29 outputs of 5, 3, 2, 1, and 1 satoshis to the five host identity keys in ranking order. derivationPrefix is the queryId. derivationSuffix is 0001 through 0005.

Example empty-wallet collect

Alice sends Bob a payment notification. Alice attaches a 20-satoshi collection grant. Bob's wallet has no BSV. Bob's client runs Phase 1 against three advertised hosts, obtains three attestations of the same list hash, spends Alice's grant into the Fibonacci outputs, and receives the message bodies. Bob never funded a wallet.

Implementation

Clients:

1. Use @bsv/auth (or equivalent BRC-103 HTTP transport) on every host call.
2. Fan the query out in parallel. Rank by local arrival time, never by attestedAt.
3. Compute SHA-256 over the canonical encoding in the table above, not over a pretty-printed JSON variant.
4. Broadcast the payout transaction only after at least one matching payload arrives, and do so promptly.
5. Persist host and client reputation locally. Do not treat another host's reputation gossip as authoritative.

Hosts:

1. Advertise BRC-178 support from /brc178/params and, when using overlay advertisements, from the existing [object Object]/SLAP records.
2. Propagate stored payloads to peers before expecting to win races that require t > 1.
3. Verify collect payments with internalizeAction against the advertised BRC-29 derivation.
4. Do not persist ephemeral lookup prefixes typed by a user beyond the request lifetime. Fuzzy-search autocomplete is allowed to see partial queries in memory; it SHOULD NOT log them.
5. Refuse grants below the advertised floor.

Single-host operators implementing BRC-33 today can add /brc178/params returning t = 1, K = 1 and accept BRC-105 payment on listMessages without implementing gossip.

Security considerations

• Host-claimed timestamps are not a ranking signal. A host that backdates attestedAt must not gain rank.
• Threshold t is a liveness and safety tradeoff. High t raises hoarding cost and also raises the chance that a live-but-small host set cannot be paid. Applications pick t for their host-set size.
• A client can collect bytes and withhold payment. Reputation and optional deposits are the intended controls. On-chain escrow for dust fees is usually more expensive than the fee.
• A host can attest a hash it does not hold, then fail collect. It wastes a rank slot and burns reputation. Clients SHOULD skip such hosts on the next query.
• A host can serve a valid payload and still lie in future queries. Hash verification is per query and does not create a durable content-addressed store unless the application also uses BRC-26 / BRC-167.
• Collection grants are value. Hosts MUST authenticate the recipient before revealing grant transactions.
• Fuzzy identity search leaks partial queries to every host that receives them. That leak is accepted for UX. Honest hosts process those prefixes ephemerally.

References

• BRC-24: Overlay Network Lookup Services
• BRC-29: Simple Authenticated BSV P2PKH Payment Protocol
• BRC-31: Authrite Mutual Authentication
• BRC-33: PeerServ Message Relay Interface
• BRC-34: PeerServ Host Interconnect Protocol
• BRC-41: PacketPay HTTP Payment Mechanism
• BRC-42: BSV Key Derivation Scheme
• BRC-52: Identity Certificates
• BRC-77: Message Signature Creation and Verification
• BRC-95: Atomic BEEF Transactions
• BRC-103: Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
• BRC-104: HTTP Transport for BRC-103 Mutual Authentication
• BRC-105: HTTP Service Monetization Framework
• BRC-167: Chunked, Hashed, Interleaved Resolution Protocol (CHIRP)
• BRC-169: Universal Handle Addressing and Resolution for the Metanet
• @bsv/auth npm package