Simulation results
The agent-based model below was run against the v2.2b rules, which included the fabricated ×19.22 curve, a 2% fee the protocol does not charge, and ETH-denominated drops. All three inputs were wrong, so the absolute figures below are not estimates of anything — they are outputs of a model of a game that does not exist. They are retained for one reason: they are the evidence that the elastic gate deadlocks, which is a structural result that holds regardless of the curve. The 97% / 100% / 59% pass rates are not forecasts and must not be quoted as such.
Every v2.2b parameter was validated with an agent-based model before shipping: simulated players of distinct archetypes running 90 simulated days against the production rules as they were then written. This is how the v2.2 deadlock was caught.
| Metric | v2.2 (elastic gate) | v2.2b (shipping) |
|---|---|---|
| Core player gate pass rate | ≈0% | 97% |
| Grinder pass rate | ≈0% | 100% |
| Casual pass rate | ≈0% | 59% |
| Ticket burn rate | 0% | 72% |
| Raids cleared (90 days) | 0 | 1,180 |
| Deflation direction | structural deadlock | positive (spend 3 > output 1) |
The casual archetype at 59% reflected a design intent of "free to play, but the full economy asks for a $30 commitment". That intent survives in v3.2, but the mechanism changed: there is no longer a grind-to-gate path at all, so a "pass rate" is no longer the right metric. The replacement metric is R over time — whether net $YIELD issuance stays subordinate to fee accrual across the same archetypes.
The v3.3 model: R does not hold, and that is the headline
The replacement model has now been run: 1,000 simulated players over 90 days, against the real curve, the real 3% fee stack, and the emission ledger in §07. The question it asks is no longer "how long until a cohort clears the gate" but the one §07 identified — can fee accrual keep pace with $YIELD issuance? The honest answer is no, not at current emission.
| Post-graduation volume (per player / day) | R after 90 days | As % of the $0.01 design peg | Reserve | Share of emission absorbed by sinks |
|---|---|---|---|---|
| Dead coin (no volume) | $0.000009 | 0.09% | $4,066 | 4.5% |
| Quiet — $1 | $0.000013 | 0.13% | $5,866 | 4.5% |
| Moderate — $10 | $0.000048 | 0.48% | $22,060 | 4.5% |
| Healthy — $50 | $0.000204 | 2.04% | $94,036 | 4.5% |
Two findings matter more than the numbers themselves.
First, sinks absorb only 4.5% of emission. That figure is invariant across every scenario, because sinks scale with play while emission scales with play too — they move together. The remaining 95.5% has to be covered by trading fees, which means R is almost entirely a function of secondary-market volume and barely a function of anything we control.
Second, even the "healthy" case lands at 2% of declared face. $50 of daily volume per player is not a pessimistic assumption — for 1,000 players it is $45M of cumulative volume over the quarter. And R still settles about 50× below the declared face of a unit. This is not a crash; it is what the mechanism actually pays. No fee revenue, no share — the arithmetic is working as designed, and the design is the problem.
Solving it backwards gives the size of the gap. Holding emission constant, defending the declared face requires $500 of volume per player per day. Holding volume at the moderate $10/day assumption instead requires cutting emission to roughly 1/213 of its current rate — the cut that was shipped, and whose actual effect is described immediately below.
Cutting emission does not make anyone richer — and we shipped it anyway
Emission has been cut to roughly 1/213 of the previous rate. It is worth being precise about what that does and does not accomplish, because the intuitive reading is wrong.
The cut is implemented as a change of denomination: one $YIELD went from $0.01 of declared face to $2.13, so a kill that used to mint 3.5 units now mints 0.0164. The dollar value of the kill is unchanged at $0.035. The alternative implementation — leaving the unit alone and cutting the dollar value of each kill by 213× — is mathematically identical in outcome. Both produce the same number of units, the same float, the same R, and therefore:
relabel only real cut
units per kill 0.0164 0.0164
R per unit $6.6763 $6.6766
declared face $2.13 $0.01
redemption ratio 313% of face 66,766% of face
REAL value of a kill $0.1097087 $0.1097087 ← identical
The player's real wealth per kill is identical to seven decimal places. Cutting emission cannot create reserve that does not exist. What it changes is the honesty of the label: under the old setting a unit declared $0.01 of face while R sat at a fraction of a cent, so the denomination itself was a misstatement. After the cut, the declared face and R are the same order of magnitude.
The consequence worth stating plainly: no emission change can raise what a $YIELD holder actually receives. That number is reserve ÷ float, and the reserve is bounded by trading fees. Emission policy decides how the pie is labelled, not how big it is.
The one equation that governs all of this
Every result above collapses into a single identity. A player who earns y units on a kill receives R × y dollars, and substituting R = reserve ÷ float with a float of total kills × y cancels y entirely:
real value of one kill = R × y
= (reserve ÷ float) × y
= reserve ÷ total kills
= 1.6% × (trading volume per kill)
The emission rate appears nowhere in the result. That is the algebraic statement of the table above, and it is why the cut could not have worked in the way the phrase "cut emission" suggests.
It also converts the vague goal "we need more volume" into a number that can be argued about. A kill carries $0.035 of declared face, so backing that face requires $2.19 of trading volume per kill ($0.035 ÷ 1.6%). The simulation's healthiest scenario produces about $0.045 per kill — roughly 2% of face, which is the figure measured independently in the scenario table, and about 48× short of backing the declared number.
reserve take volume per kill needed to back face
1.6% $2.19
2.0% $1.75
3.0% $1.17
5.0% $0.70
A second inflow that does not depend on the market
The identity above rests on a premise: that volume is the only thing that funds the reserve. That premise is a design choice, and there is an alternative already flowing through the game and being thrown away.
Raid tickets are paid in $SHARD and burned 100%. Over 90 days with 1,000 players the simulation puts that flow at roughly $171,000 — about $1.90 per player per day. It is bounded by the capital players bring in, not by how actively the coin trades. If those tickets funded the fee reserve instead of being destroyed, R would end higher in every scenario, and by far the most where it matters most:
scenario R (burn) R (fund) %face burn %face fund gain
dead coin 0.001560 0.080715 0.07% 3.79% 51.7x
cold $1/day 0.002406 0.081542 0.11% 3.83% 33.9x
mild $10/day 0.009892 0.089029 0.46% 4.18% 9.0x
healthy $50/d 0.043166 0.122303 2.03% 5.74% 2.8x
Play behaviour is identical in both columns. The only difference is where the dollars go after players have already paid them. The gain is largest precisely in the low-volume scenarios, which is the point: this lever is driven by play, not by speculation.
The cost is real and we are not hiding it. Burning $SHARD is deflationary and supports its price; selling it to fund the reserve replaces that with permanent sell pressure. This is a transfer from $SHARD holders to $YIELD holders, not the creation of value. It is also still exposed to the coin's price even though it is decoupled from its volume — a $SHARD collapse shrinks the dollar value of every ticket collected. The "dead coin" row above is therefore the least trustworthy figure on the page: the model tracks holdings in dollars and does not simulate the price collapse that would accompany that scenario.
Three things are unresolved, and the third is more fundamental than the first two:
- Should $YIELD carry a declared face at all? Given that R floats with volume, any fixed face is a promise that will be wrong in one direction or the other. The share framing ("a percentage of the reserve, whatever that reserve is") is the only description that cannot become false.
- Should raid tickets fund the reserve instead of being burned? It is the largest identified lever in the model — up to 51.7× on R — and the only one driven by play rather than by trading. It is also a direct transfer of value away from $SHARD holders.
- The reserve currently has no outflow. This is the one that makes the first two partly academic. In the shipped build,
feeReserveUsdhas exactly one write — fee revenue arriving — and zero reads that ever spend it. There is no redemption function; $YIELD cannot be converted into ETH, into $SHARD, or into anything outside the game. A holder's only route to value is spending it on territory upkeep, upgrades and materials.
That third point needs to be read carefully, because it cuts both ways. A reserve that can never be drawn down is solvent by construction — float × R = reserve holds by definition and $YIELD cannot fail. But it also means R is a shadow price, not a claim: the number a unit would be worth if a redemption path existed, published as though one did. The honest descriptions are therefore two, and one has to be chosen:
- $YIELD as an in-game consumable. Drop the face value and the backing language entirely. Value is whatever the territory and crafting utility is worth to the player — the way gold in a subscription MMO has no redemption price. Nothing published can become false. The reserve remains, but is described as funding operations, leaderboards and reward pools rather than as backing a float.
- $YIELD as a claim. Build the redemption path: $YIELD → $SHARD bought from the market using the reserve, or → ETH pro-rata. This makes R real and makes every number in this section load-bearing. It also makes $YIELD a financial instrument, and at 2–6% of face the first redemption wave would drain the reserve immediately.
None of the three is presented as settled. The simulation is published so the numbers behind them are public either way. The current build behaves as the first option while being documented in places as though it were the second — a gap that should be closed before launch, in whichever direction it closes.
The live playtest feeds the same model back. When real play disagrees with a simulation, the simulation loses.