Skip to main content
A client is a lightweight QUIC endpoint that streams content from the deCDN and pays nodes per MB. Clients do not stake, do not gossip-publish, and do not earn — they only consume. You might be:
  • An end-user running a CLI or desktop client to download a file.
  • An application — a game launcher, a video player, an update service — embedding the deCDN client library.
  • A content provider’s own bridge pulling content back from the CDN into your infrastructure.

What you do

  1. Bootstrap — generate an iroh key, query the on-chain registry, seed a peer table, subscribe to gossip.
  2. Discover — find which nodes have the blob you want (DHT + probes).
  3. Select — pick the best candidate by the unified score.
  4. Open a channel — on-chain USDC channel with the selected node.
  5. Stream + pay — receive bytes, verify against the BLAKE3 hash, sign per-MB vouchers.
  6. Close — settle the channel on-chain; unspent deposit refunds automatically.

What you need

  • An Ethereum address with USDC (for payments) and a little native gas (for channel opens/closes).
  • An iroh keypair (generated on first run).
  • An internet connection that QUIC can traverse — iroh handles most NATs automatically.

What you don’t need

  • TOKEN holdings (clients don’t stake).
  • On-chain registration (clients are ephemeral; each session uses a fresh NodeId).
  • A constant presence on the network (subscribe to gossip only while you need it).

Trust model in one sentence

You trust what you can verify. BLAKE3 hashes gate every byte; payment channels gate every transfer.

How this tab is organized

PageWhat it covers
Getting startedInstall, first run, simplest fetch
BootstrapKey generation, registry query, peer table, gossip
Account managementEthereum key options, Safe wallets, session keys
Payment channelsOpening, vouchers, cadence, closing, disputes
Trust modelThree-tier boundary: verified, trusted, not trusted