argus/DESIGN-hosting-pact.md

# Argo — the hosting pact: dilution-pool incentives for serving the decentralized web

*Argo is the host network; the hosts who crew it are **Argonauts**. Part of the
Silent Mode stack (hub: `D:\Dev\SilentMode\README.md`).*

Status: design idea (July 2026). Not yet implemented. Companion to
[PROTOCOL.md](PROTOCOL.md); assumes BNS names on BCH and content on a storage
network (Sia, IPFS, or on-chain `h` records).

## The idea in one paragraph

A site owner funds a **pool** tied to their name's content (monthly / quarterly
/ yearly). Hosts **join permissionlessly** — no one selects them — by bonding a
small stake and proving they store/serve the content. Each epoch the pool pays
out, **split among all current provers**. More hosts → thinner slices; fewer
hosts → fatter slices. Replication count is not configured anywhere: it is the
*equilibrium* of pool size vs. hosting cost, discovered continuously by the
market. Paying more is the owner's only knob — and it directly buys more
redundancy and serving capacity. Client software suggests a price from the
median of on-chain host asks.

## How Sia works, for contrast

Sia is **renter-driven, closed-membership**: the customer's agent (`renterd`)
scans the host market, *selects* ~30 specific hosts, forms bilateral fixed-term
contracts with each, monitors them, and migrates shards when hosts die. Hosts
advertise general capacity and wait to be picked; they cannot volunteer for a
specific dataset. Repair requires the renter's agent to be online and funded.

## Why Sia's model is not enough (for websites)

1. **A manager must exist.** Sia heals because *renterd* notices dead hosts
   and re-uploads. If the renter agent is offline or unfunded, redundancy
   silently decays. The pool heals **without any manager**: a dead host stops
   proving → its share flows to the survivors → each slice fattens → the pool
   becomes more attractive → new hosts join. The noticing is done by
   economics, not by an agent. This is the core automation the idea adds.
2. **Membership is closed.** In Sia, a host that *wants* to help serve a
   popular site cannot join its contract set. In the pool, joining is the
   default; the algorithm that "decides who hosts" is replaced by
   self-selection under price pressure (the same open-entry mechanism as
   Bitcoin mining: reward fixed, participants join until marginal profit ~ 0).
3. **No serving incentive.** Sia pays for *storage possession*, never for
   *serving the public* — the gap that killed Skynet (decentralized storage,
   centralized unpaid portals). The pool's payout can cover gateways/seeders,
   the actually-scarce resource for websites.
4. **Designed for private data.** Sia encrypts client-side and hides data from
   hosts — right for backups, unnecessary for websites, which are public
   goods. Public content is exactly the case where open membership is safe:
   there is nothing to leak, and anyone may legitimately serve it.
5. **Lifetime is administrative, not economic.** Sia contracts expire per
   contract term. A pool's site lives exactly as long as someone values it
   enough to fund it — a market-driven expiry that doubles as the namespace
   garbage collection Namecoin lacked (cf. Kalodner et al. 2015).

## Known hard problems (and mitigations)

- **Sybil splitting** — one disk posing as N hosts to collect N shares.
  Mitigate: per-host-unique erasure-coded shards (k-of-n), so each identity
  must store distinct data; stake per identity; diminishing returns per new
  host as slices thin.
- **Proof of possession** — challenge from a future block hash → Merkle proof
  over the host's shard. Verifiable in a BCH covenant post-May-2025 limits
  (clunky but plausible); v0 can verify in an auditable coordinator.
- **Proof of serving** — unprovable on-chain (true for Filecoin/Sia too).
  Layered approach: watchtower spot-checks, client-side reputation, coordinator
  attestation; shrink the trusted surface over versions.
- **Pool exhaustion** — funding dries up → hosts leave → site dark. Feature,
  not bug (see 5 above), but resolvers should surface "pool low" warnings so
  owners/fans can top up (anyone may pay into a pool — patronage built in).

## Sketch on BCH

1. Site → storage network → per-host shards (off-chain tooling).
2. Name's chain record: `{"cid"|"s3": ..., "pact": <pool id>}`.
3. Hosts post asks via beacon txs; wallets suggest the median (owner's knob).
4. Pool = covenant UTXO funded by owner (or anyone); hosts join by bonding
   stake in a registration tx naming their shard commitment.
5. Per epoch: block-hash challenge → hosts submit proofs → covenant releases
   the epoch tranche split among provers; missed proof = no pay (+ stake slash
   on repeated failure).
6. Resolvers discover hosts from registrations and fetch from any of them.

## Version ladder

- **v0** — coordinator does audits + payouts openly on chipnet (trusted but
  fully auditable; all money flows on-chain).
- **v1** — possession proofs verified by CashScript covenant; coordinator only
  attests serving quality.
- **v2** — multi-watchtower serving attestation, coordinator eliminated.