the token cycle: how value moves through YOM

Every time someone hits “Play” on a service running on 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 service like Walter, and HyperOrch, YOM’s edge orchestrator, picks the node that will serve it. HyperOrch sends each session to the nearest node with the GPU capability and free capacity it needs.

Nearest matters because distance is latency. Capability matters because each game title needs a certain class of GPU. Free capacity matters because a node already at its limit cannot take one more session without hurting the ones it is serving.

The chosen node boots the game and streams it back to the player over WebRTC. For players within 50 km of a node the measured median one-way latency is about 15 ms, against a sub-10 ms target (live on yom.net/source-of-truth), 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 qualifying gaming PC. When they are not playing, the PC boots a read-only system from the NANO’s own encrypted drive, which unlocks only through YOM’s key service, so the operator’s own Windows install is never touched. Each session runs in its own clean container that is discarded when the session closes, 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 four 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:

• 60% goes to the node operator who served the session
• 30% funds network development: operations, development, grants and liquidity
• 5% is shared with everyone who holds on to their payout
• 5% is retired, permanently reducing the $YOM supply

The per-session fee itself runs on a ladder from $0.04 (Light) to $0.24 (Ultra), set by the compute the game needs. The split is not a policy somebody applies after the fact. It lives in a dedicated, non-upgradeable payout contract, proven end to end on the Fuji testnet, where a claim settles at exactly the published shares, 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 how payouts work, because it is the question operators ask most. 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 60% operator share. The network-development share still goes to the network address, the community share still goes to everyone who holds on to their payout, and the 5% is still retired.

a self-regulating economy

What keeps the split predictable is that its inputs are fixed. Session prices are set per tier, from $0.04 for Light to $0.24 for Ultra, so an operator knows what a session pays before it starts. Supply grows the same way: when demand in a city grows, the network opens more node licences there.

XP sits next to this, not inside it. XP is a non-transferable contribution score that will weight token-holder votes. It does not change which node gets a session or what a session pays.

Value in YOM therefore moves through three connected mechanisms: fixed per-tier pricing, demand-gated supply, and protocol-level revenue splits.

what this looks like for operators

At the network’s 50% utilization target, a NANO (which carries 2 licences) earns about ~$53 per month, about ~$26 per licence, and pays back in about ~7 months. Those figures come from the company model at $0.048 to the operator per Standard session served, and you can check every one on the source of truth page.

One rig can run more than one session at a time, admitted only when it has the capacity, which is where operator earnings start to scale. The backend estimator calculates the supported count from each host’s measured resources. Run the free PC check for a current result. The NVIDIA encoder policy has a hard upper bound, but it is not a promise that every host can run that many sessions.

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. At the 50% utilization target, that is roughly 7% of what the node brings in blended and 17% in Europe; at lower utilization, idle power weighs more.

These are model figures, not a promise. Host earnings depend on supported capacity, session demand and utilisation. The operator share is the same percentage for a first-week operator and for someone running a rack.

where the rest of the fee goes

The 30% routed to network development is not parked. It arrives as liquid capital, converted from the session fee, and it funds network operations, development, grants and liquidity.

The 5% community share is distributed to everyone who holds on to their payout. The YOM Foundation takes its share on the same terms as every other holder, which is how the protocol’s steward is funded by usage rather than by a fixed cut.

Over time, direction of the protocol 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 non-transferable XP score 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	60%	model key fee.operators, and verified against the payout contract
network development	30%	model key fee.group, same verification
shared with holders	5%	model key fee.staking, same verification
retired per session	5%	model key fee.burn, same verification
session fee, Light to Ultra	$0.04 to $0.24	model keys compute.light to compute.ultra
one NANO (2 licences), per month	~$53	model key node.avgMonthly, at the 50% utilization target
one licence, per month	~$26	model key operator.licenseYieldMonthly, at the 50% utilization target
reward per Standard session	$0.048	model key node.rewardPerSession
payback on hardware	~7 months	model key node.paybackMonths, at the 50% utilization target
power draw per node	40.5 kWh per 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	7% blended, 17% in the EU	model keys operator.electricityShareOfRevenue.*, at the 50% utilization target
Host capacity	Backend estimator result	calculated from measured host resources

The split is enforced by the payout contract, proven end to end on the Fuji testnet, where a claim settles at exactly the published shares. Every model figure above is listed on source of truth. Model figures describe the model, not a guaranteed return.