# In-Game Reward Pool Simulations

In order to test to pool algorithm, we have run simulations of several scenarios.

In the first simulation we simulate what happens in a simple and deterministic launch of the game with no randomness to show how the pools behave and what the block revenues are of the players that we want to obtain for the first 180 days of operation of the game as new players come to the game and level up.

In the second simulation we add a lot more noise and randomness to test the robustness of the algorithm and show how it would perform in a real situation over a longer time.

### Simulation 1 : Launch and leveling up

In this first simulation we consider 10 groups of players for every 10 levels brackets from 0 to 100. We assume that the player population is stable at 100'000 daily active users.

All players start at level 0. We assume that at each level the monthly churn rate varies linearly with the level from 70% at level 0-10 to 10% at level 90-100. This rate is divided by $30 \cdot 24$ to obtain an hourly rate for the simulation. Similarly, the monthly rate of leveling up varies linearly from 2 per month at level 0-10 to 0 at level 90-100 as there is no level above that. The simulation was run with a time step of 1 hour.

The players in each level groups over time are as follow:

As we can see the proportion of high level players increase over time:

The actual evolution of players throughout the game could differ but by modifying the experience needed per level and the difficulty of some enemies we can adapt the game to obtain such behavior.

There are 10 pools of revenue corresponding to each level group. In reality there would be many more smaller pools and some overlap in the levels of players but the overall evolution should be the same. The size of the pools vary from 500K blocks for the lowest level pool to 2.5M to the highest level. The base revenue for the highest level pools is 5 times larger than for the lowest level pool.

We assume also that everyday 10% of the total circulating supply of blocks earned in game go back to the main pool as they are being spent in the game. The overall revenue pool is therefore very stable over time:

If we consider different rates at which the circulating supply earned in the game returns to the pool over a longer period of time (1000 days), we can see that with any rate over 1% an equilibrium is reached quickly. Even in the worst case scenario where none of the blocks are spent, which is very unlikely as it would mean that no block is spent in the game, the amount of blocks in the pool is still 36% of its initial amount. Note that the circulating supply it considers is only the one coming from the game, the blocks earned through staking and the seed round will come in addition to those and will increase the size of the pool as they are spent in the game.

As there are no players at the high level pools at first, their content will grow rapidly. Once a significant amount of players reach a high enough level to finish harder quests and kill higher level enemies, the corresponding pool will progressively go down in size:

As the rewards from a pool grow with its size, the daily amount a player can earn will be much higher for high level pools than for lower level ones. This is especially the case early on as no one has reached a high enough level and the pool just accumulates blocks. The daily revenue per player at each level range would be:

The first few players who reach the highest level on day 45 will have a massive revenue as they are the only ones who can earn from the highest level pool. They make a daily revenue of over 250 MBLK per day at that point. Once more players catch up that daily revenue will go down progressively. The rush to reach the highest level will incentivize players to use their blocks to buy high level weapons and armor which creates a healthy buying pressure for the blocks and NFTs.

Once a significant portion of the players reach the maximum level, we will add more quests that require not only the maximum level but also great equipment and skills to complete. Later on we will add new levels periodically, increasing the maximum level each time, to create a new rush to the top. With each expansion, the progression for lower levels will be faster so that the progression is not too slow for new players.

### Simulation 2: Large random changes

In this second simulation, we test the algorithm under more random circumstances to make sure it is robust even with high fluctuations in the player-base.

It was run for a duration of 1’000 days with a time step of one hour. We used 7 pools with base sizes of either 100'000 or 300'000 MBLK.

To simulate the user gains in the game we assume they would follow random walks between 0 and twice the size of the respective pool multiplied by a common factor for all the pools between 0.3 and 1.7 which also follows a random walk to simulate the general population of the game. These distributions are arbitrary but yield a wide range of behaviors across simulations which is useful to test the robustness of the system.

We assume that between 0 and 0.18% (following a random walk) of the total magical blocks earned within the game return to the pool every day. It comes from minting and other in-game expenses. We expect the actual amount returning to the pool to be greater than that as some of the MBLK earned for staking will be spent in the game. The total amount of blocks in the main pool will be:

A typical base daily player revenue over time for one of the pools would be:

We assume important fluctuations so that our design is robust to changes in the user base or in the players’ behavior.

The actual revenue the player gain will depend on the content of that specific pool, which is the following:

The revenue factor is proportional to the amount in the pool:

This means that earnings decrease when a lot of players are completing a quest or killing the same enemy, conversely they increase when little revenue is earned from the pool.

The resulting daily earnings revenue from this pool over time is as follows:

Even though there are large changes, over time the pool will move back towards an equilibrium.

On the scale of all the active pools, the amount in each pool over time is as follows:

We can see that when a pool is at a low level it replenishes relatively quickly. The overall player base affects the level in all the pools at the same time causing overall changes in the revenue. That effect can be beneficial to the game as the MBLK revenue per player grows when there are less players which can attract more players. At the same time, revenue per player in high level quests that less players are completing will also be significantly higher.

While the total amount in all of the game pools varies widely over time, the actual total daily revenue in blocks earned by players stays stable:

Simulations have been also performed by adding a periodical factor to simulate the daily and weekly seasonality of the player base but these short term fluctuations had no significant effect on the simulations so we omit them on the displayed graphs to keep it readable.

This algorithm ensures long term stability of the revenue gained in a pool and that if the revenue from a pool becomes extremely high suddenly due to a balancing issue or bug exploit only the revenue from that pool would be affected and the rest of the game economy would survive.

It also makes farming of a single enemy unsustainable for the players as the revenue over time from that enemy would quickly go down if every player targets it.

Last updated