From be99e683bd8d4f5a35f6f4a1eb564930edb06ff3 Mon Sep 17 00:00:00 2001
From: Anthony Ettinger <anthony@chovy.com>
Date: Sat, 5 Sep 2026 19:12:45 -0700
Subject: [PATCH] Add pay2seed, paid2seed, pay2stream and paid2stream to the
 OpenSwarm family (#143)

* Add pay2seed to the OpenSwarm family: consent at upload and a paid seed market

OpenSwarm pays a seeder per verified piece served, and nothing pays anyone
to stay. An archive, a backup, a dataset waiting for its buyer or a
podcast's back catalogue earns nothing the month nobody downloads it, so
it dies the way every swarm always has. And nothing in BitTorrent says who
put a swarm there or whether they were allowed to, which is why a seeder
is presumed to be doing something wrong.

pay2seed is the member document for both halves. An attestation, signed
at upload with a fixed basis (own, licensed, open-license, public-domain,
personal) and a notice endpoint, is what a hub requires before it will
list anything; public claims get a claim window and a standing, and a
notice voids them. An offer escrows a budget at an ippay hub for a swarm,
public or private, to be held by M seeders for N days at a price per
GiB-month, bought over x402 exactly as a pass is. Seeders take leases,
prove each period by storage challenge or by a probe over the ordinary
wire, and are paid through the payee they already have. Public feeds ride
on ipdb; ipfile.pin on c0mpute is the same offer on the auction.

Also: the family table, stack diagram and registry rows; the ip seed
command group; PRD 0006; the protocol row on /openswarm.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SKAohrRkqLKVQL2cGCAkR5

* Split pay2seed into client and server halves, and add pay2stream and paid2stream

The rule is now in the names. pay2* is the client protocol: the side that
pays, over HTTPS, and plays. paid2* is the server protocol: the BitTorrent
side that earns. One hub implements both halves of a pair; a requester or
viewer implements only pay2*; a seeder, relay or gateway only paid2*.

pay2seed keeps consent, offers, the requester's market and notices.
paid2seed takes leases, storage challenges and probes over the wire,
GiB-month accrual and receipts, the seeder client, and the ipfile.pin
mapping.

pay2stream and paid2stream do the same for a live channel over iplive.
A broadcaster attests the channel (with the two rules that separate a
licensed rebroadcast from a stolen feed), buys relays by the hour, and
publishes listings; viewers buy tickets. Relays take leases and are
proven present by a verifier that pulls segments as a peer; a gateway is
a relay that also serves standard HLS, clear or sealed, with the M3U and
XMLTV pair every IPTV app asks for, so VLC, TiviMate, Kodi and a
television play a paid swarm with nothing installed. Ace Stream showed
BitTorrent can carry live TV to millions; this is that with consent,
payment and an open spec.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SKAohrRkqLKVQL2cGCAkR5

* pay2seed: encrypted by default, access as the product, a README in every swarm

The client encrypts by default and the hub never does: what the hub
manages is who may decrypt. A team is a named set of member keys with a
scope over the owner's swarms; the hub, as keeper, issues grants to
members when the owner is offline, with invitations that expire, roles,
an audit trail, and re-encryption on removal so the next version is
closed to whoever left. A few seats are free; above that the hub charges
per seat and per organisation, settled through the same pay plugins as
everything else. Seeding is priced at disk; access is where a hub earns,
and both sides earn: seeders rent disk, requesters sell access.

Public is not a fallback. Encryption off is an explicit act, and a
public swarm is attested, listed, kept and rendered exactly as a private
one is; the only difference is who can read it.

Every swarm on the market carries a README.md at its root, no
exceptions, and the attestation carries its Markdown and the hash of
the copy inside the swarm, so the hub renders it as the swarm's page
without a key. Relative links resolve into the swarm and are gated the
way the files are.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SKAohrRkqLKVQL2cGCAkR5

* pay2seed: 1 percent, ads on the free tier, and agents as sellers

Three things the specs did not say. The reference hub takes 1 percent of
any payment that crosses it, charged to whoever is paying and never
deducted from a seeder or a relay, so a quoted price is what the
publisher gets and a promised floor is what the seeder is paid.

Public swarms are free to fetch and free to list, and an advertisement on
the swarm README page is what pays for that. The ad is on the hub page
and nowhere else: never inside a swarm, never injected into a file, a
segment or a playlist, and never in the catalogue or the market API. A
requester who wants no ad buys a seat instead. A free-to-watch channel
works the same way.

And a requester is a key, not a person. An agent can attest what it made,
price access, sell tickets, take payment through its own payee and spend
what it earns keeping its own work online. The consent rules do not
soften because a machine signed them, and the reference hub asks an
agent public attestation to name a responsible operator key so somebody
is reachable when a notice arrives.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SKAohrRkqLKVQL2cGCAkR5

* Fix CI: number the PRD requirements and advance the next-id assertion

Two checks the new PRD tripped, both by existing rather than by being
wrong.

The collection validator wants requirements as numbered R# entries and
0006 used a plain ordered list, so it reported OP-L-NO-REQUIREMENTS.
Rewritten as R1 to R7 with priorities, one capability per entry, and the
implementation tracking moved to a paragraph under them where it is not
pretending to be a requirement.

The MCP standards test asserts what the next free PRD id is, and its own
comment says that advances with every PRD added. Adding 0006 makes it
0007.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SKAohrRkqLKVQL2cGCAkR5

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
---
 apps/logicsrc-web/src/app/openswarm/page.tsx |   6 +-
 docs/openswarm.md                            |  23 +
 docs/openswarm/cli.md                        |  38 ++
 docs/openswarm/ippay.md                      |  10 +-
 docs/openswarm/paid2seed.md                  | 325 +++++++++++
 docs/openswarm/paid2stream.md                | 276 +++++++++
 docs/openswarm/pay2seed.md                   | 554 +++++++++++++++++++
 docs/openswarm/pay2stream.md                 | 260 +++++++++
 docs/openswarm/spec.md                       |  13 +
 packages/logicsrc-mcp/src/standards.test.ts  |   2 +-
 prd/0006-add-pay2seed-spec.md                | 246 ++++++++
 prd/README.md                                |   1 +
 12 files changed, 1751 insertions(+), 3 deletions(-)
 create mode 100644 docs/openswarm/paid2seed.md
 create mode 100644 docs/openswarm/paid2stream.md
 create mode 100644 docs/openswarm/pay2seed.md
 create mode 100644 docs/openswarm/pay2stream.md
 create mode 100644 prd/0006-add-pay2seed-spec.md

diff --git a/apps/logicsrc-web/src/app/openswarm/page.tsx b/apps/logicsrc-web/src/app/openswarm/page.tsx
index b9b83be..9db3725 100644
--- a/apps/logicsrc-web/src/app/openswarm/page.tsx
+++ b/apps/logicsrc-web/src/app/openswarm/page.tsx
@@ -17,7 +17,11 @@ const PROTOCOLS: Array<[name: string, line: string]> = [
   ["ipaudio", "Audio releases and tracks on ipfile swarms: renditions, seek tables, gapless, royalties"],
   ["ipvideo", "Video on demand: CMAF renditions, segment index, subtitles, thumbnails, an HLS bridge"],
   ["iplive", "Live streams: segment fan-out over paid relays with backpressure"],
-  ["ipname", "How a Moshpit name or a domain resolves to a publisher key and a catalogue"]
+  ["ipname", "How a Moshpit name or a domain resolves to a publisher key and a catalogue"],
+  ["pay2seed", "Client protocol for paid seeding: consent at upload, seed offers with escrowed budgets, the requester's market"],
+  ["paid2seed", "Server protocol for paid seeding: leases, storage challenges and probes over the wire, GiB-month settlement, the seeder client"],
+  ["pay2stream", "Client protocol for paid live streams: consent for channels, relay offers by the hour, tickets, watching on any HLS player"],
+  ["paid2stream", "Server protocol for paid live streams: relay leases, presence proofs, gateways serving standard HLS with an M3U and EPG"]
 ];
 
 const ROLES: Array<[role: string, work: string, paid: string]> = [
diff --git a/docs/openswarm.md b/docs/openswarm.md
index 61393a4..aedd2ae 100644
--- a/docs/openswarm.md
+++ b/docs/openswarm.md
@@ -34,6 +34,10 @@ a different product. The member protocols keep their `ip` names.
 | `ipvideo` | Video on demand on `ipfile` swarms: CMAF renditions, segment index, subtitles, thumbnails | [`ipvideo.md`](./openswarm/ipvideo.md) |
 | `iplive` | Live streams: segment fan-out over peers, paid relays, backpressure | [`iplive.md`](./openswarm/iplive.md) |
 | `ipname` | How a Moshpit name resolves to a publisher key and a catalogue | [`ipname.md`](./openswarm/ipname.md) |
+| `pay2seed` | Client protocol for paid seeding: consent at upload, seed offers with escrowed budgets, the requester's market | [`pay2seed.md`](./openswarm/pay2seed.md) |
+| `paid2seed` | Server protocol for paid seeding: leases, storage challenges and probes over the wire, GiB-month settlement, the seeder client | [`paid2seed.md`](./openswarm/paid2seed.md) |
+| `pay2stream` | Client protocol for paid live streams: consent for channels, relay offers, tickets and listings, watching as a peer or on any HLS player | [`pay2stream.md`](./openswarm/pay2stream.md) |
+| `paid2stream` | Server protocol for paid live streams: relay leases per hour, presence proofs, gateways serving standard HLS, M3U and EPG | [`paid2stream.md`](./openswarm/paid2stream.md) |
 
 Supporting documents:
 
@@ -50,6 +54,10 @@ Supporting documents:
   |  ipaudio      ipvideo      iplive         ipdb (catalogue)    |
   |  releases     titles       channels       feeds, entries      |
   +---------------------------------------------------------------+
+  |  pay2seed / paid2seed        |  pay2stream / paid2stream      |
+  |  consent, offers, market     |  consent, relay offers, tickets |
+  |  leases, challenges, payout  |  leases, presence, HLS gateways |
+  +------------------------------+--------------------------------+
   |  ipfile: manifest, per-file key pair, encrypted pieces,       |
   |          key grants, credit window, vouchers per served piece |
   +-------------------------------+-------------------------------+
@@ -132,6 +140,20 @@ serves more than the window unpaid.
 Its head is a BEP 44 mutable item under the feed key, so any DHT node can find
 the latest catalogue of any publisher with one `get`.
 
+**One seed market, one stream market.** A `pay2seed` offer is money
+escrowed at a hub for a swarm to be kept for a period, public or private,
+and it cannot be listed without a signed attestation of who put the data
+there and on what basis. On the `paid2seed` side, seeders take leases,
+prove they hold and serve the pieces every period, and are paid per
+GiB-month. `pay2stream` and `paid2stream` do the same for a live channel:
+a broadcaster attests it and buys relays by the hour, relays and gateways
+prove they are online and serving, and a gateway turns the swarm into
+standard HLS so any television plays it. The naming is the rule: `pay2*`
+is the client protocol, the side that pays over HTTPS; `paid2*` is the
+server protocol, the BitTorrent side that earns. It is how a torrent
+client becomes a legitimate file sharer: consent on the way in, proof on
+the way out, and a payout for staying.
+
 ## What it does not define
 
 A media player. Transcoding settings beyond what a manifest must declare. A
@@ -146,6 +168,7 @@ key and the spec says so.
 | Browser WebTorrent player, hybrid Node seeder, wss trackers | `profullstack/media-streamer` (bittorrented.com) | Speaks the vanilla wire this family extends; needs the `ipfile` extension to pay |
 | DHT crawl (bitmagnet) and `/dht` browse | `profullstack/media-streamer`, `dht-infohash-crawler` | Observes `ipfile` swarms as opaque infohashes; `ipdb` is how it would learn what they are |
 | Pay-per-pass grants, HLS manifest sealing | `media-streamer` IPTV and seedbox rails | The central-proxy version of what `ippay` moves into the swarm |
+| Headless seeder daemon with an add API and per-torrent seed time | `torlink` (`torlnk serve`) | The `pay2seed` seeder client, once it polls a market and answers challenges |
 | x402 v2 offer, `X-PAYMENT` proof, verify and settle | `profullstack/x402-gateway`, CoinPay | `ippay` pass purchase reuses it unchanged |
 | CloudEvents 1.0 + Standard Webhooks signing | `profullstack/autoblog` | Every OpenSwarm event uses the same envelope and headers |
 | MTP/1 post-quantum transport, name pins | `profullstack/moshpit-transport`, `moshpit-proxy` | Optional tunnel for native peer links; `ipname` pin kind |
diff --git a/docs/openswarm/cli.md b/docs/openswarm/cli.md
index b145352..3e01f68 100644
--- a/docs/openswarm/cli.md
+++ b/docs/openswarm/cli.md
@@ -130,6 +130,44 @@ ip node hello <peer address>                       # diagnostic: handshake and p
 A c0mpute worker embeds the same library; `c0mpute worker start --openswarm`
 is the daemon form and `ip` is the operator's tool.
 
+### 2.10 Seed and stream markets
+
+```
+ip seed attest (<file key> | <infohash> | <magnet>) --basis own|licensed|open-license|public-domain|personal
+              [--license <spdx>] [--notice <url|mailto>] [--description <text>] [--public | --private]
+ip seed offer  (<file key> | <infohash> | --feed <feed key>) --hub <url> --days <n> --seeders <min>[,<max>]
+              [--price <usd per GiB-month>] [--proof-hours <n>] [--tracker <url>]...
+ip seed offers [--hub <url>] [--public | --private] [--basis <b>] [--min-price <usd>] [--max-size <bytes>]
+ip seed take   <offer id> --hub <url>                # take a lease, fetch, seed until it ends
+ip seed leases [--hub <url>] [--status proven|fetching|lapsed|ended]
+ip seed status <offer id | lease id>
+ip seed void   <offer id>                            # requester: void and refund the unearned budget
+ip seed notice <attestation id> --kind rights|illegal|personal-data|other --statement <text>
+ip team create <name> --hub <url> [--scope <file key>|--publisher <key>]...
+ip team invite <team> --to <email|ipname|key> [--role admin|member|readonly] [--expires <days>]
+ip team accept <invite id>
+ip team remove <team> <key> [--no-rotate]
+ip team grant  <team> --file <file key>          # a member fetching their sealed grant
+ip team audit  <team> [--since <time>]
+```
+
+```
+ip stream offer  <channel key> --hub <url> --from <time> --to <time> --relays <min>[,<max>]
+                [--price <usd per relay-hour>] [--gateway-bonus <bps>] [--region <r>]...
+ip stream ticket <channel key> --hub <url> --hours <n> [--gateway <url>]     # prints the HLS, M3U and EPG URLs
+ip stream listing <channel key> --title <text> --from <time> --to <time> [--price <usd>]
+ip stream relay  <offer id> --hub <url> [--gateway --base <url> --mode clear|sealed]
+ip stream relays [--hub <url>]
+```
+
+`ip seed attest` is the consent step and is what `ip file add --public`,
+`ip file pin` and `ip live create` call first; `ip seed offer` on a private file key includes a
+pass for the seeders when the manifest charges per GiB. `ip seed take` is
+what a torlink daemon does on its own from `ip seed offers`; here it is the
+manual form, and it sets the swarm's seed time to the lease's end so the
+client's reaper cannot drop it early. Everything returns the record ids
+(`pay2seed` §7.2) and, for `offers`, the projected `earnedUsd` per lease.
+
 ## 3. Output examples
 
 ```
diff --git a/docs/openswarm/ippay.md b/docs/openswarm/ippay.md
index 721b23b..7540d7a 100644
--- a/docs/openswarm/ippay.md
+++ b/docs/openswarm/ippay.md
@@ -261,7 +261,7 @@ Published at `GET <base>/.well-known/openswarm-hub.json`:
     "eip155:137": "0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359",
     "eip155:1": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
   },
-  "minHubBps": 300,
+  "minHubBps": 100,
   "payout": { "minUsd": "1.000000", "schedule": "daily" },
   "passDays": 30,
   "createdAt": "2026-09-05T00:00:00.000Z",
@@ -280,6 +280,14 @@ lists the hub's `base`, from TLS to that base, and optionally from an MTP/1
 pin. `minHubBps` is the least `split.hubBps` a manifest may set for this hub
 to sell passes for it.
 
+The reference hub takes **1 percent** (`minHubBps: 100`), on every payment
+that crosses it: a pass, a key grant, a seed offer, a relay offer, a
+ticket. It is charged to whoever is paying and never deducted from a
+seeder's or a relay's earnings, so what a publisher quotes is what a
+publisher gets and what a seeder is promised is what a seeder is paid. A
+hub setting a higher floor says so in this record, and a manifest naming
+it can refuse.
+
 ### 5.2 API
 
 All bodies are JSON. Records are verified on receipt.
diff --git a/docs/openswarm/paid2seed.md b/docs/openswarm/paid2seed.md
new file mode 100644
index 0000000..31b965d
--- /dev/null
+++ b/docs/openswarm/paid2seed.md
@@ -0,0 +1,325 @@
+# paid2seed: The Server Protocol for Paid Seeding
+
+Status: 0.1 draft. Member of the [OpenSwarm](../openswarm.md) family.
+Depends on the [core](./spec.md), [`ipfile`](./ipfile.md) and
+[`ippay`](./ippay.md). Its client half is [`pay2seed`](./pay2seed.md).
+
+## 1. Scope
+
+`paid2seed` is the side that gets paid. It is spoken by a seeder, a
+BitTorrent client with disk and uptime to sell, to a hub over HTTPS and to
+the swarm over the ordinary wire. It defines:
+
+- **Leases.** The hub's binding of one seeder to one `pay2seed.offer` for
+  one period at one price.
+- **Proof of seeding.** Storage challenges answered from held pieces, and
+  probes in which a verifier fetches pieces over BEP 3 or the `ipfile`
+  extension. Both work on a vanilla torrent, which is what makes seeding
+  a public swarm payable.
+- **Settlement.** GiB-month accrual per proven period, receipts, and
+  payout through the `ippay` payee a seeder already has for vouchers.
+- **The seeder client**: how a torrent client polls a market, takes work,
+  seeds it, proves it, and resumes after a restart. torlink's headless
+  daemon is the reference.
+
+Consent, offers, the requester's view and notices are
+[`pay2seed`](./pay2seed.md). A hub implements both. A seeder client
+implements only this document.
+
+### Non-goals
+
+Anything about what the data is. A seeder sees an infohash or a file key,
+a size, a basis and a visibility, and decides whether to hold it. It is
+never asked to judge it and never able to read a private swarm.
+
+## 2. Terminology
+
+- **Seeder.** An identity that holds a lease and serves the swarm.
+- **Verifier.** Whoever issues challenges and probes: the hub, a c0mpute
+  verifier node, or the requester. The offer names who may.
+- **Lease.** One seeder's share of an offer (§3). **Period.** The unit of
+  accrual and proof, `offer.proof.everyHours` long.
+- Other terms as `pay2seed` §2.
+
+## 3. Leases
+
+### 3.1 Record
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "paid2seed.lease",
+  "hub": "ed25519:c9f1…",
+  "offer": "sha256:1b7f…",
+  "seeder": "ed25519:a41e…",
+  "slot": 1,
+  "priceUsdPerGibMonth": "0.150000",
+  "startsAt": "2026-09-05T18:30:00.000Z",
+  "endsAt": "2026-10-05T18:00:00.000Z",
+  "graceHours": 24,
+  "createdAt": "2026-09-05T18:30:00.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:c9f1…", "sig": "…" }]
+}
+```
+
+| Field | Rule |
+| --- | --- |
+| `offer` | Record id of the `pay2seed.offer`. |
+| `seeder` | The seeder key. MUST be a registered `ippay` payee (§5.4). |
+| `slot` | 1-based, at most `offer.seeders.max`. One lease per seeder per offer. |
+| `priceUsdPerGibMonth` | Copied from the offer at lease time so a later edit never changes what was agreed. |
+| `graceHours` | Time from `startsAt` in which the seeder MUST pass its first proof, or the lease is `abandoned` and the slot reopens. Long enough to fetch the swarm. |
+
+A lease is `fetching` until its first proof, `proven` while its most recent
+period passed, `lapsed` when a period failed, `abandoned` after
+`graceHours` without a first proof, `ended` at `endsAt`, and `voided` with
+its offer.
+
+### 3.2 Taking and losing a lease
+
+`POST /leases` with `{ "offer": <id>, "seeder": <key>, "sig" }`, `sig` by
+the seeder key over `"openswarm:paid2seed:lease:v1" || offer id`. The hub
+answers `201` with the lease, `409` when the offer has no free slot or this
+seeder already holds one, or `403` when the seeder's standing (§6.3) is
+below the offer's or hub's floor.
+
+A hub SHOULD hand out slots in order of standing and MUST NOT hand out
+more than `seeders.max`. A seeder SHOULD NOT take a lease it cannot serve
+within `graceHours`; an abandoned lease counts against standing. When an
+offer is voided (`pay2seed` §8) every lease on it is `voided`, the hub
+pushes `paid2seed.lease.voided`, and a seeder learns of it on its next
+poll at the latest.
+
+## 4. Proof of seeding
+
+### 4.1 Storage challenges
+
+Once per period, a verifier named in the offer sends the seeder:
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "paid2seed.challenge",
+  "lease": "sha256:5c02…",
+  "period": 7,
+  "nonce": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f",
+  "pieces": [17, 2048, 91, 4400],
+  "deadline": "2026-09-07T12:10:00.000Z",
+  "createdAt": "2026-09-07T12:00:00.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:c9f1…", "sig": "…" }]
+}
+```
+
+The seeder answers within `deadline`:
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "paid2seed.proof",
+  "challenge": "sha256:9d3a…",
+  "answers": ["sha256:…", "sha256:…", "sha256:…", "sha256:…"],
+  "createdAt": "2026-09-07T12:00:04.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:a41e…", "sig": "…" }]
+}
+```
+
+Each answer is `SHA-256(nonce || piece bytes)` for the piece at that index,
+which a verifier holding a copy can check and which cannot be answered
+from the piece hash alone. `pieces` MUST be at least four indices chosen
+uniformly at random per challenge; `deadline` MUST be at least ten minutes
+after `createdAt`, enough to read four pieces from a spinning disk and not
+enough to fetch them from the swarm.
+
+### 4.2 Probes
+
+A verifier connects to the seeder as an ordinary peer, over BEP 3 for a
+vanilla torrent or the `ipfile` extension for a private swarm, and requests
+the challenge's pieces. The seeder's ordinary serving is the proof; the
+verifier records `{ "lease", "period", "pieces", "receivedBytes", "peer" }`
+signed by its own key, `type` still `paid2seed.proof`. A probe MUST fetch
+from the seeder's own announced address; a swarm being alive is not
+evidence that this seeder is keeping it alive.
+
+For a `private` swarm whose `pricing.perGib` is non-zero the verifier pays
+vouchers for the probe like any leecher, and those are the seeder's in the
+usual way. Hubs SHOULD prefer probes for public swarms and challenges for
+private swarms they already pin.
+
+### 4.3 Delivery
+
+A hub pushes challenges to a seeder's registered webhook when it has one,
+and otherwise leaves them to be polled from `GET /leases/<id>/challenges`.
+A seeder without a webhook MUST poll at least every `everyHours / 4`
+hours. `deadline` is measured from `createdAt`, not delivery, so a seeder
+that polls slowly fails challenges; the cadence is the seeder's to meet.
+
+## 5. Settlement
+
+### 5.1 Accrual
+
+A lease earns, for each period in which its proof passed:
+
+```
+earnedUsd = priceUsdPerGibMonth * (sizeBytes / 2^30) * (everyHours / 720)
+```
+
+in integer micro-USD, rounding down. A failed or missed period earns
+nothing and moves the lease to `lapsed`; two consecutive failures end it
+and reopen the slot.
+
+### 5.2 Receipts
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "paid2seed.receipt",
+  "lease": "sha256:5c02…",
+  "period": 7,
+  "proof": "sha256:e77b…",
+  "earnedUsd": "0.002604",
+  "balanceUsd": "0.018228",
+  "createdAt": "2026-09-07T12:00:05.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:c9f1…", "sig": "…" }]
+}
+```
+
+### 5.3 Fees and payout
+
+The hub's fee is charged to the requester at purchase, `hubBps` of
+`budgetUsd` with `hubBps` no less than the hub record's `minHubBps`; it is
+never deducted from a seeder's earnings. Payout is `ippay` §5.6, on the
+same schedule and floor as voucher earnings.
+
+### 5.4 Payees
+
+A seeder is an `ippay` payee (`ippay` §6.1). Registering once covers
+vouchers, key grants and leases. A seeder key that is not registered
+cannot take a lease, because there would be nowhere to pay.
+
+## 6. The seeder's hub
+
+### 6.1 API, seeder side
+
+Paths relative to the `pay2seed.base` in the hub record (`pay2seed`
+§6.1). The requester side is `pay2seed` §6.2.
+
+| Method and path | Auth | Purpose |
+| --- | --- | --- |
+| `GET /offers?visibility&basis&minPrice&maxSize&feed&status` | none | The market: open offers with free slots. |
+| `POST /leases` | seeder signed | Take a slot (§3.2). |
+| `GET /leases/<id>` | none | The lease, status, periods proven, `earnedUsd`. |
+| `GET /seeders/<key>/leases?status` | none | A seeder's leases; what a client resumes after a restart. |
+| `GET /leases/<id>/challenges?since` | seeder | Pending challenges for a seeder that cannot receive them pushed. |
+| `POST /proofs` | seeder or verifier signed | Answer a challenge or report a probe. Returns the receipt. |
+| `GET /seeders/<key>` | none | `{ "standing", "leases", "proven", "failed", "abandoned", "balanceUsd" }`. |
+| `POST /webhooks` | signed | Register a CloudEvents endpoint for a seeder key. |
+
+### 6.2 The market listing
+
+`GET /offers` is what a seeder client shows its operator, or chooses from
+on its own. Each row carries the offer, the attestation's `basis`,
+`description` and `visibility`, the free slot count, and the projected
+`earnedUsd` for a full lease. A client MUST show `basis` and `visibility`
+wherever it shows an offer, so an operator knows whether they are being
+asked to hold ciphertext for a stranger's backup or to seed an openly
+licensed dataset in the clear.
+
+### 6.3 Standing
+
+Seeder standing is `proven - 2 * failed - 3 * abandoned` over the trailing
+year, floored at zero. Requester standing is `honoured - 3 * voided`, the
+same way. Both are public and are one hub's opinion signed by that hub; a
+second hub MAY read it and MAY ignore it.
+
+## 7. Seeder client behaviour
+
+A seeder client (torlink's headless daemon is the reference) does the
+following, and a conformant one does all of it:
+
+1. Holds a seeder key, registered as an `ippay` payee with a payout
+   address, and stores the key as an OpenCreds `key` item.
+2. Polls `GET /offers` on the hubs it is configured for, filtered by the
+   operator's policy: which `visibility` and `basis` values to accept, the
+   minimum `priceUsdPerGibMonth`, the maximum `sizeBytes`, free disk to keep
+   in reserve.
+3. Takes a lease, fetches the swarm (as a paying peer when `offer.pass` is
+   set), adds the offer's `trackers`, and seeds with a per-torrent seed time
+   of at least `lease.endsAt`, so its own reaper never drops a swarm it is
+   being paid to keep.
+4. For a feed offer, follows the feed (`ipdb` §5.4), fetches each new
+   segment within one period of its appearance in the head, seeds all of
+   them, and re-announces the head as a BEP 44 mutable item at least once
+   per period so the catalogue stays findable when the publisher is
+   offline.
+5. Answers challenges from local pieces within `deadline`, and serves
+   probes as ordinary peer traffic.
+6. On restart, resumes every lease in
+   `GET /seeders/<key>/leases?status=proven,fetching` before taking new ones.
+7. Stops seeding and deletes the data when a lease ends or is voided,
+   unless the operator has chosen to keep it; for a `private` swarm the
+   ciphertext is worthless without a grant, and for a `personal` one it
+   MUST be deleted.
+8. Shows the operator, for every held lease, the `basis`, `visibility`,
+   `earnedUsd` so far, and the next challenge due.
+
+## 8. Relationship to `ipfile.pin`
+
+An `ipfile.pin` job (c0mpute §3.1) is a `pay2seed.offer` with
+`visibility: "private"`, `seeders.min = seeders.max = 1`, `days` and
+`proof.everyHours` copied, `priceUsdPerGibMonth` derived from
+`max_price_usd`, and c0mpute's storage challenge standing in for §4.1. A
+c0mpute node that wins such a job holds a lease in this document's sense
+and MAY report proofs to the hub to build standing there. A hub MAY
+republish a `pay2seed.offer` as an `ipfile.pin` job on the c0mpute auction
+when no other seeder takes it, which is how the market reaches the paid
+storage network without the requester doing anything.
+
+## 9. Events
+
+CloudEvents as core §8, `source` the hub base:
+
+| `type` | Data | Subscriber |
+| --- | --- | --- |
+| `pay2seed.attestation.registered`, `.honoured`, `.voided` | attestation id | requester |
+| `pay2seed.offer.listed`, `.active`, `.settled`, `.voided` | offer id, status | requester, market followers |
+| `paid2seed.lease.granted`, `.proven`, `.lapsed`, `.ended`, `.voided` | lease id, period, `earnedUsd` | seeder, requester |
+| `paid2seed.challenge.issued` | the challenge record | seeder |
+| `pay2seed.notice.received`, `.resolved` | notice id, outcome | requester |
+
+## 10. Security notes
+
+- **Sybil seeders.** One machine holding several leases on one offer under
+  several keys earns several times for one copy. `seeders.max` bounds the
+  loss; probes from distinct verifiers to the announced addresses, and a
+  hub refusing leases to keys that share a payout address on one offer,
+  bound it further. Standing makes it expensive to repeat.
+- **Answer relaying.** A seeder that holds nothing could fetch challenged
+  pieces from the swarm within `deadline`. Ten minutes is the floor; a hub
+  SHOULD set shorter deadlines for small swarms, and probes measure the
+  seeder's own serving rather than what it can fetch.
+- **Payout addresses are the identity that matters.** A seeder key is
+  cheap; the address it pays to is where a hub's Sybil checks bite.
+
+## 11. Implementations
+
+| Piece | Where | Status |
+| --- | --- | --- |
+| Reference hub, seeder side: leases, challenges, probes, receipts, standing | `profullstack/media-streamer` (bittorrented.com) | planned |
+| Seeder client: market polling, leases, per-lease seed time, challenges | `torlink` (`torlnk serve` and `watch`) | planned; per-torrent seed time landed as baairon/torlink#186 |
+| Shared seeder client and records | `@profullstack/pay2seed` | planned |
+| Seeder and verifier on the storage network | `profullstack/c0mpute` via `ipfile.pin` | mapping in §8 |
+
+## 12. Conformance
+
+A **hub** is conformant on this side when it hands out leases as §3,
+issues at least one challenge or probe per period and pays only proven
+periods (§4, §5), and publishes seeder standing (§6.3). It MUST also be
+conformant to `pay2seed`.
+
+A **seeder client** is conformant when it does all of §7.
+
+## 13. Version history
+
+- 0.1 (2026-09-06): split out of the first pay2seed draft (2026-09-05) as
+  the server half; leases, challenges and probes, accrual and receipts,
+  the seeder API and client, the `ipfile.pin` mapping.
diff --git a/docs/openswarm/paid2stream.md b/docs/openswarm/paid2stream.md
new file mode 100644
index 0000000..bff5dd1
--- /dev/null
+++ b/docs/openswarm/paid2stream.md
@@ -0,0 +1,276 @@
+# paid2stream: The Server Protocol for Paid Live Streams
+
+Status: 0.1 draft. Member of the [OpenSwarm](../openswarm.md) family.
+Depends on the [core](./spec.md), [`iplive`](./iplive.md), [`ippay`](./ippay.md)
+and [`paid2seed`](./paid2seed.md). Its client half is
+[`pay2stream`](./pay2stream.md).
+
+## 1. Scope
+
+`paid2stream` is the side that gets paid to carry a live stream. It is
+spoken by relays and gateways: peers on the `iplive` wire that take a
+lease from a hub, stay online for a window, fan out segments, and, for a
+gateway, turn the swarm into standard HLS for any player. It defines:
+
+- **Leases** on a `pay2stream.offer`: one relay, one window, one price
+  per relay-hour.
+- **Proof of relaying.** Presence proofs by a verifier that connects as a
+  peer and pulls segments, and a served-bytes ratio so a relay that is
+  online and idle is not paid the floor for nothing.
+- **Settlement.** Relay-hour accrual, a gateway bonus, receipts, payout
+  through the `ippay` payee a relay already has for vouchers.
+- **The gateway role**: the record, the HLS presentation in clear and
+  sealed modes, the M3U and EPG, gateway-bound vouchers, and what a
+  gateway must do when a channel is voided.
+- **Regions and standing.**
+
+Consent, offers, tickets and the viewer are [`pay2stream`](./pay2stream.md).
+A hub implements both; a relay or gateway implements only this document.
+
+### Non-goals
+
+Deciding what a channel is. A relay sees a channel key, a basis, a
+visibility and a price, and decides whether to carry it.
+
+## 2. Terminology
+
+- **Relay, viewer, channel, head, segment, part, epoch, origin.** As
+  `iplive` §2.
+- **Gateway.** A relay that also speaks HTTP: presents the channel as HLS
+  and M3U, holds a grant, and signs vouchers on behalf of the HLS viewers
+  bound to it.
+- **Relay-hour.** One relay, connected and serving, for one hour.
+- **Period.** `offer.proof.everyMinutes` long.
+
+## 3. Leases
+
+A `paid2stream.lease` is a `paid2seed.lease` with `priceUsdPerRelayHour`
+in place of the GiB-month price, `graceMinutes` (default 5) in place of
+`graceHours`, a `window` copied from the offer, and a `gateway` boolean
+set when the relay commits to §5.
+
+`POST /relays` with `{ "offer", "relay", "regions", "gateway": bool,
+"sig" }`, `sig` by the relay key over `"openswarm:paid2stream:lease:v1" ||
+offer id`. `201` with the lease; `409` when no slot is free or the relay
+already holds one for this window; `403` below the standing floor. A
+relay MUST be online and announced in the channel's peer set within the
+grace window, and holds at most one lease per channel window. When an
+offer is voided every lease on it is `voided` and the hub pushes
+`paid2stream.lease.voided`.
+
+## 4. Proof and settlement
+
+### 4.1 Presence
+
+A leased relay is proven for a period when a verifier finds it, at its
+announced address, serving the channel: the verifier connects as an
+`iplive` peer, receives a `head` no older than two segments, requests one
+segment at each rendition in `capacity.renditions`, and receives them
+within one segment duration each. The verifier signs a
+`paid2stream.proof` with `{ "lease", "period", "head", "segments",
+"latencyMs" }`. A relay that is connected but answers `deny rate` to a
+verifier fails the period.
+
+For a gateway, the verifier also fetches the media playlist and one
+segment over HTTP (§5.3) and records `hls: true`.
+
+### 4.2 Served bytes
+
+Vouchers a relay redeems for this channel during the window are the
+second measure. A hub MAY require, per offer, a minimum ratio of served
+bytes to pulled bytes for a period to count, so a relay that is present
+and idle while others carry the viewers is not paid the floor for nothing.
+The default ratio is 1.0 after the first two periods.
+
+### 4.3 Accrual and receipts
+
+```
+earnedUsd = priceUsdPerRelayHour * (everyMinutes / 60) * (1 + gatewayBonusBps / 10000 if gateway)
+```
+
+per proven period, integer micro-USD, rounded down, credited to the
+relay's `ippay` payee balance with a `paid2stream.receipt` shaped as
+`paid2seed.receipt`. Two consecutive failed periods end the lease and
+reopen the slot. Vouchers are separate and additive; the hub's fee is the
+broadcaster's at purchase, never the relay's.
+
+### 4.4 Regions and standing
+
+A relay declares `regions` in its lease request, self-reported and
+verified only in the sense that a verifier records the latency it saw.
+Standing is `paid2seed` §6.3 with periods in place of days; a hub shows a
+relay's median verified latency per region beside it.
+
+## 5. Gateways and HLS
+
+A gateway is what makes this usable by a person with a television. Any
+relay MAY be one; a c0mpute node with `c0mpute:role:gateway` is expected
+to be one; the reference hub runs one.
+
+### 5.1 Record
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "paid2stream.gateway",
+  "gateway": "ed25519:a41e…",
+  "base": "https://gw-eu1.example.net/openswarm",
+  "regions": ["eu"],
+  "modes": ["clear", "sealed"],
+  "lowLatency": true,
+  "hubs": ["https://bittorrented.com/api/openswarm"],
+  "createdAt": "2026-09-10T09:00:00.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:a41e…", "sig": "…" }]
+}
+```
+
+Registered with `POST /gateways`; listed in `GET /gateways` and, per
+channel, in the `gateways` array of `GET /streams/<id>`. An origin MAY
+name preferred gateways in its channel record's `relays` block.
+
+### 5.2 Presenting a pass
+
+A gateway MUST accept the ticket three ways: `?pass=<base64url pass>` on
+the URL, as a cookie, and as `Authorization: Bearer`. It verifies the
+pass against the hub key and its scope (`ippay` §3.1), checks `expiresAt`,
+and MUST rate-limit failed presentations by source address. A pass bought
+against another gateway is valid here if the hub lists this gateway for
+the channel; the pass is the hub's record.
+
+### 5.3 HLS presentation
+
+For a channel it relays, a gateway serves:
+
+| Path | Body |
+| --- | --- |
+| `hls/<channel>/master.m3u8` | One `EXT-X-STREAM-INF` per rendition in the channel record, `CODECS` and `BANDWIDTH` from it, `EXT-X-INDEPENDENT-SEGMENTS`. |
+| `hls/<channel>/<rendition>.m3u8` | A media playlist rebuilt from the latest signed head: `EXT-X-MAP` for the init segment, one `EXTINF` per segment in the DVR window, `EXT-X-DISCONTINUITY` at a key epoch boundary in `sealed` mode, `EXT-X-PROGRAM-DATE-TIME` from the head's timestamp. With `lowLatency`, `EXT-X-PART` entries from `iplive` parts and `EXT-X-SERVER-CONTROL` with `CAN-BLOCK-RELOAD=YES`. |
+| `hls/<channel>/<rendition>/<seq>.m4s` | The segment. |
+| `hls/<channel>/init/<rendition>.mp4` | The init segment. |
+| `hls/<channel>/key/<epoch>` | `sealed` mode only: the 16-byte HLS key, to a pass holder. |
+
+**`clear` mode.** The gateway decrypts each `iplive` segment with the
+grant it holds and serves plaintext over TLS. Every IPTV player
+understands it, and it is exactly as private as the TLS session and the
+pass. A gateway MUST NOT serve `clear` for a channel whose record has
+`keys.modes` without `gateway` in it; that is how an origin refuses to be
+decrypted by anyone but viewers.
+
+**`sealed` mode.** The gateway re-encrypts each segment under a
+per-epoch AES-128-CBC key and writes
+`EXT-X-KEY:METHOD=AES-128,URI="key/<epoch>"`, so the playlist is standard
+HLS with standard encryption and the key endpoint is where the pass is
+checked. Segments may then be cached by any HTTP cache in the path. The
+re-encryption is the gateway's cost; the origin's content key never
+leaves the `iplive` layer.
+
+Both modes are one segment behind the peer edge; `lowLatency` narrows that
+to one part.
+
+### 5.4 The M3U and the EPG
+
+`GET <base>/channels.m3u?pass=<pass>` returns `#EXTM3U` with one
+`#EXTINF` per channel the pass is in scope for, carrying `tvg-id`,
+`tvg-name`, `tvg-logo` and `group-title` from the channel record's
+`title`, `logo` and `group` fields (added to `iplive.channel` as OPTIONAL
+by this document), each pointing at that channel's `master.m3u8` with the
+pass attached. `GET <base>/epg.xml?pass=` returns XMLTV built from the
+`pay2stream.listing` entries of those channels. This pair is what every
+IPTV app asks for on setup, and it is how a gateway looks, to a
+television, like the provider it replaces.
+
+### 5.5 Gateway-bound vouchers
+
+A gateway signs vouchers to its upstream for what it pulls, as any relay
+does, and signs vouchers to itself on behalf of each bound viewer for what
+it serves them, bounded by that viewer's ticket `capUsd`. It MUST NOT
+sign a voucher for bytes it did not serve; the hub compares signed bytes
+against the segment count in the window, and the gateway's standing is
+what it loses.
+
+### 5.6 Stopping
+
+On `pay2stream.channel.voided` a gateway MUST stop serving the channel
+within one segment duration, answer its playlists with `410`, and drop
+the channel from `channels.m3u`. A gateway that keeps serving a voided
+channel is delisted and its standing zeroed.
+
+## 6. Hub API, relay and gateway side
+
+Relative to `pay2stream.base`. The client side is `pay2stream` §7.
+
+| Method and path | Auth | Purpose |
+| --- | --- | --- |
+| `GET /streams?open&region` | none | Offers with free relay slots, and what each pays per hour. |
+| `POST /relays` | relay signed | Take a lease (§3). |
+| `GET /relays/<key>` | none | Standing, leases, median latency per region. |
+| `GET /relays/<key>/leases?status` | none | What a relay resumes after a restart. |
+| `POST /proofs` | verifier signed | Report a presence proof; returns the receipt. |
+| `POST /gateways` | gateway signed | Register or update a gateway record. |
+| `GET /passes/<id>` | none | Verify a presented ticket against the hub's record (`ippay` §5.2). |
+| `POST /vouchers` | none | Redeem, as `ippay` §5.3; gateway-bound vouchers carry `boundBy`. |
+| `POST /webhooks` | signed | Register a CloudEvents endpoint for a relay or gateway key. |
+
+## 7. Relay and gateway client behaviour
+
+1. Holds a relay key, registered as an `ippay` payee, stored as an
+   OpenCreds `key` item.
+2. Polls `GET /streams?open` on its hubs, filtered by the operator's
+   policy: which `basis` values to carry, minimum price per hour,
+   regions, upload to keep in reserve.
+3. Takes a lease, connects to the channel's peers using the offer's pass,
+   accepts up to `capacity.downstreamPerRelay` downstream peers, and
+   stays for the window.
+4. As a gateway: holds a grant, serves §5.3 in at least `clear` mode,
+   §5.4, and the three pass presentations of §5.2.
+5. Answers verifiers as ordinary peer traffic, and over HTTP for the
+   gateway probe.
+6. On restart, resumes leases from `GET /relays/<key>/leases?status=proven`.
+7. Stops on a void (§5.6). Shows the operator, per lease, the basis,
+   earned so far, viewers served, and the next period due.
+
+## 8. Events
+
+| `type` | Data | Subscriber |
+| --- | --- | --- |
+| `pay2stream.offer.listed`, `.active`, `.settled`, `.voided` | offer id | broadcaster, market followers |
+| `paid2stream.lease.granted`, `.proven`, `.lapsed`, `.ended`, `.voided` | lease id, period, `earnedUsd` | relay, broadcaster |
+| `pay2stream.channel.live`, `.ended`, `.voided` | channel key, gateways | relays, gateways, viewers with tickets |
+| `pay2stream.listing.published` | listing id | market followers |
+
+## 9. Security notes
+
+- **Presence without service.** The served-bytes ratio (§4.2) is what
+  stops a relay from collecting the floor while doing nothing.
+- **Gateway over-signing.** Bounded per viewer by `capUsd`, and in
+  aggregate by the hub's segment-count check and the gateway's standing.
+- **Clear mode is clear.** A gateway is trusted with plaintext by the
+  origin's choice of `keys.modes`; an origin that does not want that
+  offers `sealed` only, or no gateways at all.
+- **Relay regions are self-declared.** Only the verified latency beside
+  them is evidence.
+
+## 10. Implementations
+
+| Piece | Where | Status |
+| --- | --- | --- |
+| Reference hub, server side, and the hub's own gateway | `profullstack/media-streamer` (bittorrented.com), Live TV | planned; the IPTV resale rail (`/api/public/iptv/<slug>/stream`) already seals HLS manifests per session, the central version of §5.3 |
+| Gateway on the storage network | `profullstack/c0mpute` `c0mpute:role:gateway`, DIP 0019 playlist rebuild | mapping; DIP 0019 already rebuilds playlists from swarmed segments |
+| Relay client | `torlink` with the `iplive` extension | planned |
+| Shared relay and gateway code | `@profullstack/pay2seed` (one package for the four protocols) | planned |
+
+## 11. Conformance
+
+A **hub** on this side: leases as §3, at least one presence proof per
+period and pays only proven periods (§4), lists gateways per channel,
+pushes `channel.voided` to relays and gateways.
+
+A **relay**: `iplive` §12 as a relay, plus §7. A **gateway**: a relay,
+plus §5.2, §5.3 in at least `clear` mode, §5.4, §5.5 and §5.6.
+
+## 12. Version history
+
+- 0.1 (2026-09-06): first draft, as the server half; leases per
+  relay-hour with a gateway bonus, presence proofs and the served-bytes
+  ratio, gateways with clear and sealed HLS, the M3U and EPG pair,
+  gateway-bound vouchers, stopping on a void.
diff --git a/docs/openswarm/pay2seed.md b/docs/openswarm/pay2seed.md
new file mode 100644
index 0000000..50350a7
--- /dev/null
+++ b/docs/openswarm/pay2seed.md
@@ -0,0 +1,554 @@
+# pay2seed: The Client Protocol for Paid Seeding
+
+Status: 0.1 draft. Member of the [OpenSwarm](../openswarm.md) family.
+Depends on the [core](./spec.md), [`ipfile`](./ipfile.md), [`ippay`](./ippay.md)
+and [`ipdb`](./ipdb.md). Its server half is [`paid2seed`](./paid2seed.md).
+
+## 1. Scope
+
+`pay2seed` is the side that pays. It is spoken over HTTPS by a requester, a
+person or a program that wants data kept alive on a swarm by machines they
+do not control, to a hub. It defines:
+
+- **Consent.** A signed attestation, made when the data is added, that the
+  requester has the right to distribute it and accepts notice. A hub MUST
+  NOT list an offer without one. This is the part BitTorrent never had.
+- **Offers.** A request to store, archive or share a swarm for a period,
+  with a budget escrowed at the hub, a number of seeders wanted, and a
+  proof cadence. Public offers cover vanilla torrents and `ipdb` feeds;
+  private offers cover `ipfile` swarms whose ciphertext a seeder holds
+  without ever reading.
+- **Encryption by default, and access.** A private swarm is `ipfile`
+  ciphertext under a key the requester holds. Who else may decrypt it is
+  a team: members the requester invites, and a keeper that issues grants
+  to them when the requester is offline. This is what a hub charges for.
+  Public is encryption switched off by an explicit act, and is listed and
+  kept like anything else.
+- **The requester's view of the market**, of standing, and of notices.
+
+Everything on the BitTorrent side, how a seeder takes a lease, proves it
+holds and serves the pieces, and is paid, is [`paid2seed`](./paid2seed.md).
+The two documents share one hub, one set of record types, and one
+lifecycle; the split is who speaks which half. A hub implements both. A
+requester client implements only this one. A seeder client implements
+only the other.
+
+`ipfile.pin` ([c0mpute](./c0mpute.md) §3.1) is this document's offer
+carried on c0mpute's job auction; `paid2seed` §8 gives the mapping.
+
+### Non-goals
+
+Judging content. A hub sees an attestation, an infohash and, for a private
+swarm, nothing else. It enforces that the attestation exists, is signed and
+is honoured on notice; whether it is true is the requester's liability, and
+§8 is how a false one is undone. Not a DRM. Not a token. Not a replacement
+for `ippay` vouchers: a swarm that charges leechers keeps charging them.
+
+## 2. Terminology
+
+- **Requester.** The identity that posts an offer and funds it. Usually the
+  publisher of the swarm; for a public torrent it may be anyone who wants
+  it kept alive, subject to §3. A key, not necessarily a person: an
+  autonomous agent is a requester like any other (§5.8).
+- **Seeder.** An identity that holds a lease and serves the swarm
+  (`paid2seed`).
+- **Hub.** An `ippay` hub that also implements this document and
+  `paid2seed`. bittorrented.com is the reference hub.
+- **Attestation.** The consent record (§3). **Offer.** The request (§4).
+- **Period.** The unit of accrual and proof, `proof.everyHours` long.
+- **Visibility.** `public` (a vanilla torrent or an `ipdb` feed) or
+  `private` (an `ipfile` swarm; ciphertext only).
+
+Keys, records, signatures, amounts and times are as in the core.
+
+## 3. Consent: the attestation
+
+An attestation is the requester saying, under signature, what the data is
+and why they may distribute it. It is made once per swarm, before the first
+offer, and every offer for that swarm references it.
+
+### 3.1 Record
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "pay2seed.attestation",
+  "subject": { "infohashV1": "4330ddb304b78b1398a77297f57ea22c1ef3fb56", "infohashV2": null, "file": null },
+  "visibility": "public",
+  "basis": "own",
+  "license": "CC-BY-4.0",
+  "description": "Field recordings, Dartmoor, 2026",
+  "notice": "https://example.com/.well-known/pay2seed-notice",
+  "acceptsTakedown": true,
+  "createdAt": "2026-09-05T18:00:00.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:0d87…", "sig": "…" }]
+}
+```
+
+| Field | Rule |
+| --- | --- |
+| `subject` | Exactly one of `file` (an `ipfile` file key; visibility MUST be `private`), `infohashV1`/`infohashV2` (at least one; visibility MUST be `public`), or `channel` (an `iplive` channel key; see `pay2stream` §3). A feed offer (§4.4) attests the feed key in `file`. |
+| `visibility` | `public` or `private`. Fixed for the life of the swarm. |
+| `basis` | Why the requester may distribute this. One of §3.2. |
+| `license` | REQUIRED when `basis` is `open-license`: an SPDX identifier. |
+| `description` | OPTIONAL, at most 280 characters, shown on public listings. |
+| `notice` | An HTTPS URL or `mailto:` at which the requester receives notices (§8). REQUIRED for `public`. |
+| `acceptsTakedown` | MUST be `true`. Present so the acceptance is in the signed bytes. |
+| `readme`, `readmeSha256` | REQUIRED. The swarm's `README.md` and the hash of the copy inside the swarm (§5.6). No README, no listing. |
+
+Signer: the requester key. For an `ipfile` subject the attestation MUST
+also carry a signature by the file's publisher key, which is how a
+stranger is prevented from attesting somebody else's private swarm. For a
+public infohash no such proof of authorship exists; §3.3 stands in for it.
+
+### 3.2 Basis values
+
+| `basis` | Meaning | Allowed visibility |
+| --- | --- | --- |
+| `own` | The requester made it or holds the rights outright. | either |
+| `licensed` | The requester holds a licence that permits redistribution. | either |
+| `open-license` | Released under the SPDX licence in `license`. | either |
+| `public-domain` | No rights subsist, or they were waived. | either |
+| `personal` | The requester's own data, kept for themselves: backup, archive, sync. | `private` only |
+
+A hub MUST reject an attestation whose `basis` and `visibility` disagree
+with this table, and any with an unlisted `basis`. Hubs MAY refuse to list
+particular bases; the hub record says which (§6.1).
+
+### 3.3 Public infohashes and the claim window
+
+Anyone can attest a public infohash, so the attestation is a claim. A hub
+lists a public offer only after a **claim window** (`claimHours` in the
+hub record, default 24) during which the infohash and the attestation are
+visible at `GET /offers/<id>` and on the `pay2seed.offer.listed` event,
+and a notice voids it. An offer for a swarm that already has an honoured
+attestation from a different key is refused unless the new basis is
+`open-license` or `public-domain`, the two that do not depend on who is
+asking.
+
+A requester's standing (`paid2seed` §6.3) records every attestation of
+theirs that was voided. A hub SHOULD refuse new public attestations from a
+key whose voided count exceeds its accepted count, and MUST refuse them
+from a key with three or more voided in the last year.
+
+## 4. Offers
+
+An offer is money on the table for a swarm to be kept for a period. It is
+bought from the hub as an `ippay` pass is, so the budget is settled before
+anyone starts seeding.
+
+### 4.1 Record
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "pay2seed.offer",
+  "hub": "ed25519:c9f1…",
+  "requester": "ed25519:0d87…",
+  "attestation": "sha256:8e1c…",
+  "subject": { "infohashV1": "4330ddb304b78b1398a77297f57ea22c1ef3fb56", "infohashV2": null, "file": null, "feed": null },
+  "visibility": "public",
+  "sizeBytes": 7462331904,
+  "days": 30,
+  "seeders": { "min": 3, "max": 10 },
+  "priceUsdPerGibMonth": "0.150000",
+  "budgetUsd": "12.000000",
+  "proof": { "everyHours": 6, "verifiers": ["hub"] },
+  "pass": null,
+  "trackers": ["udp://tracker.opentrackr.org:1337/announce", "wss://tracker.openwebtorrent.com"],
+  "startsAt": "2026-09-05T18:00:00.000Z",
+  "expiresAt": "2026-10-05T18:00:00.000Z",
+  "payment": { "network": "eip155:8453", "nonce": "0x2f0a…" },
+  "createdAt": "2026-09-05T18:00:00.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:c9f1…", "sig": "…" }]
+}
+```
+
+| Field | Rule |
+| --- | --- |
+| `hub` | The hub that sold it and holds the budget. Signer. |
+| `requester` | Who paid, bound at purchase as `ippay` §3.3 binds a payer. |
+| `attestation` | Record id of an attestation whose `subject` and `visibility` match. |
+| `subject` | As the attestation, plus OPTIONAL `feed`: an `ipdb` feed key (§4.4). |
+| `sizeBytes` | Ciphertext or payload size. For a feed, the size at posting. |
+| `days` | Period the swarm is to be held from `startsAt`. |
+| `seeders.min` | Leases before the offer is `active`; `max` caps them. |
+| `priceUsdPerGibMonth` | What one seeder earns for the whole swarm for 30 days, pro rata. |
+| `budgetUsd` | Escrowed. At least `max * priceUsdPerGibMonth * sizeBytes/2^30 * days/30`, rounded up. |
+| `proof.everyHours` | Period length, 1 to 168. |
+| `proof.verifiers` | `hub`, `requester`, or `c0mpute`. |
+| `pass` | For a `private` swarm whose `pricing.perGib` is non-zero: an `ippay.pass` scoped to the file so a seeder can fetch as a paying peer. |
+| `trackers` | Announce URLs the seeder MUST add. At least one `wss://` when browser peers should find it. |
+| `startsAt`, `expiresAt` | `expiresAt` is `startsAt + days`. Leases never outlive it. |
+| `payment.nonce` | The settlement that funded `budgetUsd`. |
+
+### 4.2 Purchase
+
+`POST /offers` with an unsigned draft (every field but `hub`, `payment`,
+`sigs`, `createdAt`) and no `X-PAYMENT` header answers `402` with an x402
+offer for `budgetUsd` plus the hub's fee (`paid2seed` §5.3), exactly as
+`ippay` §3.2 answers a pass purchase, with the same `X-OpenSwarm-Payer`
+binding. Repeating with a valid proof answers `201` with the signed offer.
+A hub MUST verify the referenced attestation before quoting, and MUST
+refuse a `private` offer whose `sizeBytes` disagrees with the manifest.
+
+An offer is `pending` until `seeders.min` leases exist, `active` from then
+until `expiresAt`, then `settled`. It is `voided` by a notice (§7) or by
+the requester (`DELETE /offers/<id>`, signed), and the unearned budget is
+refunded to the requester's payout address less what leases have accrued.
+
+### 4.3 Public swarms
+
+A `public` offer is a vanilla torrent. Nothing in the wire changes; the
+only new thing on the network is another well behaved seeder that stays.
+A podcast archive, a dataset, a software release, an out-of-print
+recording with a clean basis: kept alive by strangers who are paid for it.
+
+### 4.4 Public feeds
+
+An offer whose `subject.feed` is set covers an `ipdb` feed: every segment
+swarm the feed publishes, present and future, and the duty to keep the
+feed's head reachable. What a leased seeder must do about it is
+`paid2seed` §7. `sizeBytes` is the feed's size at posting; each new segment
+joins the accrual base at the period it is proven, and the hub MUST NOT
+hand out leases whose projected accrual exceeds `budgetUsd`. The requester
+tops up with a further offer for the same feed.
+
+### 4.5 Private swarms
+
+A `private` offer is an `ipfile` swarm. The seeder holds ciphertext and,
+without a grant, cannot read a byte of it. `personal` is the basis for a
+backup nobody else is ever meant to read; its `pricing` SHOULD be zero and
+its manifest SHOULD not be catalogued. Where the manifest has `keys.public`
+set the data is readable by anyone with the manifest and the offer is
+still `private` in this document's sense: the attestation says the
+requester may store it.
+
+## 5. Encryption by default, and who may decrypt
+
+### 5.1 The default
+
+A client adding data through `pay2seed` encrypts it. The default swarm is
+an `ipfile` swarm: AES-256-CTR over pieces under a content key the
+requester's publisher key derives and holds (`ipfile` §4). Nothing about
+the data, not its name, not its size to the byte, not a single block,
+is readable by a seeder, a tracker, the DHT, or the hub. `visibility`
+is `private`.
+
+The client encrypts. The hub never does, never holds a content key it
+was not delegated as keeper, and never sees plaintext; what it manages
+is access to keys, not the bytes.
+
+Encryption is a choice the requester makes off, not on. A requester who
+wants the world to have the data sets `visibility` to `public`: the
+swarm is a vanilla torrent and there is no content key. A public swarm
+is not a fallback and not a second class: it is attested, listed, kept
+by paid seeders and rendered on the hub exactly as a private one is. The
+only difference is that anyone who finds it, on the hub or on the DHT,
+can read it. A client MUST make the default private, MUST make turning
+it off an explicit act, and MUST say plainly what off means: anyone.
+
+### 5.2 Access is the product
+
+What a private swarm needs, and what BitTorrent never had, is a way for
+the requester to say who else may decrypt it, and for that to keep
+working when the requester's laptop is closed. That is a **team**: a
+named set of member keys held at the hub, with a policy over which of
+the requester's swarms each member may receive a grant for. The hub, or
+a keeper it delegates to (`ipfile` §3.2 `delegate`, c0mpute's keeper
+role), issues the grant when a member asks. The requester never has to
+be online for a colleague to open a file, and never has to hand anyone
+the content key itself.
+
+Seeding is priced at the cost of disk. Teams are where a hub earns:
+seats, groups, an organisation with many groups, audit, and the
+guarantee that a grant is there at three in the morning.
+
+### 5.3 Records
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "pay2seed.team",
+  "hub": "ed25519:c9f1…",
+  "owner": "ed25519:0d87…",
+  "name": "field-recordings",
+  "members": [
+    { "key": "ed25519:a1b2…", "box": "x25519:4c40…", "role": "admin", "since": "2026-09-06T10:00:00.000Z" },
+    { "key": "ed25519:c3d4…", "box": "x25519:9e11…", "role": "member", "since": "2026-09-06T10:05:00.000Z" }
+  ],
+  "scope": { "files": ["*"], "publishers": ["ed25519:0d87…"] },
+  "keeper": "ed25519:c9f1…",
+  "createdAt": "2026-09-06T10:00:00.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:0d87…", "sig": "…" }]
+}
+```
+
+| Field | Rule |
+| --- | --- |
+| `owner` | The requester key. Signer. Only the owner and `admin` members may change the record; every change is a new signed record and the hub keeps the history. |
+| `members[].key`, `box` | The member's signing key and the X25519 box key a grant is sealed to (core §4.4). |
+| `members[].role` | `admin` (may invite and remove), `member` (may receive grants), `readonly` (may receive grants for files the team marks so). |
+| `scope` | As a pass's scope (`ippay` §3.1): which file keys or publisher keys members may be granted. `["*"]` files under the owner's publisher key is the common case. |
+| `keeper` | Who issues grants: the hub's key, or a keeper the owner has delegated to. The owner's publisher key remains able to grant directly. |
+
+An **invitation** is `pay2seed.invite`: `{ "team", "to": <email, phone,
+ipname or key>, "role", "expiresAt" }`, signed by an admin. It travels
+out of band (the hub emails or messages it) and is redeemed with a key:
+the invitee's client mints one if they have none, and the hub adds the
+member. An invite to a key that already exists is added at once. An
+invitation MUST expire, 7 days by default.
+
+A **grant** to a member is an `ipfile.grant` (`ipfile` §3.2) with
+`delegate: true` and `pass: null`, sealed to the member's `box`, issued
+by the keeper. It is what an `ippay` pass buys for a stranger, handed
+instead to a member because the team says so.
+
+### 5.4 Removal and rotation
+
+Removing a member ends future grants at once. It does not, and cannot,
+unread what they have already read; a grant they hold for a file still
+decrypts that file's current key epoch. A team with `rotateOnRemove:
+true` (the default) has the hub trigger `ip file reencrypt` on the files
+in scope (`ipfile` §11, a new content key and a new swarm), so the next
+version is closed to them. A client MUST show this distinction to the
+owner rather than imply removal is retroactive.
+
+### 5.5 What the hub charges
+
+A hub prices teams as it likes and says so in its record:
+
+```json
+"teams": { "freeMembers": 3, "seatUsdPerMonth": "2.000000", "orgUsdPerMonth": "50.000000", "keeperBps": 500 }
+```
+
+`freeMembers` seats per owner cost nothing, so a person sharing with
+their family or a three-person shop never pays for access. Above that a
+seat is billed monthly, an organisation (many teams, one bill, shared
+admins) at a flat rate, and `keeperBps` is the hub's share when it acts
+as keeper for a paid file (`ipfile` §7). All of it is settled through
+the same pay plugins the rest of the family uses, CoinPay and x402 over
+the owner's `ippay` payee, never a card form of the hub's own.
+
+Both sides earn. A seeder rents out disk through `paid2seed`. A requester
+sells access: to strangers through `ippay` passes at the swarm's
+`keyUsd` and `perGib`, to colleagues through a team. A hub takes its
+`hubBps` on payments that cross it, **1 percent at the reference hub**
+(`ippay` §5.1), plus its seat fees on teams, and nothing at all on the
+seeder's floor. Public swarms are not charged for; they carry an ad
+instead (§5.7).
+
+### 5.6 The README
+
+Every swarm on the market MUST contain a `README.md` at its root. No
+exceptions: an attestation without one is refused, and a hub that lists
+a swarm without one is not conformant. The README is the swarm's face:
+what this is, who made it, what a buyer or a member gets, how to use it.
+
+The attestation carries it, so the hub can show it without a key:
+
+| Field | Rule |
+| --- | --- |
+| `readme` | The README's Markdown, UTF-8, at most 64 KiB. Signed with the rest of the attestation. |
+| `readmeSha256` | SHA-256 of the exact bytes of `README.md` inside the swarm. For a private swarm, of the plaintext; a member with a grant MAY verify it. |
+
+The hub renders `readme` as HTML on the swarm's page: CommonMark with
+GFM tables and fenced code, sanitised, no raw HTML, no scripts, images
+only from the swarm itself or over HTTPS. A relative link resolves to a
+file in the swarm and is gated the same way the file is: a public swarm's
+link downloads, a private swarm's link asks for a pass or a grant. That
+page, on bittorrented.com, is the listing; the DHT crawl's bare
+infohashes never had one, and this is what a consented swarm looks like
+beside them.
+
+### 5.7 Public swarms pay for themselves
+
+Public distribution is free to the requester and free to the fetcher, and
+it is not charity. A public swarm has a page on the hub, built from the
+README (§5.6), and that page carries an advertisement. The hub earns from
+the page; the swarm's bytes are never metered, never gated and never
+counted.
+
+This is the trade, stated so nobody has to guess at it:
+
+| | Public | Private |
+| --- | --- | --- |
+| Bytes | free, over the ordinary wire and the DHT | `ipfile` ciphertext, `perGib` and `keyUsd` as the manifest says |
+| Who may read it | anyone | pass holders and team members |
+| What the hub earns | the ad on the swarm's page | its percentage of each payment, plus seats (§5.5) |
+| What the requester pays | nothing, unless they buy an offer to keep it alive | nothing, unless they buy an offer or seats |
+
+A requester who wants no advertisement on their page pays for a seat
+(§5.5); a hub MUST make that switch available rather than making the ad
+the price of being listed at all. An ad never appears inside a swarm, is
+never injected into a file, and never rides the wire: it is on the hub's
+page about the swarm and nowhere else. `ipdb` entries and the market API
+carry no advertising, so a client that reads the catalogue directly sees
+none of it.
+
+### 5.8 An agent may be a requester
+
+Nothing in this family assumes a person. A requester is a key, and an
+autonomous agent holds keys as readily as anyone: it can attest what it
+made, publish a swarm, price access to it, sell tickets to a live
+channel, take payment through its own `ippay` payee, and spend what it
+earns buying offers so its own work stays online. The same is true on the
+other side: an agent with disk can hold leases and be paid for them
+(`paid2seed` §7).
+
+Two rules, and they are the same rules a person gets:
+
+- **The attestation is the agent's own claim**, signed by the agent's key,
+  and its standing (§3.3) is the agent's. An agent that attests what it
+  had no right to distribute loses standing exactly as a person does, and
+  a hub applies §3.3's refusals without asking which kind of requester it
+  is looking at.
+- **Consent does not become weaker because a machine gave it.** An agent
+  publishing work made from somebody else's material has the same bases
+  available and no others; `own` means the agent or its operator holds
+  the rights, and there is no basis meaning "a model produced this, so
+  nobody owns it".
+
+A hub MAY require an agent's attestations to name a responsible operator
+key alongside the agent's own, and the reference hub does for `public`
+swarms: an agent can sell freely, and somebody remains reachable when a
+notice arrives.
+
+### 5.9 API
+
+| Method and path | Auth | Purpose |
+| --- | --- | --- |
+| `POST /teams` | owner signed | Create or replace a team record. |
+| `GET /teams/<id>` | member signed | The record, its history, the files in scope. |
+| `POST /teams/<id>/invites` | admin signed | Issue an invitation; the hub delivers it. |
+| `POST /invites/<id>/accept` | invitee signed | Redeem with a key; returns the updated team. |
+| `DELETE /teams/<id>/members/<key>` | admin signed | Remove; triggers rotation when the team says so. |
+| `GET /teams/<id>/grant?file=` | member signed | A sealed grant for a file in scope, from the keeper. `403` outside scope or after removal. |
+| `GET /teams/<id>/audit?since` | admin signed | Who was granted what, when. |
+
+## 6. The requester's hub
+
+### 6.1 Hub record
+
+An `ippay.hub` record that offers this family adds:
+
+```json
+"pay2seed": {
+  "base": "https://bittorrented.com/api/openswarm/pay2seed",
+  "bases": ["own", "licensed", "open-license", "public-domain", "personal"],
+  "claimHours": 24,
+  "minStanding": 0,
+  "verifiers": ["hub", "c0mpute"],
+  "maxDays": 365
+}
+```
+
+`bases` is what this hub will list. `minStanding` is the floor a seeder
+needs to take a lease (`paid2seed`). A hub MAY run a market for private
+backups only, or for open data only, by narrowing `bases`.
+
+### 6.2 API, requester side
+
+All bodies JSON, records verified on receipt, paths relative to `base`.
+The seeder side of the same API is `paid2seed` §6.1.
+
+| Method and path | Auth | Purpose |
+| --- | --- | --- |
+| `POST /attestations` | signed record | Register. `201` with its id; `409` if one is honoured for the subject by another key (§3.3). |
+| `GET /attestations/<id>` | none | The record and `{ "status": "claimed|honoured|voided", "notices": n }`. |
+| `POST /offers` | x402 + `X-OpenSwarm-Payer` | Buy an offer (§4.2). |
+| `GET /offers?visibility&basis&minPrice&maxSize&feed&status` | none | The market, newest first, paged. What a seeder client reads; what a requester watches. |
+| `GET /offers/<id>` | none | The offer, its status, leases held, slots free, periods proven per lease. |
+| `DELETE /offers/<id>` | requester signed | Void and refund the unearned budget. |
+| `GET /requesters/<key>` | none | `{ "standing", "attestations", "voided", "offers" }`. |
+| `POST /notices` | signed | A notice against an attestation (§7). |
+| `POST /webhooks` | signed | Register a CloudEvents endpoint for a requester key. |
+
+## 7. Requester client behaviour
+
+A requester client (the `ip seed` commands in [cli.md](./cli.md), a web
+app such as bittorrented.com's upload form) does the following:
+
+1. Holds a requester key, stored as an OpenCreds `key` item, registered
+   as an `ippay` payee so refunds have somewhere to go.
+2. Makes the attestation before anything else, and MUST NOT let a user
+   post an offer without choosing a `basis` and, for `public`, a `notice`
+   endpoint. The basis list is a choice, never a default.
+2b. Encrypts by default (§5.1). Turning encryption off is an explicit
+   act with its consequence stated. Shares a private swarm by inviting
+   members to a team (§5.3), never by handing out a content key.
+3. Buys offers only against attestations the key actually signed.
+4. Includes a pass in a `private` offer when the manifest charges per GiB.
+5. Watches `GET /offers/<id>` or the events for `active`, `lapsed` leases
+   and `settled`, and shows the user seeders held out of wanted, periods
+   proven, and spend against the budget.
+6. Receives notices at the endpoint it named, and shows them.
+
+## 8. Notices and takedown
+
+Anyone may `POST /notices` against an attestation:
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "pay2seed.notice",
+  "attestation": "sha256:8e1c…",
+  "kind": "rights|illegal|personal-data|other",
+  "claimant": { "name": "…", "contact": "mailto:…" },
+  "statement": "…",
+  "createdAt": "2026-09-06T09:00:00.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:77aa…", "sig": "…" }]
+}
+```
+
+On a notice the hub MUST forward it to the requester's `notice` endpoint
+and MUST, within `claimHours`, either void the attestation or record that
+it was reviewed and stands. Voiding an attestation voids every offer that
+references it: leases end (`paid2seed` §3.2), the requester is refunded
+the unearned budget less accrued earnings, and their `voided` count rises.
+A hub that voids on every notice without review is conformant; a hub that
+never voids is not.
+
+For a `private` swarm the hub cannot inspect the content and does not
+pretend to. What it has is the requester's identity, attestation and
+standing, which is what accountability looks like for ciphertext.
+
+## 9. Security notes
+
+- **Attestation is a claim.** §3.3's window, standing and notices are the
+  defence. A hub that lists a public offer the moment it is paid is not
+  conformant.
+- **Hub as escrow.** The budget sits with the hub for `days`, as a pass
+  buyer's `capUsd` does for 30. The hub's signed receipts and refunds are
+  its auditable trail.
+- **Private means ciphertext, not secret existence.** An offer reveals to
+  its seeders the file key, the size and the requester's key. `personal`
+  swarms SHOULD use a fresh unrelated file pair (core §4.2) so backups are
+  not linkable to a publisher's catalogue.
+
+## 10. Implementations
+
+| Piece | Where | Status |
+| --- | --- | --- |
+| Reference hub, requester side: attestations, offers, market, notices | `profullstack/media-streamer` (bittorrented.com) | planned; the seedbox rental rail is the pay-per-pass half today |
+| Requester client and shared records | `@profullstack/pay2seed` | planned |
+| Requester CLI | `ip seed …` ([cli.md](./cli.md)) | proposed |
+
+## 11. Conformance
+
+A **hub** is conformant on this side when it refuses offers without an
+honoured attestation (§3), enforces the basis table and claim window
+(§3.2, §3.3), escrows the budget before listing (§4.2), publishes the
+market and requester standing (§5.2), and forwards and resolves notices
+within `claimHours` (§7). It MUST also be conformant to `paid2seed`.
+
+A **requester client** is conformant when it does all of §6.
+
+## 12. Version history
+
+- 0.1 (2026-09-06): split out of the first pay2seed draft (2026-09-05) as
+  the client half; attestation, offers, requester API, notices. Same day:
+  encryption by default, teams, invitations, member grants, rotation on
+  removal, and the hub's pricing for access. Then: the 1 percent reference
+  fee, the advertisement that pays for public swarms, and agents as
+  requesters.
diff --git a/docs/openswarm/pay2stream.md b/docs/openswarm/pay2stream.md
new file mode 100644
index 0000000..6930907
--- /dev/null
+++ b/docs/openswarm/pay2stream.md
@@ -0,0 +1,260 @@
+# pay2stream: The Client Protocol for Paid Live Streams
+
+Status: 0.1 draft. Member of the [OpenSwarm](../openswarm.md) family.
+Depends on the [core](./spec.md), [`iplive`](./iplive.md), [`ippay`](./ippay.md)
+and [`pay2seed`](./pay2seed.md). Its server half is
+[`paid2stream`](./paid2stream.md).
+
+## 1. Scope
+
+`pay2stream` is the side that pays for a live stream. Two parties speak it
+over HTTPS to a hub and to a gateway:
+
+- **A broadcaster**, who attests a channel (consent), buys guaranteed
+  relay capacity for a window, publishes listings, and sets ticket prices.
+- **A viewer**, who buys a ticket and watches, either as an `iplive` peer
+  or, out of the box, on any player that speaks **HLS**: VLC, TiviMate,
+  Kodi, hls.js, an Apple TV, a Smart TV app. The viewer never installs
+  anything new. What they get is a URL with a pass on it, and an M3U plus
+  an EPG that look, to a television, like the provider they replace.
+
+The BitTorrent side, how a relay takes a lease, proves it is online and
+serving, runs a gateway that turns swarmed segments into HLS, and is paid,
+is [`paid2stream`](./paid2stream.md). One hub implements both. A player
+implements nothing; that is the point.
+
+### Prior art
+
+Ace Stream (TorrentStream, 2013) proved BitTorrent carries live television
+to millions of viewers at once. It never paid a relay, never recorded
+consent, and never opened its engine. `pay2stream` and `paid2stream` are
+the open answer to the same problem with those three things added.
+
+### Non-goals
+
+Encoding and ingest (`iplive` §6, c0mpute DIP 0019). Chat, ads, a guide
+format beyond the M3U attributes every IPTV player already reads. DRM past
+the key a viewer is granted; a gateway serving clear HLS is serving
+plaintext to whoever holds the pass, and this document says so.
+
+## 2. Terminology
+
+- **Origin, relay, viewer, channel, head, segment, part, epoch.** As
+  `iplive` §2.
+- **Broadcaster.** The identity that attests the channel and buys relay
+  offers. Usually the publisher of the `iplive.channel`.
+- **Gateway.** A relay that presents the channel over HTTP as HLS and M3U
+  (`paid2stream` §5).
+- **Ticket.** An `ippay.pass` scoped to one or more channel keys, with a
+  window: a game, a day, a month.
+- **Listing.** A signed `ipdb` entry saying what is on when, at what price.
+
+## 3. Consent
+
+A channel is listed on a hub only against a `pay2seed.attestation`
+(`pay2seed` §3) whose `subject` names the channel:
+
+```json
+"subject": { "channel": "ed25519:0d87e09c7fea3ad6ba6c2f3e027ea47f5b245452899910948470906704c5295d" }
+```
+
+`visibility` is `public` for a channel any viewer may buy, `private` for
+one whose tickets a broadcaster hands out themselves. `basis` is any value
+from `pay2seed` §3.2 except `personal`. The attestation MUST be signed by
+the channel key and the publisher key, as the channel record itself is
+(`iplive` §3.1).
+
+Two things are stated because they are where live streaming has always
+gone wrong:
+
+- A broadcaster relaying a feed they receive under a subscription that
+  forbids redistribution has no basis in the table and MUST NOT attest
+  `licensed`. A hub that learns of it treats the attestation as false.
+- A broadcaster with a licence that does permit redistribution (a
+  league's own OTT rights, a broadcaster's own channel, a creator's own
+  camera) attests `licensed` or `own` and names the licence in
+  `description`. That is the entire difference between an IPTV reseller
+  and a pirate, and it is now a signed record on a public standing.
+
+The claim window (`pay2seed` §3.3) applies to a public channel before its
+first listing, not to each broadcast.
+
+## 4. Relay offers
+
+A broadcaster buys relays the way a requester buys seeders: an offer with
+a budget escrowed at the hub, so a stream has relays before its first
+viewer arrives and keeps them when vouchers alone would not.
+
+```json
+{
+  "openswarm": "0.1",
+  "type": "pay2stream.offer",
+  "hub": "ed25519:c9f1…",
+  "broadcaster": "ed25519:5d29…",
+  "attestation": "sha256:8e1c…",
+  "channel": "ed25519:0d87…",
+  "window": { "startsAt": "2026-09-12T18:30:00.000Z", "endsAt": "2026-09-12T22:00:00.000Z" },
+  "relays": { "min": 4, "max": 12 },
+  "regions": ["eu", "us-east"],
+  "capacity": { "downstreamPerRelay": 8, "renditions": ["1080p", "720p"] },
+  "priceUsdPerRelayHour": "0.050000",
+  "gatewayBonusBps": 5000,
+  "budgetUsd": "4.200000",
+  "proof": { "everyMinutes": 10, "verifiers": ["hub", "broadcaster"] },
+  "pass": { "…": "an ippay.pass scoped to the channel, so relays can pull" },
+  "payment": { "network": "eip155:8453", "nonce": "0x2f0a…" },
+  "createdAt": "2026-09-10T09:00:00.000Z",
+  "sigs": [{ "alg": "ed25519", "key": "ed25519:c9f1…", "sig": "…" }]
+}
+```
+
+| Field | Rule |
+| --- | --- |
+| `attestation` | An honoured attestation for `channel` (§3). |
+| `window` | When relays are wanted. A standing channel MAY post rolling 24 h windows. |
+| `relays.min`, `max` | Leases before the offer is `active`; the cap. |
+| `regions` | OPTIONAL. Region labels a relay self-declares; the hub prefers matching relays and never refuses others. |
+| `capacity.downstreamPerRelay` | The `iplive` `maxDownstream` a leased relay MUST accept. |
+| `priceUsdPerRelayHour` | The floor a relay earns per proven hour online, on top of vouchers. |
+| `gatewayBonusBps` | OPTIONAL. Extra floor, in basis points of the hourly price, for a relay that also runs a gateway. |
+| `budgetUsd` | Escrowed: at least `max * priceUsdPerRelayHour * hours * (1 + gatewayBonusBps/10000)`. |
+| `proof.everyMinutes` | Period length, 5 to 60. |
+| `pass` | So a leased relay can pull from upstream as a paying peer; the upstream `perGib` cost is the broadcaster's, not the relay's. |
+
+Purchase, lifecycle, voiding and refund are as `pay2seed` §4.2, over x402
+at `POST /streams`.
+
+## 5. Tickets and listings
+
+A **ticket** is an `ippay.pass` with `scope.channels` (added to the pass
+record by this document; the hub verifies it as it verifies
+`scope.files`) and a window: the hub sells `expiresAt` as short as one
+hour for a channel whose record sets `ticket.minHours`, and as long as its
+`passDays`. Pricing is the channel's `keyUsd` per grant plus `perGib`
+served; a broadcaster who wants a flat ticket sets `perGib` to zero and
+`keyUsd` to the ticket price, and the pass's `capUsd` to zero. Nobody
+pays for bytes twice.
+
+A **listing** is an `ipdb` entry of type `pay2stream.listing`: channel,
+title, start, end, description, and the ticket price at the time, signed
+by the channel key. Listings are what a market page and an EPG are built
+from, and what a viewer buys against.
+
+A channel whose `keyUsd` and `perGib` are both zero is **free to watch**:
+no ticket, no grant, and a gateway serves it to anyone. Its page on the
+hub carries an advertisement the same way a public swarm's does
+(`pay2seed` §5.7), which is what pays for listing it. The stream itself
+is never interrupted: nothing is injected into a segment, into the
+playlist, or into the M3U. A broadcaster selling tickets pays the hub its
+percentage instead, 1 percent at the reference hub, and their page
+carries no advertising.
+
+## 6. Watching
+
+### 6.1 As a peer
+
+`iplive` §7: resolve the channel, buy or reuse a ticket with `grant: true`,
+connect to two peers, pull segments, send vouchers. This is the browser
+player on bittorrented.com and the `ip live watch` command.
+
+### 6.2 On any HLS player
+
+An HLS player cannot sign a voucher, so the viewer's ticket is bought with
+a gateway's key as `payer` (`ippay` §3.3) and the viewer's own identity
+recorded by the hub as `boundBy`. The gateway then signs vouchers on the
+viewer's behalf, bounded by the ticket's `capUsd`, which is the whole of
+the viewer's exposure. A viewer who disputes a gateway's spend has the
+hub's `GET /passes/<id>` record and the gateway's standing.
+
+The ticket reaches the player as a bearer token in the URL, because that
+is the only credential an IPTV player can carry:
+
+```
+https://gw-eu1.example.net/openswarm/hls/<channel key>/master.m3u8?pass=<base64url pass>
+```
+
+Gateways also accept the pass as a cookie and as `Authorization: Bearer`
+for browser players (`paid2stream` §5.2).
+
+The pair every IPTV app asks for on setup:
+
+```
+https://gw-eu1.example.net/openswarm/channels.m3u?pass=<pass>
+https://gw-eu1.example.net/openswarm/epg.xml?pass=<pass>
+```
+
+The M3U lists every channel the ticket is in scope for, with `tvg-id`,
+`tvg-name`, `tvg-logo` and `group-title`; the EPG is XMLTV built from the
+listings. Point TiviMate or Kodi at those two and it is done. Latency is
+one segment behind the peer edge, one part with low latency.
+
+Which gateway? `GET /streams/<id>` lists the gateways currently relaying
+the channel with their regions and median verified latency; a hub's own
+gateway is always among them. A viewer client picks the nearest, and a
+ticket bought against one gateway is presentable at any gateway the hub
+lists for the channel, since the pass is the hub's record, not the
+gateway's.
+
+## 7. Hub API, client side
+
+Relative to a `pay2stream.base` the hub adds to its `ippay.hub` record as
+`pay2seed` adds its own. The relay and gateway side is `paid2stream` §6.
+
+| Method and path | Auth | Purpose |
+| --- | --- | --- |
+| `POST /streams` | x402 + `X-OpenSwarm-Payer` | Buy a relay offer (§4). |
+| `GET /streams?live&region&basis&minPrice` | none | Channels currently live with their gateways and listings; offers with free relay slots. |
+| `GET /streams/<id>` | none | The offer, leases, gateways, the latest listing. |
+| `DELETE /streams/<id>` | broadcaster signed | Void and refund the unearned budget. |
+| `POST /listings` | channel signed | Publish a `pay2stream.listing` (also replicated on the channel's `ipdb` feed). |
+| `GET /tickets?payer&channel&hours` | x402 + `X-OpenSwarm-Payer` | Buy a ticket (§5). `payer` MAY be a gateway key with the viewer's own key as `X-OpenSwarm-Bound-By`. |
+| `GET /gateways?region&channel` | none | Gateways, and which channels each currently relays. |
+| `POST /notices` | signed | As `pay2seed` §8; voiding ends every lease and delists every gateway for the channel. |
+
+## 8. Client behaviour
+
+A **broadcaster client** (`ip live` plus `ip stream offer` and
+`ip stream ticket` in [cli.md](./cli.md); bittorrented.com's Live TV rent-out
+form) attests before listing, buys offers only against its own attestation,
+includes a pass in the offer, publishes a listing for every window, and
+receives notices at its endpoint.
+
+A **viewer client** (a web page, `ip live watch`, or a plain IPTV app with
+a URL pasted in) buys or reuses a ticket, prefers a gateway by region, and
+MUST NOT send a ticket to a gateway the hub does not list for that channel.
+
+## 9. Security notes
+
+- **Clear HLS is clear.** A ticket holder can capture the stream. So could
+  a peer with a grant. The spec does not pretend otherwise.
+- **Pass in the URL.** It is a bearer token in a log line on every proxy
+  in the path. Hubs SHOULD sell short tickets to gateway-bound viewers and
+  viewers SHOULD prefer the cookie form where a player supports it.
+- **Gateway as payer.** The viewer's exposure is `capUsd`; the gateway's
+  incentive to over-sign is bounded by its standing and by the hub
+  comparing signed bytes with the segment count in the window.
+- **A stolen feed with a signed attestation** is the failure this spec
+  moves from "impossible to know" to "a named key, a public standing, and
+  a notice that ends it".
+
+## 10. Implementations
+
+| Piece | Where | Status |
+| --- | --- | --- |
+| Reference hub, client side: attestations, offers, tickets, listings, market | `profullstack/media-streamer` (bittorrented.com), Live TV | planned; the IPTV resale rail sells per-game passes today, centrally |
+| Viewer in the browser | bittorrented.com, tipoffwatch, genrewatch players (hls.js, mpegts.js) | no change for HLS; `iplive` peer mode planned |
+| Players | VLC, TiviMate, Kodi, Apple, Android TV | no work |
+| Broadcaster CLI | `ip stream …` ([cli.md](./cli.md)) | proposed |
+
+## 11. Conformance
+
+A **hub** on this side: everything `pay2seed` §11 requires of it, over
+channels; sells tickets bound to gateways; lists gateways per channel.
+
+A **broadcaster client** and a **viewer client**: §8.
+
+## 12. Version history
+
+- 0.1 (2026-09-06): first draft, as the client half; consent for
+  channels, relay offers, tickets and listings, watching as a peer or on
+  any HLS player.
diff --git a/docs/openswarm/spec.md b/docs/openswarm/spec.md
index 1a89cf7..597e5f0 100644
--- a/docs/openswarm/spec.md
+++ b/docs/openswarm/spec.md
@@ -502,6 +502,19 @@ Member conformance is defined per document; the checklist is collected in
 | `ipvideo.title` | publisher key | ipvideo |
 | `iplive.channel`, `iplive.head` | channel key | iplive |
 | `ipname.pin` | publisher key | ipname |
+| `pay2seed.attestation` | requester key (and the file's publisher key, or the channel key, for `ipfile` and `iplive` subjects) | pay2seed |
+| `pay2seed.offer` | hub key | pay2seed |
+| `pay2seed.notice` | claimant key | pay2seed |
+| `pay2seed.team` | owner key (or an admin member) | pay2seed |
+| `pay2seed.invite` | an admin member | pay2seed |
+| `paid2seed.lease`, `paid2seed.receipt` | hub key | paid2seed |
+| `paid2seed.challenge` | verifier key | paid2seed |
+| `paid2seed.proof` | seeder key, or verifier key for a probe | paid2seed |
+| `pay2stream.offer` | hub key | pay2stream |
+| `pay2stream.listing` | channel key | pay2stream |
+| `paid2stream.lease`, `paid2stream.receipt` | hub key | paid2stream |
+| `paid2stream.proof` | verifier key | paid2stream |
+| `paid2stream.gateway` | gateway key | paid2stream |
 
 ## 12. Version history
 
diff --git a/packages/logicsrc-mcp/src/standards.test.ts b/packages/logicsrc-mcp/src/standards.test.ts
index 14ce0a8..3aee8f9 100644
--- a/packages/logicsrc-mcp/src/standards.test.ts
+++ b/packages/logicsrc-mcp/src/standards.test.ts
@@ -203,7 +203,7 @@ describe("MCP: OpenPRD", () => {
   it("reports the next free id and the allowed lifecycle moves", async () => {
     const client = await connect();
     // Asserted against the live prd/ directory, so this advances with every PRD added.
-    expect(toolText(await client.callTool({ name: "prd_next_id", arguments: {} }))).toBe("0006");
+    expect(toolText(await client.callTool({ name: "prd_next_id", arguments: {} }))).toBe("0007");
 
     const moves = await client.callTool({ name: "prd_next_statuses", arguments: { ref: "0001" } });
     const payload = JSON.parse(toolText(moves)) as { status: string; allowedNext: string[] };
diff --git a/prd/0006-add-pay2seed-spec.md b/prd/0006-add-pay2seed-spec.md
new file mode 100644
index 0000000..f02cf48
--- /dev/null
+++ b/prd/0006-add-pay2seed-spec.md
@@ -0,0 +1,246 @@
+---
+openprd: "0.2"
+id: "0006"
+title: "Add pay2seed, paid2seed, pay2stream and paid2stream to the OpenSwarm family"
+status: Draft
+authors:
+  - anthony@profullstack.com
+created: 2026-09-05
+updated: 2026-09-05
+repo: profullstack/logicsrc
+discussion:
+implementation:
+tags:
+  - openswarm
+  - pay2seed
+  - paid2seed
+  - pay2stream
+  - paid2stream
+  - iplive
+  - hls
+  - ipfile
+  - ippay
+  - ipdb
+  - bittorrent
+  - torlink
+  - bittorrented
+  - c0mpute
+supersedes:
+superseded-by:
+---
+
+## Problem
+
+BitTorrent is the best distribution network ever built and it has never
+been a legitimate business, because two things are missing from the
+protocol. Nobody is paid to seed, so a swarm lives exactly as long as
+somebody feels like leaving a client open. And nothing about an upload says
+who put it there or whether they were allowed to, so every index is a pile
+of unattributed infohashes and every seeder is presumed to be doing
+something wrong.
+
+OpenSwarm (PRD 0005) fixed the first half for encrypted media: `ippay` pays
+a seeder per verified piece served. It does not pay anyone to *stay*. A
+piece that nobody downloads this month earns nothing, so an archive, a
+backup, a dataset waiting for its buyer or a podcast's back catalogue is
+exactly as unfunded as it was before. `ipfile.pin` on c0mpute pays a
+storage node to hold a swarm, but only a c0mpute node, only for a private
+`ipfile` swarm, and only through c0mpute's auction.
+
+The second half, consent, is not addressed anywhere. bittorrented.com
+indexes what the DHT crawl finds and runs a seedbox rental rail, and
+neither has a place for "I made this, here is the licence, here is where to
+send a notice". A user of ours who wants to share their own work, keep an
+off-site copy of their own data, or seed an openly licensed dataset for
+money has no way to say so that anyone else can check.
+
+## Naming
+
+`pay2*` is the client protocol: the side that pays, over HTTPS, and plays.
+`paid2*` is the server protocol: the BitTorrent side that earns. One hub
+implements both halves of a pair; a requester or viewer client implements
+only `pay2*`; a seeder, relay or gateway implements only `paid2*`. The
+first draft of pay2seed carried both halves in one document and was split
+the same day.
+
+## Goals
+
+- **Consent is part of the upload.** A signed attestation with a fixed set
+  of bases (`own`, `licensed`, `open-license`, `public-domain`, `personal`)
+  and a notice endpoint, without which no hub lists the swarm. Public
+  claims get a claim window and a public standing; false ones are voided
+  on notice and count against the requester.
+- **Anyone can pay to have anything kept.** An offer escrows a budget at a
+  hub for a swarm to be held for N days by M seeders at a price per
+  GiB-month. Public offers cover vanilla torrents and `ipdb` feeds; private
+  offers cover `ipfile` ciphertext.
+- **Anyone can be paid to keep it.** A seeder takes a lease, proves each
+  period by challenge or probe, and is paid per proven period through the
+  same `ippay` payee it already has for vouchers. torlink's headless daemon
+  is the reference client; a laptop qualifies.
+- **The market is one HTTP surface.** `GET /offers` is what a client picks
+  work from. bittorrented.com is the reference hub.
+- **Encryption on by default, access as the product.** Private swarms are
+  the default; teams, invitations, member grants via the hub as keeper,
+  rotation on removal, and per-seat pricing are in the spec. Public is
+  opt-out and rides the DHT for free.
+- **Reuse.** Offers are bought like passes (x402, `X-OpenSwarm-Payer`),
+  payouts are `ippay` §5.6, challenges are c0mpute's storage challenge,
+  feeds are `ipdb`, events are the family envelope. One new document, six
+  new record types, no new primitive.
+
+## Business model
+
+Encryption is on by default: every private swarm is `ipfile` ciphertext
+under a key the requester holds. Seeding is priced at the cost of disk and
+is not where the money is. **Access is.** A requester invites team,
+group or organisation members, and the hub (as keeper) issues them grants
+to decrypt, at three in the morning, when the requester is offline, with
+an audit trail and rotation on removal. A few seats are free so a family
+or a three-person shop never pays; above that, seats and organisations
+are billed monthly through the same CoinPay rail as everything else.
+Public distribution is encryption switched off: a vanilla torrent that
+the DHT finds for nothing and that the hub never charges for. It is not
+charity either. A public swarm has a page on the hub built from its
+README, and that page carries an advertisement; the bytes are never
+metered and nothing is ever injected into a file, a segment or a
+playlist. A requester who wants no ad on their page buys a seat.
+
+The hub's cut is **1 percent** of any payment that crosses it, charged to
+whoever is paying and never taken out of a seeder's or a relay's
+earnings. So there are three lines: 1 percent of transactions, seats for
+managed access, and ads on the free tier.
+
+Sellers need not be people. A requester is a key, and an autonomous agent
+can attest what it made, price access, sell tickets to a live channel,
+take payment through its own payee and spend what it earns keeping its
+own work online. The consent rules do not soften because a machine signed
+them, and the reference hub asks an agent's public attestations to name a
+responsible operator key so somebody is reachable when a notice
+arrives.
+
+## Non-Goals
+
+- Deciding what content is acceptable. The hub enforces that an
+  attestation exists, is signed and is honoured on notice. Its truth is
+  the requester's liability.
+- Encrypting public swarms. Public is public; private is `ipfile`.
+- A reputation system that crosses hubs. Standing is one hub's signed
+  opinion.
+- A token, a chain, or a DAO.
+- The seeder client, the hub, or the library themselves. This PRD adds the
+  specification; implementation is tracked in each repo (§ Requirements
+  lists them).
+
+## Users
+
+- **A creator or label** who wants their own release kept online for a
+  year without running a server, and wants it on record that they are the
+  one who put it there.
+- **A person keeping a backup** who wants three copies of ciphertext held
+  by strangers for 30 days and deleted after, and never wants the strangers
+  to know what it is.
+- **An open data or open source publisher** with a 4 GB installer or a
+  dataset who wants ten seeders paid to stay, and downloaders to pay
+  nothing.
+- **A seedbox operator or torlink user** with disk and bandwidth to spare
+  who wants to be paid for holding swarms, and to see, before accepting,
+  whether they would be holding a stranger's ciphertext or seeding a
+  CC-BY dataset in the clear.
+- **bittorrented.com** as the hub: attestations, offers, the market, and
+  the seedbox rental rail it already runs, with IPTV and other passes sold
+  beside it.
+- **A c0mpute node** that already bids on `ipfile.pin` and now sees the
+  same offers from any hub.
+
+## Requirements
+
+- R1 [P0] Define `pay2seed`, the client half: the attestation record and
+  basis table, the mandatory README and its hash, the claim window and
+  requester standing, the offer record and its purchase over x402, the
+  offer lifecycle, public swarms, public `ipdb` feeds and private swarms,
+  the hub record extension, the requester API, notices and takedown.
+- R2 [P0] Define `paid2seed`, the server half: the lease record and slot
+  rules, storage challenges and wire probes, GiB-month accrual, receipts
+  and payout through `ippay`, the seeder API and client behaviour, seeder
+  and requester standing, the `ipfile.pin` mapping, events, conformance.
+- R3 [P0] Define `pay2stream`, the client half for live: consent for
+  channels with the two rules that separate a licensed rebroadcast from a
+  stolen feed, relay offers per relay-hour with a gateway bonus, tickets
+  and listings, watching as a peer or on any HLS player.
+- R4 [P0] Define `paid2stream`, the server half for live: relay leases,
+  presence proofs and the served-bytes ratio, gateways serving standard
+  HLS in clear and sealed modes with an M3U and XMLTV EPG so any IPTV
+  player works with no new client, gateway-bound vouchers, stopping on a
+  void.
+- R5 [P0] Specify encryption by default and access as the product: teams
+  with roles and scopes, invitations that expire, member grants issued by
+  the hub as keeper, re-encryption on removal, per-seat pricing, the 1
+  percent fee on payments that cross the hub, and the advertisement that
+  pays for public swarms.
+- R6 [P1] Say that a requester is a key rather than a person, so an
+  autonomous agent can attest, price access, sell tickets and be paid,
+  under the same consent rules and with a responsible operator key named
+  on public attestations.
+- R7 [P1] Wire the family into the repo: `docs/openswarm.md` family table,
+  stack diagram and "what already exists"; `spec.md` §11 record type
+  registry; the `ip seed` and `ip stream` command groups in `cli.md`; and
+  the four protocols listed on the `/openswarm` page.
+
+Implementations are tracked outside this repo: bittorrented.com
+(`profullstack/media-streamer`) as the reference hub; torlink
+(`baairon/torlink`, via the `ralyodio` fork) as the seeder client, whose
+per-torrent seed time (#186) is the first piece; `@profullstack/pay2seed`
+as the shared client; and c0mpute for `ipfile.pin` interop.
+
+## UX Notes
+
+- An attestation is one form on the upload screen: what is it, why may
+  you share it, where do notices go. The basis list is a radio group;
+  `personal` is greyed out unless the swarm is private.
+- The market listing shows, for every offer, the basis and visibility in
+  words a seeder can act on: "Open licence (CC-BY-4.0), public, 7.4 GB,
+  30 days, earns about $1.04". A seeder client MUST show the same.
+- A seeder's own view is a table of leases: what, basis, earned so far,
+  next challenge due, ends on. torlink's `/downloads` grows a `lease`
+  block per torrent.
+- A requester sees, per offer: status, seeders held out of wanted, proven
+  periods, and a spend bar against the budget.
+
+## Success Metrics
+
+- A public swarm with an honoured attestation and a funded offer on
+  bittorrented.com is held by its `seeders.min` within `graceHours`, and
+  still has that many proven seeders at `expiresAt`.
+- A torlink daemon takes a lease, passes every challenge for 30 days, and
+  is paid out without an operator touching it.
+- An `ipfile.pin` job from c0mpute and a `pay2seed.offer` from
+  bittorrented.com are served by the same node with one code path.
+- A notice against a public attestation ends every lease on it within
+  `claimHours` and the requester's standing shows it.
+
+## Risks & Open Questions
+
+- **Sybil seeding.** One machine, many keys, one copy. `seeders.max`,
+  probes to announced addresses, and refusing a shared payout address on
+  one offer bound it; they do not remove it. Open: whether a hub should
+  require a small stake per lease that a failed period forfeits.
+- **Answer relaying on challenges.** A seeder holding nothing can fetch
+  the four pieces inside a ten-minute deadline on a fast link. Probes are
+  the stronger evidence for public swarms; deadlines should scale with
+  piece count. Open: whether a challenge should also demand a piece the
+  swarm currently has no other seeder for.
+- **Claim window versus liveness.** Twenty-four hours before a public
+  offer is listed is a day of nobody being paid. Open: a shorter window
+  for `open-license` and `public-domain` bases, which a licence file in
+  the swarm can substantiate.
+- **Hub as escrow.** Budgets sit with the hub for up to a year. A hub
+  going away takes them. Same trust as `ippay` passes, longer duration.
+  Open: whether budgets should be released to the hub per period rather
+  than at purchase.
+- **Private and `personal` swarms are unreviewable by design.** Consent is
+  the requester's signature and standing, nothing else. This is stated
+  in the spec rather than hidden.
+- **Naming.** The rest of the family uses `ip` names. `pay2seed` is the
+  product name and reads as one to a seeder choosing work; the record
+  types are `pay2seed.*` so the two never need reconciling.
diff --git a/prd/README.md b/prd/README.md
index 4ef71fd..18d2c8c 100644
--- a/prd/README.md
+++ b/prd/README.md
@@ -16,3 +16,4 @@ Status lives in each file's front-matter and is the source of truth:
 | [0003](./0003-add-logicsrc-opencontext-spec.md) | Add the LogicSRC OpenContext specification | Draft | opencontext, context, agents, permissions, provenance, schemas |
 | [0004](./0004-add-logicsrc-opencreds-spec.md) | Add the LogicSRC OpenCreds specification | Draft | opencreds, credentials, vault, encryption, portability, schemas |
 | [0005](./0005-add-logicsrc-openswarm-spec.md) | Add the LogicSRC OpenSwarm specification family | Draft | openswarm, ipfile, ipdb, ipaudio, ipvideo, iplive, bittorrent, x402, c0mpute |
+| [0006](./0006-add-pay2seed-spec.md) | Add pay2seed, paid2seed, pay2stream and paid2stream to the OpenSwarm family | Draft | openswarm, pay2seed, paid2seed, pay2stream, paid2stream, iplive, hls, ipfile, ippay, ipdb, bittorrent, torlink, bittorrented, c0mpute |