diff --git a/apps/logicsrc-web/src/app/openswarm/page.tsx b/apps/logicsrc-web/src/app/openswarm/page.tsx
index fcaed91..9db3725 100644
--- a/apps/logicsrc-web/src/app/openswarm/page.tsx
+++ b/apps/logicsrc-web/src/app/openswarm/page.tsx
@@ -18,7 +18,10 @@ const PROTOCOLS: Array<[name: string, line: string]> = [
   ["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"],
-  ["pay2seed", "Consent at upload, seed offers with escrowed budgets, leases, proof of seeding, and the market a seeder client picks work from"]
+  ["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 d6a012b..aedd2ae 100644
--- a/docs/openswarm.md
+++ b/docs/openswarm.md
@@ -34,7 +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` | Consent at upload, seed offers with escrowed budgets, leases, proof of seeding, the seed market | [`pay2seed.md`](./openswarm/pay2seed.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:
 
@@ -51,8 +54,10 @@ Supporting documents:
   |  ipaudio      ipvideo      iplive         ipdb (catalogue)    |
   |  releases     titles       channels       feeds, entries      |
   +---------------------------------------------------------------+
-  |  pay2seed: attestation, offers, leases, challenges, market    |
-  +---------------------------------------------------------------+
+  |  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 |
   +-------------------------------+-------------------------------+
@@ -135,12 +140,19 @@ 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.** 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.
-Seeders take leases, prove they hold and serve the pieces every period, and
-are paid per GiB-month. 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.
+**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
 
diff --git a/docs/openswarm/cli.md b/docs/openswarm/cli.md
index 4ab153e..5b191f4 100644
--- a/docs/openswarm/cli.md
+++ b/docs/openswarm/cli.md
@@ -130,7 +130,7 @@ 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 market
+### 2.10 Seed and stream markets
 
 ```
 ip seed attest (<file key> | <infohash> | <magnet>) --basis own|licensed|open-license|public-domain|personal
@@ -145,8 +145,17 @@ ip seed void   <offer id>                            # requester: void and refun
 ip seed notice <attestation id> --kind rights|illegal|personal-data|other --statement <text>
 ```
 
-`ip seed attest` is the consent step and is what `ip file add --public` and
-`ip file pin` call first; `ip seed offer` on a private file key includes a
+```
+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
diff --git a/docs/openswarm/paid2seed.md b/docs/openswarm/paid2seed.md
new file mode 100644
index 0000000..48d38fa
--- /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` §7) 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`
+§5.1). The requester side is `pay2seed` §5.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
index 6bd6352..c41bcec 100644
--- a/docs/openswarm/pay2seed.md
+++ b/docs/openswarm/pay2seed.md
@@ -1,73 +1,58 @@
-# pay2seed: Consent, Seed Offers and the Seed Market
+# 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).
+and [`ipdb`](./ipdb.md). Its server half is [`paid2seed`](./paid2seed.md).
 
 ## 1. Scope
 
-`pay2seed` is how somebody pays to have data kept alive on a swarm by
-machines they do not control, and how the people running those machines are
-paid for it. It turns a torrent client into a legitimate file sharer: every
-swarm on the market carries a signed statement of who put it there and on
-what basis, every seeder holds a lease that says what they were asked to
-keep and for how long, and every payout is backed by proof that the bytes
-were held and served.
-
-It covers:
+`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, a minimum number of seeders and a proof cadence. Public offers
-  cover vanilla torrents and `ipdb` feeds; private offers cover `ipfile`
-  swarms, whose ciphertext a seeder holds without ever being able to read.
-- **Leases.** The hub's binding of one seeder to one offer for one period at
-  one price.
-- **Proof of seeding.** Storage challenges answered from the held pieces, and
-  probes in which a verifier fetches pieces over the ordinary wire. Both work
-  on a vanilla torrent, which is what makes public seeding payable.
-- **Settlement.** GiB-month accrual per proven period, receipts, and payout
-  through an `ippay` hub. Served-byte vouchers, where the swarm charges for
-  them, are separate and additive.
-- **The market.** A hub API that lists open offers so a client can pick
-  work, and a seeder client's expected behaviour.
+- **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.
+- **The requester's view of the market**, of standing, and of notices.
 
-`ipfile.pin` ([c0mpute](./c0mpute.md) §3.1) is this document's offer shape
-carried on c0mpute's job auction. `pay2seed` is the same request opened to
-any seeder: a torlink daemon on a seedbox, a laptop that is on most of the
-day, a c0mpute node. A node MAY treat a `pay2seed.offer` as an `ipfile.pin`
-job and vice versa; §11 gives the mapping.
+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 the attestation is true is the requester's
-liability, and §9 is how a false one is undone. Not a DRM: a public swarm is
-public, a private swarm is `ipfile`'s encryption and no more. Not a token.
-Not a replacement for `ippay` vouchers: a swarm that charges leechers keeps
-charging them, and its seeders earn both ways.
+is honoured on notice; whether it is true is the requester's liability, and
+§7 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.
-- **Seeder.** An identity that holds a lease and serves the swarm.
-- **Hub.** An `ippay` hub that also implements this document's API (§7).
-  bittorrented.com is the reference hub.
-- **Verifier.** Whoever issues challenges and probes: the hub, a c0mpute
-  verifier node, or the requester. A lease names who may.
-- **Attestation.** The consent record (§3).
-- **Offer.** The request (§4). **Lease.** One seeder's share of it (§5).
+  publisher of the swarm; for a public torrent it may be anyone who wants
+  it kept alive, subject to §3.
+- **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, readable by
-  anyone) or `private` (an `ipfile` swarm; ciphertext only).
+- **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. Every
-record below is a core §3 record with the `type` shown.
+Keys, records, signatures, amounts and times are as in the core.
 
 ## 3. Consent: the attestation
 
@@ -95,18 +80,18 @@ offer, and every offer for that swarm references it.
 
 | Field | Rule |
 | --- | --- |
-| `subject` | Exactly one of `file` (an `ipfile` file key; visibility MUST be `private`) or `infohashV1`/`infohashV2` (at least one; visibility MUST be `public`). A feed offer (§4.4) attests the feed key in `file`. |
-| `visibility` | `public` or `private`. Fixed for the life of the swarm; changing it is a new swarm. |
-| `basis` | Why the requester may distribute this. One of the values in §3.2. |
-| `license` | REQUIRED when `basis` is `open-license`: an SPDX identifier. Otherwise OPTIONAL. |
+| `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 (§9). REQUIRED for `public`; OPTIONAL for `private`, where the hub's own contact for the requester's account stands in. |
+| `notice` | An HTTPS URL or `mailto:` at which the requester receives notices (§7). REQUIRED for `public`. |
 | `acceptsTakedown` | MUST be `true`. Present so the acceptance is in the signed bytes. |
 
-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 is what stands in for it.
+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
 
@@ -116,35 +101,33 @@ infohash no such proof of authorship exists; §3.3 is what stands in for it.
 | `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. Nobody else is meant to read it. | `private` only |
+| `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 MUST reject any attestation with an unlisted `basis`.
-Hubs MAY refuse to list particular bases (a hub for personal backup only, a
-hub for open data only); the hub record says which (§7.1).
+with this table, and any with an unlisted `basis`. Hubs MAY refuse to list
+particular bases; the hub record says which (§5.1).
 
 ### 3.3 Public infohashes and the claim window
 
-Anyone can attest a public infohash, so the attestation is a claim, not a
-proof. 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 to anyone following the
-hub's `pay2seed.offer.listed` event, and a notice (§9) voids it. An offer
-for a swarm that already has an honoured attestation from a different key
-is refused unless the new attestation's basis is `open-license` or
-`public-domain`, which are the two bases that do not depend on who is
+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 (§7.5) 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 attestations in the last year.
+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 exactly as an `ippay` pass is bought, so the budget is
-settled before anyone starts seeding.
+bought from the hub as an `ippay` pass is, so the budget is settled before
+anyone starts seeding.
 
 ### 4.1 Record
 
@@ -175,19 +158,19 @@ settled before anyone starts seeding.
 
 | Field | Rule |
 | --- | --- |
-| `hub` | The hub that sold it and holds the budget. Signer of the record. |
+| `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 this offer's. |
+| `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 torrent payload size. For a feed, the size at posting; §4.4 says how growth is paid. |
+| `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 the hub will hand out before the offer is `active`. `max` caps them; extra seeders beyond `max` earn only vouchers. |
-| `priceUsdPerGibMonth` | What one seeder earns for holding the whole swarm for 30 days, pro rata. |
-| `budgetUsd` | Escrowed. MUST be at least `max * priceUsdPerGibMonth * sizeBytes/2^30 * days/30`, rounded up to six places. |
-| `proof.everyHours` | Period length. 1 to 168. |
-| `proof.verifiers` | Who may challenge: `hub`, `requester`, or `c0mpute` (any node with `c0mpute:role:verifier`). |
-| `pass` | For a `private` swarm whose `pricing.perGib` is non-zero: an `ippay.pass` scoped to the file, so a seeder can fetch it as a paying peer. `null` otherwise. |
-| `trackers` | Announce URLs the seeder MUST add. At least one `wss://` tracker when the requester wants browser peers to find it. |
+| `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`. |
 
@@ -195,198 +178,49 @@ settled before anyone starts seeding.
 
 `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 (§6.3), exactly as `ippay` §3.2
-answers a pass purchase, and with the same `X-OpenSwarm-Payer` binding.
-Repeating the request with a valid proof answers `201` with the signed
-offer. A hub MUST verify the referenced attestation before quoting, and MUST
+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`, and then `settled`. It is `voided` by a notice (§9) or by
-the requester (`DELETE /offers/<id>`, signed), in which case the unearned
-budget is refunded to the requester's registered payout address, less what
-leases have accrued.
+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. The seeder fetches it from the swarm
-like any client, using `trackers` and the DHT, and serves plaintext. Nothing
-in the wire changes; the only new thing on the network is another well
-behaved seeder that stays. This is how a podcast archive, a dataset, a
-software release or an out-of-print recording with a clean basis gets kept
-alive by strangers who are paid for it.
+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. A leased seeder MUST follow the feed (`ipdb` §5.4),
-fetch each new segment within one period of its appearance in the head,
-seed all of them, and re-announce the head as a BEP 44 mutable item at least
-once per period so the catalogue stays findable when the publisher is
-offline. `sizeBytes` is the feed's size at posting; each new segment is
-added to the lease's accrual base at the period in which it was 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.
+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,
-unless it also holds a grant, cannot read a byte of it. 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: what is being paid
-for is storage of a specific swarm, and what the attestation says is that
-the requester may store it. `personal` is the basis for a backup nobody else
-is ever meant to read; the swarm's `pricing` SHOULD be zero and its manifest
-SHOULD not be catalogued.
+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. Leases
+## 5. The requester's hub
 
-### 5.1 Record
+### 5.1 Hub record
 
-```json
-{
-  "openswarm": "0.1",
-  "type": "pay2seed.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 offer. |
-| `seeder` | The seeder key. It MUST be a registered `ippay` payee (§6.4), which is where the money goes. |
-| `slot` | 1-based, at most `offer.seeders.max`. A seeder holds at most one lease per offer. |
-| `priceUsdPerGibMonth` | Copied from the offer at lease time so a later offer 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.
-
-### 5.2 Taking a lease
-
-`POST /leases` with `{ "offer": <id>, "seeder": <key>, "sig" }`, `sig` by
-the seeder key over `"openswarm:pay2seed:lease:v1" || offer id`. The hub
-answers `201` with the lease, or `409` when the offer has no free slot or
-this seeder already holds one, or `403` when the seeder's standing (§7.5)
-is below the offer's or hub's floor.
-
-A hub SHOULD hand out slots to seeders in order of standing, and MUST NOT
-hand more than `seeders.max`. A seeder SHOULD NOT take a lease it cannot
-serve within `graceHours`; an abandoned lease counts against standing.
-
-## 6. Proof and settlement
-
-### 6.1 Storage challenges
-
-Once per period, a verifier named in the offer sends the seeder:
-
-```json
-{
-  "openswarm": "0.1",
-  "type": "pay2seed.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` with a proof:
-
-```json
-{
-  "openswarm": "0.1",
-  "type": "pay2seed.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 that holds the piece hashes and a copy of the piece can
-check, and which cannot be answered from the hash alone. A verifier that
-does not hold the pieces (the hub, for a swarm it does not store) uses a
-probe instead. `pieces` MUST be at least four indices chosen uniformly at
-random per challenge; `deadline` MUST be at least ten minutes after
-`createdAt`, which is enough to read four pieces from a spinning disk and
-not enough to fetch them from the swarm.
-
-### 6.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 as the proof record's `answers` equivalent, with
-`type` still `pay2seed.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 vouchers are the seeder's
-in the usual way. Hubs SHOULD prefer probes for public swarms, whose pieces
-anyone can fetch, and challenges for private swarms they already pin.
-
-### 6.3 Accrual and receipts
-
-A lease earns, for each period in which its proof passed:
-
-```
-earnedUsd = priceUsdPerGibMonth * (sizeBytes / 2^30) * (everyHours / 720)
-```
-
-computed with integer arithmetic in 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. Earned amounts are
-credited to the seeder's `ippay` payee balance and reported with a receipt:
-
-```json
-{
-  "openswarm": "0.1",
-  "type": "pay2seed.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": "…" }]
-}
-```
-
-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.
-
-### 6.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.
-
-## 7. The hub
-
-### 7.1 Hub record
-
-An `ippay.hub` record that offers this document adds:
+An `ippay.hub` record that offers this family adds:
 
 ```json
 "pay2seed": {
@@ -399,90 +233,45 @@ An `ippay.hub` record that offers this document adds:
 }
 ```
 
-`bases` is what this hub will list. `minStanding` is the floor for taking a
-lease. A hub MAY run a market for private backups only, or for open data
-only, by narrowing `bases`.
+`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`.
 
-### 7.2 API
+### 5.2 API, requester side
 
-All bodies are JSON. Records are verified on receipt. Paths are relative to
-`pay2seed.base`.
+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 an attestation. `201` with its id, `409` if one is honoured for the subject by another key (§3.3). |
+| `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: open offers with free slots, newest first, paged. |
-| `GET /offers/<id>` | none | The offer, its status, leases held, slots free. |
+| `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. |
-| `POST /leases` | seeder signed | Take a slot (§5.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. |
-| `POST /proofs` | seeder or verifier signed | Answer a challenge or report a probe. Returns the receipt. |
-| `GET /leases/<id>/challenges?since` | seeder | Pending challenges for a seeder that cannot receive them pushed. |
-| `GET /seeders/<key>` | none | `{ "standing", "leases", "proven", "failed", "abandoned", "balanceUsd" }`. |
 | `GET /requesters/<key>` | none | `{ "standing", "attestations", "voided", "offers" }`. |
-| `POST /notices` | signed | A notice against an attestation (§9). |
-| `POST /webhooks` | signed | Register a CloudEvents endpoint for a requester or seeder key. |
+| `POST /notices` | signed | A notice against an attestation (§7). |
+| `POST /webhooks` | signed | Register a CloudEvents endpoint for a requester key. |
 
-### 7.3 Delivering challenges
+## 6. Requester client behaviour
 
-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 from delivery, so a seeder that polls slowly fails
-challenges; the cadence is the seeder's problem to meet.
+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:
 
-### 7.4 The market listing
+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.
+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.
 
-`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.
-
-### 7.5 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. Standing is public at `GET /seeders/<key>` and
-`GET /requesters/<key>`, and portable in the sense that it is one hub's
-opinion signed by that hub; a second hub MAY read it and MAY ignore it.
-
-## 8. 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 the client's own reaper never drops a
-   swarm it is being paid to keep.
-4. Answers challenges from local pieces within `deadline`, and serves
-   probes as ordinary peer traffic.
-5. On restart, resumes every lease in `GET /seeders/<key>/leases?status=proven,fetching`
-   before taking new ones.
-6. 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.
-7. Shows the operator, for every held lease, the `basis`, `visibility`,
-   `earnedUsd` so far, and the next challenge due.
-
-A requester client (`ip` CLI, a web app) makes the attestation, buys the
-offer, and watches `GET /offers/<id>` or the events.
-
-## 9. Notices and takedown
+## 7. Notices and takedown
 
 Anyone may `POST /notices` against an attestation:
 
@@ -502,88 +291,47 @@ Anyone may `POST /notices` against an attestation:
 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, seeders are told by event and by their next
-poll, the requester is refunded the unearned budget less leases' accrued
-earnings, and the requester's `voided` count rises. A hub that voids on
-every notice without review is conformant; a hub that never voids is not.
+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, their attestation and
-their standing, which is what accountability looks like for ciphertext.
+pretend to. What it has is the requester's identity, attestation and
+standing, which is what accountability looks like for ciphertext.
 
-## 10. Security notes
+## 8. 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 the same
-  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.
-- **Hub as escrow.** The budget sits with the hub. A requester trusts the
-  hub with `budgetUsd` for `days`, as a pass buyer trusts it with `capUsd`
-  for 30. A hub's signed receipts and refunds are its auditable trail.
 - **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.
-- **Private means ciphertext, not secret existence.** A lease reveals to
-  its seeder the file key, the size and the requester's key. `personal`
-  swarms SHOULD use a fresh unrelated file pair (core §4.2) so that backups
-  are not linkable to a publisher's catalogue.
+- **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.
 
-## 11. 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 §6.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.
-
-## 12. 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 |
-| `pay2seed.lease.granted`, `.proven`, `.lapsed`, `.ended`, `.voided` | lease id, period, `earnedUsd` | seeder, requester |
-| `pay2seed.challenge.issued` | the challenge record | seeder |
-| `pay2seed.notice.received`, `.resolved` | notice id, outcome | requester |
-
-## 13. Implementations
+## 9. Implementations
 
 | Piece | Where | Status |
 | --- | --- | --- |
-| Reference hub: attestations, offers, leases, probes, market, notices | `profullstack/media-streamer` (bittorrented.com) | planned; the seedbox rental rail is the pay-per-pass half of it today |
-| 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 client and promo library | `@profullstack/pay2seed` | planned |
-| Seeder and verifier on the storage network | `profullstack/c0mpute` via `ipfile.pin` | mapping in §11 |
+| 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 |
 
-## 14. Conformance
+## 10. Conformance
 
-A **hub** is conformant 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); issues at least one challenge or
-probe per period and pays only proven periods (§6); publishes the market
-and standing (§7); forwards and resolves notices within `claimHours` (§9).
+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 **seeder client** is conformant when it does all of §8.
+A **requester client** is conformant when it does all of §6.
 
-A **requester client** is conformant when it makes an attestation the
-signer actually holds the key for, buys offers only against it, and
-receives notices at the `notice` endpoint it named.
+## 11. Version history
 
-## 15. Version history
-
-- 0.1 (2026-09-05): first draft. Attestation with basis table and claim
-  window; offers bought over x402 with escrowed budgets; leases with
-  slots and grace; challenges and probes; GiB-month accrual and receipts;
-  public feeds on `ipdb`; notices; the `ipfile.pin` mapping.
+- 0.1 (2026-09-06): split out of the first pay2seed draft (2026-09-05) as
+  the client half; attestation, offers, requester API, notices.
diff --git a/docs/openswarm/pay2stream.md b/docs/openswarm/pay2stream.md
new file mode 100644
index 0000000..71739ff
--- /dev/null
+++ b/docs/openswarm/pay2stream.md
@@ -0,0 +1,251 @@
+# 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.
+
+## 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` §7; 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` §10 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 994379d..b483535 100644
--- a/docs/openswarm/spec.md
+++ b/docs/openswarm/spec.md
@@ -502,11 +502,17 @@ 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 file's publisher key for `ipfile` subjects) | pay2seed |
-| `pay2seed.offer`, `pay2seed.lease`, `pay2seed.receipt` | hub key | pay2seed |
-| `pay2seed.challenge` | verifier key | pay2seed |
-| `pay2seed.proof` | seeder key, or verifier key for a probe | pay2seed |
+| `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 |
+| `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/prd/0006-add-pay2seed-spec.md b/prd/0006-add-pay2seed-spec.md
index 6924909..981b3ef 100644
--- a/prd/0006-add-pay2seed-spec.md
+++ b/prd/0006-add-pay2seed-spec.md
@@ -1,7 +1,7 @@
 ---
 openprd: "0.2"
 id: "0006"
-title: "Add pay2seed to the OpenSwarm family: consent at upload and a paid seed market"
+title: "Add pay2seed, paid2seed, pay2stream and paid2stream to the OpenSwarm family"
 status: Draft
 authors:
   - anthony@profullstack.com
@@ -13,6 +13,11 @@ implementation:
 tags:
   - openswarm
   - pay2seed
+  - paid2seed
+  - pay2stream
+  - paid2stream
+  - iplive
+  - hls
   - ipfile
   - ippay
   - ipdb
@@ -49,6 +54,15 @@ 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
@@ -107,19 +121,26 @@ money has no way to say so that anyone else can check.
 
 ## Requirements
 
-1. `docs/openswarm/pay2seed.md` specifies: the attestation record and
+1. `docs/openswarm/pay2seed.md` and `paid2seed.md` together specify: the attestation record and
    basis table; the claim window and requester standing; the offer record,
    its purchase over x402, and its lifecycle; public swarms, public feeds
    on `ipdb`, private swarms; the lease record and slot rules; storage
    challenges and probes; GiB-month accrual, receipts and payout through
    `ippay`; the hub record extension and API; seeder client behaviour;
    notices and takedown; the `ipfile.pin` mapping; events; conformance.
-2. `docs/openswarm.md` lists `pay2seed` in the family table, the stack
+1b. `docs/openswarm/pay2stream.md` and `paid2stream.md` specify the
+   same for a live channel over `iplive`: consent for channels with the
+   two rules for licensed feeds; relay offers per relay-hour with a
+   gateway bonus; tickets and listings; 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.
+2. `docs/openswarm.md` lists the four in the family table, the stack
    diagram, "What it defines" and "What already exists".
-3. `docs/openswarm/spec.md` §11 registers the six `pay2seed.*` record
+3. `docs/openswarm/spec.md` §11 registers the `pay2seed.*`, `paid2seed.*`, `pay2stream.*` and `paid2stream.*` record
    types and their signers.
-4. `docs/openswarm/cli.md` gains the `ip seed` command group.
-5. The `/openswarm` page on logicsrc.com lists `pay2seed` among the
+4. `docs/openswarm/cli.md` gains the `ip seed` and `ip stream` command groups.
+5. The `/openswarm` page on logicsrc.com lists the four among the
    protocols.
 6. Implementations, tracked outside this repo:
    - bittorrented.com (`profullstack/media-streamer`): the reference hub.
diff --git a/prd/README.md b/prd/README.md
index 4b5782c..18d2c8c 100644
--- a/prd/README.md
+++ b/prd/README.md
@@ -16,4 +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 to the OpenSwarm family: consent at upload and a paid seed market | Draft | openswarm, pay2seed, ipfile, ippay, ipdb, bittorrent, torlink, bittorrented, 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 |