> For the complete documentation index, see [llms.txt](https://docs.blockcast.network/main/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blockcast.network/main/overview/the-blockcast-relay.md). # The Blockcast RELAY **The Blockcast RELAY** is the workhorse node of the Blockcast network — a compact, plug-and-play device that combines edge caching with AMT multicast relaying, deployed wherever an operator has spare capacity and an interest in monetizing it. A RELAY caches popular content close to viewers and extends multicast reach into networks that can't peer directly with a CAST node. The operator running it earns weekly rewards proportional to verified bandwidth, uptime, and content served — settled on-chain through the Proof of Bandwidth system. ### What is a Blockcast RELAY, and How is It Different? Traditional CDN edge servers are commodity reverse-proxies (Varnish, NGINX, ATS) deployed by the CDN itself, paid for as bulk infrastructure, and operated as a closed system. A **Blockcast RELAY** is the same kind of edge server — but contributed by an independent operator inside their own network, registered to the Blockcast network on-chain, and verified continuously by the protocol: * **Edge cache:** Stores popular content close to viewers so requests don't have to traverse ISP transit to a distant CDN. Same role as a traditional CDN edge. * **AMT relay:** Tunnels multicast streams over unicast on RFC 7450, extending TreeDN multicast coverage to networks that can't peer directly with a CAST source. Linux kernel AMT runs by default; Juniper MX hardware offload is supported for higher tunnel scale. * **Verified capacity:** Bandwidth commitments per network interface are measured by speedtest, attested to on-chain, and re-verified periodically by the Proof of Bandwidth challenge system. * **Operator-owned:** The node belongs to whoever provisions it. Rewards accrue to the operator's wallet, not to a CDN vendor. This combination lets ISPs, IXes, and independent operators contribute capacity to a shared streaming substrate without giving up control of their infrastructure — and lets content providers reach audiences through a wider, more resilient edge footprint than any single CDN vendor can offer alone. ### How is a RELAY Node Provisioned and Managed? A RELAY is onboarded through the Blockcast portal in six steps, then operated autonomously with portal-side observability. Going live is gated: after onboarding, a node must pass reachability, capacity and attestation, and health and uptime checks before it is promoted, so a misconfigured node can't go live and start charging the network. **Provisioning:** * **Register:** The operator installs the Blockcast RELAY runtime, runs `blockcastd init` to produce a Hardware ID and EC P-384 Challenge Key, and registers the node in the portal. The node starts as a **BEACON** (attestation-only). * **Stake to upgrade:** Staking tokens on-chain upgrades the node from BEACON to RELAY status, unlocking caching, bandwidth commitments, and full rewards. * **Allocate storage and RAM:** The operator selects which physical disks (or a virtual disk path) hold the cache, and dedicates an in-memory cache tier via a RAM slider. * **Commit bandwidth:** The portal auto-detects network interfaces, runs a per-interface speedtest, and the operator commits a threshold per interface (defaults to 80% of measured). The detected ASN and cache group are pinned to the operator's verified autonomous system. * **Optional AMT hardware offload:** Linux kernel AMT handles hundreds of tunnels per node by default. Operators with Juniper MX routers can offload AMT to dedicated hardware for thousands of tunnels at line rate. * **Verification gate:** Before going live, the portal validates that ports 53 (DNS), 80 (HTTP), 443 (HTTPS/QUIC), and 2268 (AMT) are reachable, and that Traffic Monitor, Traffic Router, the cache process, and the AMT relay all report healthy. **Management:** * **My Nodes dashboard:** Live health, uptime, and per-node controls — rename, transfer ownership, or drill into per-interface metrics. * **Traffic Monitor probes every 10 seconds** for liveness and performance; unhealthy nodes are routed around within seconds. * **Proof of Bandwidth challenges** run periodically against the committed thresholds and record verified capacity. Rewards scale with verified — not just claimed — bandwidth. * **Traffic Router** picks RELAYs for each request based on geography, current health, and verified capacity; the routing decision is saturation-aware across the cache group. * **DRIAD discovery (RFC 8777):** Clients performing AMT discovery reach the topologically nearest RELAY automatically — no separate signaling infrastructure to operate. For the step-by-step onboarding guide with portal screenshots, see [Start Running your RELAY](/main/getting-started/how-do-i-participate-in-the-network/relay.md). For Juniper MX hardware offload, see [Juniper MX AMT Hardware Offload](/main/getting-started/how-do-i-participate-in-the-network/relay/relay-amt.md). ### RELAY in the TreeDN Architecture (RFC 9706) The RELAY is the **edge tier** of the TreeDN tree-based CDN architecture defined in [RFC 9706](https://datatracker.ietf.org/doc/rfc9706/) — fanning multicast streams out to the last-mile while serving cached unicast HTTP to clients that can't or won't speak multicast directly. The Blockcast TreeDN implementation consists of: * **CAST nodes** as multicast content sources (ROUTE/FLUTE or MoQ-MMT) * **RELAY nodes** as AMT relays and edge caches extending multicast coverage — the role this document describes * **BEACON nodes** as deep-edge receivers on modems, TVs, phones, and browsers * **DRIAD discovery** (RFC 8777) for automatic nearest-relay selection For a detailed technical walkthrough, see [TreeDN: Multicast Content Delivery](/main/overview/control-plane/treedn-multicast.md) and [AMT Relays & Multicast Backbone](/main/overview/control-plane/treedn-multicast/amt-relays.md).