YOM is a decentralized GPU edge network, built to orchestrate the world’s idle consumer GPUs into one compute grid that serves each session from a node near the user, within about 50 km where the network has one, at a fraction of centralized cloud cost. Gaming is the first workload because it is the hardest: millisecond latency budgets, AAA fidelity and stateful sessions that cannot be paused or retried. The same network is built to run live AI conversations and partners’ own containers as sessions.
The stack spans a custom pixel-streaming solution, secure bare-metal edge computing and HyperOrch, YOM’s edge orchestrator. Together, these components stream games to any device with a browser, with low edge latency and security from boot to stream, at a fraction of the cost of centralized cloud gaming.
The protocol is built on three components: HyperOrch (the edge orchestrator), NodeOS (the node’s read-only operating system) and the Universal Streamer (browser-based pixel streaming). Nodes run on bare metal, no Kubernetes and no virtual machines, so each session reaches the GPU without a hypervisor in the way.
Stateful by Design
Most distributed GPU networks sell GPU-hours for batch and stateless jobs: they route compute to whatever GPU is free. Real-time sessions are fundamentally different. They require stateful execution: game state persists across frames, and input loops are measured in milliseconds.
YOM is built for the session. The same session model carries games, live AI conversations and partners’ own containers, each held for one user next to that user. That captures the real-time work that stateless-only networks structurally cannot serve.
Peer-to-Peer Pixel Streaming
YOM deploys its own lightweight pixel-streaming service that runs games on remote consumer-grade GPUs, encodes each frame on the GPU’s hardware encoder (NVENC, H.264) and streams it back to players over WebRTC, so the player installs nothing. Once a session is approved, the gameplay is delivered over a direct peer-to-peer connection between the node and the player’s device where possible, and through a TURN relay when a firewall or NAT blocks the direct path, so the session still connects.
Video, audio and input travel encrypted in transit with WebRTC’s standard DTLS-SRTP, keeping hops to a minimum and the stream private on public networks.
Universal Streamer & Middleware
Every YOM node runs a middleware layer that orchestrates the full session lifecycle: from preparing the game and starting a GPU-accelerated container (Docker with the NVIDIA Container Toolkit), to managing tunnels, health checks and session teardown. The middleware pulls its instructions from HyperOrch over an outbound connection, so the node needs no open inbound port, and ensures each container is monitored and ready to stream within seconds.
Inside each game container, the Universal Streamer takes over. This lightweight streaming client handles everything a player needs to interact with the game: WebRTC video and audio, low-latency input capture (mouse, keyboard, gamepad, microphone) and adaptive bitrate streaming, all running directly in the browser with nothing to install.
The Universal Streamer is what makes YOM game-agnostic. Players bring the Steam and Epic libraries they already own; studios upload a build. No SDK integration required. The streamer wraps the game’s rendered output, establishes a peer connection to the player’s browser and starts streaming. For developers, onboarding a new title is as simple as uploading a build and embedding an iframe.
Together, the middleware and Universal Streamer form the operational backbone of every node, turning raw GPU power into browser-based sessions at scale.
Node Verification & Telemetry
Every node registers with the network and reports its GPU class, location and load. NANO nodes check their boot files against known hashes at each start; HyperOrch considers only nodes that pass, and a node that fails is quarantined automatically.
During live operation the node reports FPS, latency, bitrate, packet loss and temperatures, and the free rig check measures how many sessions a machine can hold before it ever serves one.
Every session runs in a clean container that is discarded when it ends, so nothing from one user carries over to the next. A NANO’s disk is fully encrypted and unlocks at each start only through YOM’s key service; a device YOM revokes stays locked.
NANO nodes boot a minimal, read-only Linux image from their own drive, apart from the owner’s operating system. On first launch the operating system:
- Auto-detects hardware and installs signed GPU drivers so the discrete card is exposed at full performance (no user intervention required).
- Runs a registration module that links the machine to its operator and reports its GPU capability, location and capacity to HyperOrch.
- Runs each session in its own container, destroyed when the session ends, sharing the GPU with other sessions through the driver’s time-slicing.
HyperOrch: Edge Orchestrator
Workload allocation across the YOM network is handled by HyperOrch, YOM’s edge orchestrator, in production today.
HyperOrch sends each session to the nearest node with the GPU capability and free capacity it needs. HyperOrch filters nodes that are online, carry the session’s game and have a qualifying GPU and free capacity, then sends the start instruction to the nearest one. Nodes without a qualifying GPU or free capacity are passed over, so the nearest node can lose to one that qualifies.
On the node, several sessions share one consumer card today through the GPU driver’s time-slicing.
If the chosen node does not answer, the next qualifying node takes the session. If a node drops mid-session, the player restarts on the next nearby node.
Overflow Capacity & Service Levels
The network’s primary supply is community-operated consumer GPUs, but density takes time to build in any new region. Where operator supply is thin, Walter sessions run on GPUs rented on demand, about 13% of Walter sessions in the first year of the plan, falling to 3% by year five as operator coverage grows.
Service levels set the supply behind each session, and each is stated as a session completion rate: the share of hour-long sessions that finish without a network-caused disconnect, not uptime. On home GPUs (Basic, best effort), the design target is 98% of sessions without a network-caused drop. Protected targets 99.5% of hour-long sessions without a network-caused drop, with most of its sessions on telco racks, and Carrier targets 99.9% on telco racks alone.
Patents
Patent-pending technology across the secure boot medium, pixel streaming and orchestration.