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 |