A Monte Carlo simulation runs a token model thousands of times, redrawing the uncertain inputs on every run, and returns a distribution of outcomes instead of one number. In a token model the uncertain inputs are the ones nobody can know in advance: demand growth, staking participation, how much of an unlock actually gets sold, and the price path itself. What it tells you is how often the treasury runs dry and in which month the design is thinnest. What it does not tell you is what the token will be worth.
A Monte Carlo run cannot be more honest than the input ranges you gave it. Every percentile it prints is a restatement of your own assumptions at higher resolution, so the defensible output is the shape and the timing of the failure region, never a price.
Scroll to see the full diagram
What gets randomised in a token model
Start from a deterministic base case: a revenue model with every fee stream written out, an emission schedule, an unlock calendar, an operating cost line. That model produces one answer. Monte Carlo replaces the inputs you had to guess with ranges and runs the whole thing again and again.
In practice the guessed inputs are a short list. Demand growth, and how fast it compounds. The share of circulating supply that stakes rather than sells. The proportion of each unlock that reaches the market inside a month. Fee capture per unit of activity. And the price path, usually drawn from a lognormal process. Everything else in the model is arithmetic downstream of those.
You read the bad tail, not the average
The output is a sorted distribution, and the median is the least useful part of it. What a founder needs is the fifth or tenth percentile: in the worst tenth of simulated worlds, did the treasury still cover its obligations, and in which month did it stop. That is a coverage question and a runway question, and both have design answers.
A published example of the format is worth looking at for shape rather than content. One 2025 modelling paper on Bitcoin supply, demand and price dynamics pairs a deterministic baseline with a Monte Carlo layer that varies uncertain parameters and reports probabilistic rather than point outputs.1 The method is the transferable part. Its headline numbers belong to its own parameter choices, and we neither reproduce nor endorse them.
Scenario modelling is not forecasting
Because the output is a probability distribution over prices, it invites exactly the misreading it should prevent. A percentile is not a probability that the world will do something. It is a probability inside a model whose assumptions you wrote, and the assumption sheet is doing the forecasting, not the simulation.
So the honest use is comparative and internal. Does design A run out of money in fewer paths than design B. Does moving the cliff by six months narrow the failure region. Does the buyback still fund itself when fee revenue lands at the low end of the range. Those are answerable. What a token will trade at is not, and we do not model it or publish it.
Where it misleads
Four ways, all common. Independent draws: if the simulation samples weak demand, a heavy unlock and thin liquidity separately, it will rarely produce the case where all three arrive together, which is the case that kills projects. Distribution choice: a lognormal price process cannot generate the gap events that token markets actually deliver, so the tail comes out too thin.2
Then false precision, because ten thousand runs of a guess is still a guess with more decimal places. And frozen behaviour, because a Monte Carlo model usually assumes participants keep behaving as specified even in the paths where the economy is falling apart. Where reflexive behaviour is the thing you are testing, an agent-based model is the better instrument.
What we actually run it on
The simulation earns its cost when it is pointed at obligations rather than upside. Emissions against sinks. Treasury runway against operating cost when the treasury is denominated in the volatile thing. Coverage of redemption or reward promises across percentiles. Unlock timing against modelled liquidity depth, which is where a schedule that looks fine on a calendar turns out to be scheduled into a market that cannot absorb it.
The output that changes a decision is usually a single sentence: this design fails in a defined share of paths, always for the same reason, in roughly the same month. That sentence is a specification for a mechanism fix, and it is worth more than the whole distribution it came from.
Common questions
What is Monte Carlo simulation used for in tokenomics?
It stress-tests a token model by rerunning it thousands of times with the uncertain inputs redrawn each run, then reads the distribution of outcomes. In practice that means testing whether emissions, unlock timing, treasury runway and reward promises survive a wide range of demand and price conditions. The useful answer is how often a design fails and in which month, not what the token is worth.
How many simulation runs are enough?
Enough that the percentile you care about stops moving when you add more runs. That is a stability check you can perform directly: run the model, run it again with more paths, and compare the fifth percentile. Adding runs sharpens the estimate of your own assumptions and does nothing about whether those assumptions were right, so run count is the cheapest part of the exercise to get comfortable with.
What is the difference between Monte Carlo simulation and sensitivity analysis?
Monte Carlo varies every uncertain input at once and reports the distribution of outcomes. Sensitivity analysis varies one input at a time across a range and reports how far the outcome moves, which ranks the assumptions by how much they matter. They answer different questions and most token models need both: the sweep tells you which parameter to worry about, the simulation tells you how often the design breaks.
See Tokenomics Data Room for how this applies in practice.
Sources
- Bitcoin Supply, Demand, and Price Dynamics
Journal of Risk and Financial Management, via IDEAS/RePEc, 2025
Pairs a deterministic baseline supply and demand model with a Monte Carlo layer over uncertain parameters, reporting probabilistic rather than point outputs. Cited here for method structure only. - Prediction of Cryptocurrency Prices Through a Path Dependent Monte Carlo Simulation
Ayush Singh, Anshu K. Jha and Amit N. Kumar, arXiv:2405.12988, 2024
Uses Merton jump diffusion with a compound Poisson jump process, on the basis that a plain continuous lognormal specification does not fit crypto price behaviour.
Last reviewed 2026-08
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
100+ projects advised. Complete tokenomics in 4 to 6 weeks.