Cost-based Model

Next to benchmarking the performance of games, YOM benchmarks the power usage of its machines and infers the consumption of individual connections as mWh (meta Watt hour). We then use the global average costs of electricity to calculate the electricity costs required to host a single average benchmarked game.

Finally we add in a variable profit margin multiplier which is automatically scaled dependent on the supply/demand for machines in a particular region (-> <15ms ping, 30+ fps @ 1080p). We created the following table that demonstrates some example reward schemes:

mWh	Multiplier (demand)	Rewards
€ 0.01	high demand, low supply -> 10	€ 0.10/u/hr
€ 0.02	high demand, high supply -> 5	€ 0.16/u/hr
€ 0.03	low demand, high supply -> 2	€ 0.06/u/hr

Market-based approach

In order to sustain artificial price movements due to token hoarding and release, we need to determine a threshold percentage of tokens to be used in YOM's circulating streaming economy that forms a sustainable base of value onto which a price point for $YOM can be anchored.

We take a range of at least 0.1% of the total circulating supply which may grow towards ~ 5% of the total circulating supply in correspondence with increased demand for streaming minutes. The higher the percentage, the better $YOM represents the underlying value of cloud gaming.

In order to peg the price of $YOM to the demand for cloud gaming, we need to build a function that initially optimizes for streaming (product usage) as percentage (t) of the total circulating supply (s) and then increases the price of $YOM in correspondence with the demand for cloud gaming. For this reason, we created a power function:

$$\frac{t\left(0.000001s^{\frac{1}{2}}+0.0006\right)}{s}$$

The output of this power function determines the $YOM hourly rewards. The maximum rewards a nodes can get from this approach is set at a maximum of 2 $YOM per hour and cannot exceed the USDC rewards ceiling (see diagram). We set this reward to protect the ecosystem from allocating extremely high rewards (preventing outage or other scenarios that could lead to near-zero streaming minutes). As an example we get:

Required circulation level	Rewards
Up to .09% of total circulating supply is used for streaming.	2 $YOM/u/hr
~ .12% of total circulating supply is used for streaming.	1 $YOM/u/hr
~ .8% of total circulating supply is used for streaming.	1/24 $YOM/u/hr
~ 5.0% of total circulating supply is used for streaming.	1/168 $YOM/u/hr

Reward distribution

To determine the final streaming rewards, we need the following input:

1. Base rewards -> x$YOM/u/hr:

• The total circulating supply

• The number of tokens circulating for streaming purposes

• The price of $YOM (-> expressed in USDC)

• The power usage of an avg. game (-> expressed in mWh)

• A demand multiplier (-> 45+ fps @ 1080p, <15ms ping)

2. Node performance -> multiplier: 1-12

• The amount of connected users (-> 45+ fps @ 1080p, <15ms ping)

3. Rendering difficulty -> multiplier: x%offset

• Performance benchmark

After applying the distribution algorithm, the output returns x$YOM/u/hr, which is multiplied by the rendering difficulty and amount of connected users then distributed among all streaming stakeholders.

Example case

As an example we assume that .8% tokens are circulating for the purposes of streaming, we assume the power consumption of an average project in a particular region is €0.02, we estimate a relative high demand in a region where the node is streaming so we set the demand multiplier at 8, and the amount of connections this particular beacon can stream we set as 2, the graphical requirements are slightly more demanding than average (+10%). We also take into consideration a future scenario where streaming minutes have pushed the $YOM price to $2.8.

Margin-based rewards: $ 0.02 * 8 = $ 0.16 -> 0.06 $YOM /u/hr

Market-based rewards: 0.12 $YOM /u/hr

Normalized rewards : (0.1 * 0.06 + 0.8 * 0.11) / 0.9 = 0.11 $YOM /u/hr

Total rewards (2 users at + 10% difficulty): 0.11 * 2 * 1.1 = 0.24 $YOM/hr:

Stakeholder	$YOM rewards	Fiat
Studio/ Agency	0.24 * 5% = ~ 0.01 $YOM	€ 0.03
YOM	0.24 * 30% = ~ 0.07 $YOM	€ 0.20
YOM DAO	0.24 * 5% = ~ 0.01 $YOM	€ 0.03
Node	0.24 * 60% = 0.15 $YOM	€ 0.40

Market efficiency

As you may have noticed, there is a gap between the margin-based and the circulation based approach. This situation may represent an inefficient market where speculative forces outperform the actual value of the demand (which in this example could have been roughly $1.37 instead of $2,80). To create market efficiency, we can close the gap via liquidity providers.

For this reason, YOM will create incentives (liquidity pools) to attract additional liquidity to reinforce the demand/supply of project streaming and reward traders and investors to create market efficiency. The result is a price that converges to a stable state of growth that represents the market for the ecosystem.

The liquidity pool allows users to collect rewards on their own terms based on the amount liquidity they provide to the market. Simply put, the more liquidity you provide to enable market efficiency, the more rewards you will receive (difference between speculative and actual/real value). It is up to the community to invent better mechanisms than the margin-based approach, as is proposed in this article.