Every time someone hits “Play” on a platform powered by YOM, a small economic engine spins up behind the scenes. When you are deep in the day-to-day of running a node or building on the protocol, it is easy to lose sight of how the pieces fit together. Here is what a single gaming session actually does, and how it creates value for everyone keeping the network running.
What happens when you click “Play”
A YOM session begins when a player requests a game through a web app or a platform like Walter.gg, and HyperOrch, YOM’s AI scheduler, picks the node that will serve it. It looks across the whole network and matches the request to the best available machine.
“Best” is not simply “nearest”. HyperOrch continuously collects a capability vector from every node: available GPU and CPU headroom, memory, bandwidth, encoder load, thermal headroom. Each game title carries a resource footprint of its own. The scheduler predicts the expected frame rate for that game on each candidate node and ranks them on latency, hardware suitability and current load together. It also learns from the outcome, so placement gets better with every session.
The chosen node boots the game and streams it back to the player over WebRTC. Edge latency holds sub-12ms, close enough that the session feels local even though it is running on someone else’s hardware.
That someone else’s hardware is the whole point. Node operators plug a NANO device into a standard gaming PC. It is plug-and-play and secure-boot, and it turns a PC into a trusted, isolated node in minutes with no technical hassle. The game image is mounted read-only in a sandbox and the GPU is passed through exclusively, so an operator can share idle capacity without exposing their own machine.
Where the money actually goes
When a YOM session ends, the fee it generated is divided three ways, and the protocol does the dividing rather than a finance team. There is no middleman holding the money and nothing to reconcile by hand:
- 40% goes to the node operator who served the session
- 55% funds the YOM Foundation’s protocol treasury
- 5% is burned, permanently reducing the $YOM supply
That split is not a policy somebody applies after the fact. It lives in a dedicated, non-upgradeable payout contract, and it has been proven end to end: on the Fuji testnet a claim settled at exactly 40.00 / 55.00 / 5.00 percent, with the burn absorbing the rounding dust so the shares always sum. The audited YOM token itself is never touched, and the contract holds no tokens of its own.
Worth being precise about the timing, because it is the question operators ask most. Payouts go live shortly, and this is the shape they take. Every session credits your balance the moment it ends, keyed on the session ID so it can never be counted twice. Settlement then runs one of two ways: a monthly batch on the first of the month, where YOM pays the gas, or a self-claim from the operator app whenever you want your balance out, where you pay the gas. Both paths draw down the same on-chain counter, so a replayed claim is mathematically a no-op.
One more piece of honesty about the trust model, since this is the part worth scrutinising before you rely on it. The self-claim path uses a signed voucher from the backend, so there is a signer in the loop. What makes that acceptable is the blast radius: the treasury never hands the distributor custody of any tokens, and even a compromised signer could only ever touch the 40% operator share. The 55% still goes to the network address and the 5% still burns.
A self-regulating economy
What keeps this from being a flat, static split is the layer sitting on top of it: reputation, expressed as XP, combined with supply-and-demand pricing.
XP is a soul-bound reputation token. Operators accrue it by holding $YOM and by performing well, and HyperOrch prioritises higher-XP nodes when it places workloads. The effect is a soft lock that needs no timelock contract: to keep getting sessions, it pays to hold your rewards rather than sell them immediately. Meanwhile session pricing responds to how much demand is hitting the network relative to available capacity, so the economics stay responsive instead of fixed.
Value in YOM therefore moves through three interconnected mechanisms: a reputation system, supply-and-demand pricing, and protocol-level revenue splits.
What this looks like for operators
A YOM node operator earns roughly $58 per month from a single card, and payback on the hardware lands around six months. Those come from the company model, at 50% utilisation and $0.03 per session served, and you can check every figure on the source of truth page.
One rig can run more than one session at a time, which is where operator earnings start to scale. A licence comes with the NANO, and seven more can be added once multi-licence support ships, so a fully loaded host is eight concurrent sessions, which works out to roughly $464 per month at the current per-session average. Multi-licence is not live yet, so treat that as the shape of the ceiling rather than something you can switch on today. It is also not a hard cap: as total demand on the network grows, more sessions get routed to each capable rig, and a busy host can push toward $500 a month.
Electricity is not taken out of any of that. YOM pays the operator share gross, so what you see is what lands in your wallet, and the power bill stays on your own meter. The model puts that at 40.5 kWh a month for a node, about $5 on a blended basis, closer to $12 in Europe. As a share of what the node brings in, that is roughly 9% blended and 21% in Europe.
These are model figures, not a promise, and the spread between one session and eight is large because utilisation is the variable that moves most. What does not move is the 40% share: it is the same percentage for a first-week operator and for someone running a rack.
Who steers the treasury
The 55% routed to the treasury is not parked. It arrives as liquid capital, converted from the session fee, and it funds network operations, development, grants and liquidity. Today the YOM Foundation manages it.
Over time, direction moves to the YOM DAO, the community governance layer where members vote on protocol changes, treasury allocations and incentive parameters. Governance is a planned use of the token rather than a live one, and it will combine $YOM with the soul-bound XP so that voting weight reflects contribution and not only holdings. Proceeds from node licences also feed back into incentives that grow the network.
Why the burn matters
Every YOM session permanently destroys 5% of its own fee, which makes usage of the network directly deflationary for the $YOM supply rather than merely offsetting inflation. The burn is not a scheduled event; it is a side effect of somebody playing something.
It is worth being clear-eyed about scale. At low volumes the burn is small in absolute terms; it becomes material as sessions compound, which is exactly the point of tying it to usage instead of to a schedule. A burn driven by a calendar happens whether the network is used or not. This one only happens because somebody played something.
The full loop
Looking at the complete picture: a player creates demand, an operator’s hardware supplies the compute, a publisher provides the game, and the protocol distributes the proceeds to support the network and tighten supply. Players, operators, publishers and the DAO all read from and write to the same token economy, and the network that carries it is the same one whether the work is a game or an inference request.
That is the token cycle. An automated loop that runs every time someone plays a game.
Where every figure in this piece comes from
| figure | value | source |
|---|---|---|
| operator share | 40% | model key fee.operators, and verified against the payout contract |
| treasury share | 55% | model key fee.treasury, same verification |
| burned per session | 5% | model key fee.burn, same verification |
| one node, per month | ~$58 | model key node.avgMonthly, at 50% utilisation |
| reward per session | $0.03 | model key node.rewardPerSession |
| purchasable licences | 7 | model key node.maxPerHost, plus the one that ships with the NANO |
| payback on hardware | ~6 months | model key node.paybackMonths |
| power draw per node | 40.5 kWh/month | model key operator.electricity.monthlyKWh |
| power cost per node | ~$5 blended, ~$12 in the EU | model keys operator.electricity.monthlyCost.* |
| power as a share of revenue | 9% blended, 21% in the EU | model keys operator.electricityShareOfRevenue.* |
| eight sessions, per month | ~$464 | arithmetic, eight times the per-node average. Not a model key |
| a busy host | up to ~$500 | projection as network demand grows. Not a model key |
The split was proven end to end on the Fuji testnet: a claim settled at exactly 40.00 / 55.00 / 5.00 percent. Every model figure above is listed on source of truth. Model figures describe the model, not a guaranteed return.
