Simulator

Watch the engine run

The rules from the previous page, set in motion. Move the settings and watch what the system allows itself to create, what it funds with GEM already in circulation, and what it does not create at all.

Pick a situation

Each one sets everything at once. The sliders stay below if you then want to try your own values.

The example published on the tokenomics page. Power would allow 12,000,000 GEM, adoption only 7,000,000, and that lower figure is the one kept. One very large account does not make a community.

What the distributed amount is made of

  • Newly created GEM 4,550,000
  • GEM already in circulation 2,450,000
  • Not created 0

The bar represents the retained cap. The larger the violet share, the less the game depends on creation. The dark share is what could not be funded, and is therefore not created.

Creation tightens as the game grows

Read the curve like this: pick a number of players along the bottom, go up to the curve, and read on the left what share of the distribution can come from newly created GEM.

25 %50 %75 %100 %1,00010,00050,000200,000Your situation : 65 % Share that can come from new GEMNumber of active players

The pink dot is the situation picked above. The dotted lines give you its two values: the number of players along the bottom, the share fundable by creation on the left.

This is the curve that carries the whole argument: as adoption rises, the share of the distribution that can come from newly created GEM falls. The rest must come from GEM already spent by players.

What player spending replaces

Same reading: pick along the bottom what players respend for every 100 GEM distributed, go up to the curve, and read on the left the share of the distribution that comes from GEM already in circulation rather than from creation.

25 %50 %75 %100 %050100150Your situation : 35 % Share coming from GEM already in circulationGEM respent per 100 distributed

The curve climbs straight, then stops flat. That plateau is the point where spending covers everything creation does not fund: beyond it, spending more replaces nothing, since creation is already at the minimum the cap allows. The plateau moves right as the game grows and as halvings land, and that is exactly why the game has to keep opening more uses.

The settings

Four things decide what happens during a cycle. The starting values are those of the published example on the tokenomics page.

The total power of every creature placed in Mines that actually run. This is what sets the first cap.

Real adoption, measured in a way that reduces the weight of very large accounts. This sets the second cap, and it is what validates halvings.

This decides whether a halving threshold is reached. Three are planned, at a quarter, a half and three quarters of the 21 billion cap.

What players put back into the game: expanding the Mine, unlocking slots, forging, equipping, entering a mode. That GEM joins the Reward Vault and replaces creation in the next cycle. The slider goes past 100 because the game always opens more uses than a player earns GEM.

What the cycle produces

The two caps

Cap from power
12,000,000 GEM
Cap from adoption
7,000,000 GEM
Retained cap The system always keeps the lower of the two.
7,000,000 GEM

What can be created

Share fundable by newly created GEM It falls as adoption grows. This is elasticity.
65 %
Effect of halvings
no threshold reached
Maximum creation of new GEM
4,550,000 GEM

What is actually distributed

Recycled GEM needed to distribute the whole cap
2,450,000 GEM
Spending needed to distribute the whole cap Above this level, nothing is missing.
35 GEM reached
What the Reward Vault covers
2,450,000 GEM
Amount actually distributed
7,000,000 GEM
What is not fundable, and is therefore not created
0 GEM

What it changes for GEM

New GEM actually created this cycle
4,550,000 GEM
Share coming from GEM already in circulation
35 %
What this spending puts back into the Reward Vault Available for the next cycle.
2,800,000 GEM
Left to create before the 21 billion cap
21 billion

Reminder: these amounts come from simplified coefficients, not from the live engine. They show how the system reacts, they do not foreshadow any cycle.

Where the halvings stand

A halving does not land on a date. It needs two conditions at once: an amount of GEM already created, and a level of adoption. Move both sliders to watch the states change.

  1. First halving

    5.25 billion GEM created

    20,000 active players figure invented for the demonstration

    creation divided by two

    Not reached yet

    5,250,000,000 GEM left to create before this threshold.

  2. Second halving

    10.5 billion GEM created

    60,000 active players figure invented for the demonstration

    creation divided by four

    Not reached yet

    10,500,000,000 GEM left to create before this threshold.

  3. Third halving

    15.75 billion GEM created

    150,000 active players figure invented for the demonstration

    creation divided by eight

    Not reached yet

    15,750,000,000 GEM left to create before this threshold.

This brake exists for a simple reason: if creation runs ahead of the game, it is better to slow it down straight away than to notice the problem afterwards. It only acts on what is left to create, it never removes GEM already produced.

In every case, a halving only touches creation. It never reduces the ability of the Reward Vault to redistribute GEM that already exist.

Do not confuse the two columns. The GEM thresholds are real and published: 5.25, 10.5 and 15.75 billion. The adoption levels are invented to make the demonstration work. The real ones are not published, for the same reason as the rest of the coefficients.

What the sliders show

Raise power without touching active players: the first cap climbs, but the retained cap does not move. A few very powerful accounts are not enough to make the system create more. That is what the second cap is for.

