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 square-root weights so that second- and later-place hosts still earn enough to stay viable, while first place still earns more than fifth. A possession threshold on the content hash makes isolated possession insufficient to collect: eligibility requires t distinct host identity keys attesting the same hash. 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.

Eligibility is then a function of shared possession, not isolated possession. A host that can answer quickly still needs t distinct identity keys to have attested the same content hash before the client may pay. Racing to respond determines how the fee is split. BSV micropayments make a long-tail split practical.

Overlay lookup data is a commodity. Any honest host can obtain the same payload from the chain or from a peer. The product users actually buy is collective availability: no single operator can credibly sell more than about 99.9% uptime without extreme cost, so even the current fastest host benefits when another host is up during its outage. Withholding payload from other operators in order to starve them therefore shrinks the reliability of the market the withholder itself sells. The rational strategy for an operator is to be as fast as it can, not to hoard.

Geographic proximity to clients and pre-computation of likely answers are investments. The race pays for them. The protocol MUST NOT penalize a host for being close to its customers or for having warm caches.

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 square-root payout function, protocol floor fee, and default SLAP-tracker bootstrap
• 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
• complete-payload hash check at collect time
• sender grant expiry and reclamation
• operator discretion to refuse a query

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. Storage format is not the attested format. A host that attests SHA-256 of non-canonical bytes is not interoperable and MUST be treated as a different content hash.

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.
7. Arrival time is the local receive time of a syntactically valid attestation. The client MUST NOT subtract measured RTT, MUST NOT penalize geographic proximity, and MUST NOT treat a warm or pre-computed answer as invalid. Those are legitimate sources of speed.
8. raceMs MAY be adapted from observed network conditions. Randomizing raceMs per query is OPTIONAL and is not required to defend proximity.

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.

Square-root weights

An earlier draft used Fibonacci weights; this BRC uses square-root weights.

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) = sqrt(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).

Implementations MUST compute weights in ordinary floating point, then apply floor only at the payout step. Do not integer-truncate the square roots before summing S.

Worked example, k = 5, R = 12. Weights below are IEEE-754 binary64 values of sqrt (ordinary floating point). Raw floors are computed first. The remainder is applied only after that sum.

S = 2.236067977499790 + 2.000000000000000 + 1.732050807568877 + 1.414213562373095 + 1.000000000000000 = 8.382332347441762

Sum of raw floors = 3 + 2 + 2 + 2 + 1 = 10. Remainder 12 - 10 = 2 is added to rank 1. Final payouts are 5, 2, 2, 2, 1. First place is strictly above fifth, and ranks 2 through 5 are non-zero.

Dividing the same weights rounded to three decimal places (2.236, 2.000, 1.732, 1.414, 1.000, S = 8.382) as exact decimals produces the same raw floors and the same remainder adjustment. Quotients below are the exact values, truncated:

floor(12 * 2.236 / 8.382) = floor(3.201145311381531...) = 3
floor(12 * 2.000 / 8.382) = floor(2.863278453829634...) = 2
floor(12 * 1.732 / 8.382) = floor(2.479599141016463...) = 2
floor(12 * 1.414 / 8.382) = floor(2.024337866857551...) = 2
floor(12 * 1.000 / 8.382) = floor(1.431639226914817...) = 1

Sum of those floors is 10. Remainder 2 added to rank 1 yields 5, 2, 2, 2, 1.

Worked example, k = 3, R = 20. Binary64:

S = sqrt(3) + sqrt(2) + sqrt(1) = 1.732050807568877 + 1.414213562373095 + 1.000000000000000 = 4.146264369941973

floor(20 * 1.732050807568877 / 4.146264369941973) = floor(8.354753354008237) = 8
floor(20 * 1.414213562373095 / 4.146264369941973) = floor(6.821627548042177) = 6
floor(20 * 1.000000000000000 / 4.146264369941973) = floor(4.823619097949584) = 4

Sum of raw floors = 18. Remainder 20 - 18 = 2 is added to rank 1, which receives 10. Payouts: 10, 6, 4.

The same floors follow from the three-decimal sketch S = 1.732 + 1.414 + 1.000 = 4.146, using exact decimal division (quotients truncated):

floor(20 * 1.732 / 4.146) = floor(8.355041003376748...) = 8
floor(20 * 1.414 / 4.146) = floor(6.821032320308731...) = 6
floor(20 * 1.000 / 4.146) = floor(4.823926676314520...) = 4

Sum of floors = 18, remainder 2, rank 1 receives 10. Payouts: 10, 6, 4.

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.

