What happens during a session

A YOM session is mostly invisible from your side as an operator. Your GPU light comes on, your network upload climbs, the session counter increments. But under the hood, a tightly orchestrated pipeline is moving frames from your machine to a player’s browser at roughly 60 fps with sub-50 ms latency. Here’s what’s happening.

step 1: player clicks “play” on a YOM-enabled site

A player visits a YOM-enabled site (yom.net/demo, walter.gg, a Steam-integrated page, a publisher’s site) and clicks to start a game. The YOM player runs in their browser. It sends a session-start request to the matchmaker.

step 2: matchmaker picks your node

The matchmaker has a real-time index of every active node, ranked by:

• Latency to the player’s IP (lowest = highest priority)
• Capacity available (how many free session slots the node has)
• Game compatibility (does the node have the game’s container image cached, or does it need to download it first)
• Recent reliability (nodes that have completed sessions cleanly outrank nodes that have dropped recent ones)

If your node wins the routing decision, the matchmaker sends an instruction to your node’s middleware over a persistent WebSocket: “Start container X for session Y.”

step 3: your node spins up the game container

Your node runs Docker with NVIDIA container toolkit. The middleware pulls the game’s pre-built container image (cached locally if you’ve hosted this game before; downloaded on first request, takes a few minutes). The container starts with GPU passthrough, mounts a fresh session-scoped storage volume, and launches the game in a windowed mode the encoder can capture.

Total cold-start time: 5-15 seconds depending on game size and disk speed. Warm-start (cached image): under 3 seconds.

step 4: the streaming loop

This is where your GPU’s NVENC encoder earns its keep. The loop, repeating ~60 times per second:

1. Game renders a frame to a virtual display surface
2. NVENC encodes the frame as H.264 or H.265 (decided per session based on the player’s browser support)
3. The encoded frame is shipped through a WebRTC peer connection straight to the player’s browser, bypassing the matchmaker entirely
4. The player’s browser decodes and paints the frame
5. The player’s input (keyboard / mouse / controller) is sent back to your node over the same peer connection
6. Your node’s middleware injects the input into the container as if it were a local keyboard / mouse

End to end, this loop runs in 30-50 ms when everything is healthy. The player perceives it as roughly the latency of a high-refresh local PC. Sub-30 ms feels indistinguishable from local play.

step 5: session ends

A session ends when the player closes the tab, the game itself quits, or the network detects a long stall (e.g., the player’s connection dropped and didn’t recover within 30 seconds). When the session closes:

1. Your node tears down the container and frees the GPU slot
2. The middleware reports session duration, frames served, and quality metrics back to the matchmaker
3. The matchmaker writes a session record to the database with the operator share, studio share, and treasury share computed

That record is what eventually drives the 40% operator payout into your wallet.

step 6: settlement

Every 24 hours on average, the settlement contract on Avalanche reads the queue of pending session records, sums earnings per wallet, and emits an on-chain ERC-20 transfer to each operator. Your wallet receives $YOM. The transaction is visible on Snowtrace.

You don’t sign anything. The contract is permissionless and trustless: it follows the rules in its deployed code, which is verified and unchangeable except via the multisig timelock.

what an operator sees on the dashboard

While all this is happening, your operator dashboard:

• Increments the sessions counter the moment the session ends
• Updates earnings today when the settlement batch runs
• Adjusts avg latency based on the player’s measured RTT during the session
• Logs the session in your Earnings page with the game name, duration, and operator share

You can dig into any individual session for the full breakdown. Everything is auditable.

what makes a session good vs bad

Good session (drives high routing priority for future sessions):

• Latency stayed under 50 ms throughout
• No frame drops > 1%
• Session ran to completion without disconnects
• Heartbeat consistent

Bad session (drops your routing priority temporarily):

• Latency spiked above 100 ms repeatedly
• Frame drops > 5%
• Session terminated abnormally
• Heartbeat gaps during the session

The matchmaker remembers and prioritizes accordingly. A node with a string of bad sessions sees less traffic until reliability improves.