Raise active players: the cap goes up, but the share fundable by newly created GEM goes down. The game can distribute more while creating proportionally less. This is the single most important point of the whole economy.

Lower the Reward Vault: the distributed amount falls with it. What cannot be funded is not created to fill the gap. No rule in the system allows creating GEM to keep a promise.

Push GEM already created past the first threshold while leaving adoption low: the pre-halving brake appears. Creation is already divided, yet the halving is not validated. Raise active players afterwards and it switches to validated.

Five cycles, written out

The same calculations, laid flat. These are exactly the results the sliders give with these settings. Watch one thing in particular from one cycle to the next: the level of spending needed to distribute everything rises at every step.

At launch

  • Combined power: 30,000 points. Active players: 1,500. Players respend 25 GEM for every 100 distributed.
  • Cap from power: 3,000,000. Cap from adoption: 1,500,000.
  • Retained cap: 1,500,000, the lower of the two.
  • Share fundable by newly created GEM: 80%, the maximum. That is expected: almost nothing has been spent yet, so there is almost nothing to recycle.
  • Maximum creation: 1,200,000 new GEM.
  • Covering the rest would need 20 GEM respent for every 100 distributed. Players respend 25, so the whole cap is distributed.
  • Amount distributed: 1,500,000, of which 20% came from GEM already in circulation.

Cruising speed, before any halving

  • Combined power: 120,000 points. Active players: 7,000. Players respend 40 GEM for every 100 distributed.
  • Cap from power: 12,000,000 GEM.
  • Cap from adoption: 7,000,000 GEM.
  • Retained cap: 7,000,000, the lower of the two.
  • Share fundable by newly created GEM: 65%. Maximum creation: 4,550,000.
  • Covering the rest would need 35 GEM respent for every 100 distributed. Players respend 40, so the whole cap is distributed.
  • Amount distributed: 7,000,000, of which 35% came from GEM already in circulation.

The same game, four times more players

  • Combined power: 500,000 points. Active players: 28,000. Players respend 45 GEM for every 100 distributed.
  • Cap from power: 50,000,000. Cap from adoption: 28,000,000.
  • Retained cap: 28,000,000.
  • Share fundable by newly created GEM: 41%, against 65% in the previous cycle. Adoption grew, creation tightened.
  • Maximum creation: 11,480,000 new GEM.
  • It would now take 59 GEM respent for every 100 distributed. Players only respend 45: the sums no longer add up.
  • Amount distributed: 20,872,727. The missing 7,127,273 are not created to fill the gap.
  • Share coming from GEM already in circulation: 45%, exactly the level of spending. Below the threshold, that is always the case.

The same game, once the first halving is validated

  • Same settings as the previous cycle, with 6 billion GEM already created.
  • Both conditions are met: the 5.25 billion threshold is passed and adoption keeps up. The first halving is validated.
  • Retained cap: still 28,000,000, the caps themselves do not change.
  • Maximum creation: 5,740,000 new GEM instead of 11,480,000. Creation is divided by two.
  • It would now take 80 GEM respent for every 100 distributed. This is where the whole logic of the model shows: the less the game creates, the more it has to circulate.
  • Amount distributed: 10,436,363. The missing 17,563,637 are not created.
  • Share coming from GEM already in circulation: 45%. The halving did not touch recycling, only creation.

The pre-halving brake

  • Combined power: 120,000 points. Active players: 7,000. Spending: 40 GEM for every 100 distributed. And 6 billion GEM already created.
  • The 5.25 billion threshold is passed, but the adoption expected to validate the first halving is not there. The halving does not switch to validated.
  • The reduction is applied in advance all the same: creation is divided by two.
  • Retained cap: 7,000,000. Maximum creation: 2,275,000 new GEM instead of 4,550,000.
  • It would take 68 GEM respent for every 100 distributed. Players respend 40.
  • Amount distributed: 3,791,666. The missing 3,208,334 are not created.
  • The system therefore slows creation without waiting for the game to catch up, and without ever removing a single GEM already produced. As soon as adoption reaches the expected level, the halving switches to validated and the brake disappears.

How these figures are obtained

The order is the published one. Two caps are computed separately, one from power and one from adoption. The system keeps the lower. It then applies the share fundable by newly created GEM, followed by the division from halvings reached. The rest of the cap must come from the Reward Vault. What is neither owed nor fundable is not created.

What is simplified here are the coefficients: those that turn power into a cap, adoption into a cap, adoption into a fundable share, and the adoption level expected to validate each halving. The real ones account for a great deal more, and they stay internal.

In short: the orders of magnitude and the direction of every variation are correct, the exact values of a real cycle would not be. The point is to understand the engine, not to predict its output.

This simulator computes nothing for any individual player, and it never will. GEM is a game resource.

Back to the tokenomics