Non-normative: a host that slows down over time while remaining inside the paid top-K still loses weight on the square-root curve as soon as another host overtakes it. The curve is not flat. Clients MAY additionally decay a host's effective weight if that host's median collect latency worsens over a rolling window; this is local policy, not a consensus rule.

Host collect response

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

The client MUST hash the entire received payload. The client MUST accept the payload only if that hash equals the committed contentHash and the received length equals payloadSize. A prefix that hashes correctly is not sufficient. Truncation, early close, or trailing garbage is a failed collect.

On mismatch the client MUST NOT acknowledge the collect against that host, MUST NOT treat that host as having been paid for this queryId, and SHOULD lower local reputation for that host identity key.

Because the payment transaction is already bound to queryId and rank, a client that received matching complete bytes SHOULD broadcast the transaction.

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 square-root 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.

Reclamation window: after expires, hosts MUST stop advertising the grant immediately. The sender MAY sweep the grant output at any time after expires. This BRC does not require an extra delay block. Implementations SHOULD treat expires as the sole cut-off so value is not stranded between expiry and an undefined later deadline.

At collect time the recipient spends the grant into the square-root payout outputs.

Eligibility threshold

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.

This is an eligibility rule, not a moral rule about sharing. Isolated possession of a payload is not enough to collect when t > 1. Propagation is the ordinary way a host joins a threshold set. This BRC does not require a host to gossip; it only refuses payment when t is not met.

Withholding payload from other operators is allowed by the protocol and is usually self-defeating. The payload is obtainable from the chain or from any honest peer. The market users pay for is the chance that some host is up. An operator that starves every competitor reduces the collective uptime that makes overlay lookup trustworthy, including during that operator's own outages. The specified default strategy is: be fast; do not rely on exclusive possession.

Hosts SHOULD forward a newly stored payload to a random subset of advertised peers promptly. Gossip wire format remains BRC-34, BRC-23, and BRC-88.

Operator discretion

A query is an offer to pay for an answer. It does not bind any host. A host MAY refuse any query for any reason, including commercial, operational, or political reasons. Refusal is not a protocol violation.

Clients MAY keep a local note of which hosts declined which query classes and MAY use that note when building hostSetHint. This BRC does not require hosts to explain a refusal and does not treat refusal as slashable.

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 and default SLAP trackers

A new host set has no traffic and therefore no fees. The intended first operators are non-profit hosts that run at cost on the square-root curve (or flatter) and publish every topic they know. That non-profit baseline is the speed and coverage floor commercial hosts must beat. After several commercial hosts exist, clients MAY keep using the same curve; this BRC does not automatically steepen weights.

Default SLAP trackers: client software SHOULD ship a signed, versioned list of overlay host URLs (SLAP trackers) covering known topics. The default list is the diversity backbone for query broadcast. It exists so a client is not limited to whatever hosts happen to sit on its current network path.

Requirements:

1. The list MUST be signed by a well-known publisher key shipped with the client or retrieved over a pinned channel.
2. The list MUST carry a version and a fetched-at time.
3. The client MUST be able to replace the list with a user-supplied list. The default is a starting point, not a choke point.
4. hostSetHint SHOULD be initialized from the current tracker list, then refined by local reputation.
5. An eclipse of the client's local network path does not fill threshold t unless the attacker also displaces the tracker-derived host set. Compromising the publisher of the default list is a trust-root failure; clients mitigate by replacing the list.

An application treasury MAY additionally 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. This BRC does not require a subsidy.

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 square-root 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, 2, 2, 2, and 1 satoshis to the five host identity keys in ranking order, using the square-root payout function in this BRC (raw floors 3, 2, 2, 2, 1, then remainder 2 added to rank 1). 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 square-root payout 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 SHIP/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. Rank is client receive time.
• Geographic proximity and warm caches are legitimate. The protocol does not discount them.
• Threshold t is a liveness and safety tradeoff. High t raises the number of distinct keys required and also raises the chance a small live set cannot be paid.
• A client can collect bytes and withhold payment. Reputation and optional deposits remain the controls. On-chain escrow for dust fees is usually more expensive than the fee.
• Collect integrity is complete-payload hash equality. Prefix match is insufficient.
• A host MAY refuse any query. Clients may record that fact locally. The protocol does not punish refusal.
• Default SLAP trackers are a trust root. They MUST be signed, versioned, and replaceable.
• Canonicalization disagreement fails the threshold. Attest the table encoding, not the storage encoding.
• Collection grants are value. Authenticate the recipient before revealing grant transactions. After expires, stop advertising; sender may sweep.
• 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.
• 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