Tokenomics Modeling: Three Approaches and When to Use Each
Tokenomics modeling covers three approaches: cadCAD simulation, Monte Carlo analysis, and agent-based modeling. Here is how each works and which one your project needs.
Tokenomics modeling is the process of simulating a token economy before launch to test how supply, demand, and incentive mechanics interact under different conditions. The three primary approaches are cadCAD simulation, Monte Carlo analysis, and agent-based modeling. Each one answers a different class of design question, and choosing the wrong approach is as costly as skipping modeling entirely.
Most token models ship without ever being stress-tested. A whitepaper describes intended behavior. A model tests whether the mechanics actually produce that behavior when real money and real actors are in the system. The difference between those two things is the difference between a design that holds up and one that fails in front of the community six months after launch. Token mechanism failures are business failures. The revenue model, the community, and the protocol's ability to attract institutional capital all depend on the token design holding up under real conditions.
#What Tokenomics Modeling Is (and Why a Whitepaper Is Not a Model)
A whitepaper can be internally consistent and still fail. The mechanics look sound on paper. The allocation table adds up. The vesting schedule runs 48 months. And then the system behaves in ways no one planned for because the whitepaper described what each component was supposed to do, not how all the components would interact under real conditions.
Tokenomics modeling: the use of computational simulation to test how a token economy's supply, demand, and incentive mechanics interact under defined conditions before launch.
That distinction matters in practice. A whitepaper does not tell you what happens when a large unlock event hits the market the same week protocol revenue drops. A model does. A whitepaper does not tell you whether your staking reward APY stays attractive as total staked supply grows. A model does. A whitepaper does not tell you at what treasury burn rate the protocol becomes insolvent. A model does.
The other key distinction is against spreadsheets. A spreadsheet produces one deterministic path: given these inputs, here is the output. Modeling, in any of its three forms, produces a distribution of outcomes under varying assumptions. That distribution is where the design insight lives.
We've found that the projects most surprised by post-launch mechanism failures are the ones that never asked "what does this look like under a stress scenario?" before launch. A thorough tokenomics audit can surface structural weaknesses, but modeling is what tells you how badly those weaknesses play out under pressure.
#Approach 1: cadCAD Simulation
cadCAD is an open-source Python framework for simulating complex adaptive systems. It models a token economy as a set of state variables (circulating supply, treasury balance, staked supply, protocol revenue) and a set of update rules that govern how those variables change at each time step. The simulation runs forward, typically 12 to 48 months, and produces a trajectory for each state variable. The framework is maintained as a community open-source project on GitHub, with documentation and example models published by the original development team.
The key insight behind cadCAD is that it models the system, not a single scenario. A spreadsheet models one path. cadCAD runs the same model across a matrix of assumptions (low growth, mid growth, high growth; high token price, mid price, low price) and shows how the design behaves across that range. When cadCAD incorporates Monte Carlo parameter sampling (which it commonly does), a single run becomes thousands of trajectories and the output becomes a distribution rather than a line.
cadCAD is the right tool when the token model has feedback loops. Feedback loops are the defining characteristic. If staking behavior feeds back into circulating supply, and circulating supply feeds back into price signals, and price signals feed back into staking behavior, that is a feedback loop. A spreadsheet cannot model it because the output of one time step is the input to the next. cadCAD was built for exactly this pattern.
When we use cadCAD in practice, the trigger is almost always one of four design questions. Many of them connect back to the token velocity problem. When tokens move too quickly through the economy, no incentive structure survives the resulting sell pressure.
Unlock cliff sizing. How much sell pressure will a cliff event generate, and can the liquidity depth at that moment absorb it?
Staking APY sustainability. Does the staking reward rate stay attractive as more supply locks in, or does it collapse under its own success?
Treasury runway. At defined spend rates and protocol revenue projections, at what point does the treasury run out? What assumptions flip the outcome from "solvent" to "depleted"?
DePIN node operator incentive decay. As network coverage grows and reward emissions decrease, does the incentive for node operators to stay in the network hold?
One framing the guardrails require: cadCAD simulates mechanism behavior under stated assumptions. It does not predict token price. The model shows "under assumption set X, circulating supply follows this trajectory." What that trajectory does to price in the open market depends on liquidity depth, market conditions, and participant behavior that no model can fully capture. The frame is always "the design holds under these assumptions." Not "the price will do this."
#Approach 2: Monte Carlo Simulation
Monte Carlo simulation is a technique, not a framework. Where cadCAD is a system for building a full state machine, Monte Carlo is a method for stress-testing any model's sensitivity to uncertainty in its input assumptions.
The core idea: instead of running the model with a single set of inputs, Monte Carlo samples each input parameter from a probability distribution thousands of times and runs the model once per sample. The method predates crypto by decades; the original Metropolis and Ulam paper on the Monte Carlo method (1949) is still the cleanest statement of why random sampling beats single-point estimation when the system is too complex to solve analytically. The output is a distribution of outcomes: treasury runway in the 5th, 50th, and 95th percentile; sell pressure at unlock if the token price at that date is 0.5x, 1x, or 2x the raise price; protocol revenue sensitivity to user growth rate.
Monte Carlo and cadCAD are often used together. cadCAD provides the state machine; Monte Carlo provides the parameter sweep that turns a single-scenario run into a probabilistic distribution. But Monte Carlo can also run on simpler financial models (a treasury projection spreadsheet with stochastic inputs, for example) without the full cadCAD machinery. This makes it faster to apply in situations where the design question is narrow and the feedback loops are limited.
Monte Carlo is the right technique when the primary question is about the distribution of outcomes under uncertainty, not about modeling the interaction of feedback loops. If the founder needs to know "what is the plausible range of treasury runway given uncertainty in token price and user growth?" that is a Monte Carlo question. If the founder needs to know "how do staking incentives interact with circulating supply over 36 months?" that is a cadCAD question (often with Monte Carlo on top).
The firm uses Monte Carlo regularly for pre-TGE financial modeling for investor decks, treasury runway sensitivity analysis, and unlock cliff timing scenarios. Sell-pressure scenarios depend directly on how supply is allocated across rounds, so the allocation design feeds straight into the model. Token allocation best practices cover the distribution decisions that shape those unlock scenarios. Input parameters for price and volume distributions are typically calibrated against comparable token launches. CryptoRank token market data provides the historical benchmark set for this calibration. If you are earlier in the process and working through overall TGE strategy, modeling is most valuable when the token generation event structure is still flexible enough to change. Across 80+ projects, this is the most commonly requested analysis in the two months before a token generation event.
Brand note: the canonical term is "Monte Carlo simulation" or "Monte Carlo stress testing," not "stochastic modeling" or "scenario simulation."
#Approach 3: Agent-Based Modeling
Agent-based modeling (ABM) takes a different architectural approach. Where cadCAD and Monte Carlo model the token economy from a top-down aggregate perspective (the system has these state variables and these aggregate update rules), ABM models it from the bottom up.
In an agent-based model, individual actors (token holders, stakers, traders, liquidity providers, arbitrage bots, institutional allocators) each follow their own behavioral rules and interact with the protocol and with each other. System behavior emerges from those individual interactions rather than from aggregate assumptions. A sell-off is not "circulating supply increases by X% at month 12." It is "10,000 simulated holders each evaluate their position based on their individual rule set when the cliff hits, and 2,400 of them decide to sell."
This produces a fundamentally different class of insight. ABM is most valuable when the design question explicitly depends on heterogeneous agent behavior that aggregate models will miss. The most common triggers:
DePIN node operator incentives. How do node operators with different cost structures respond to decreasing rewards as network coverage grows? Aggregate models assume uniform behavior. ABM can model operators with different break-even thresholds exiting at different points.
Liquidity mining dynamics. How do mercenary capital providers, long-term holders, and automated arbitrage bots each respond to the same incentive structure? What does the aggregate liquidity curve look like when those three actor types are all present?
Unlock cliff heterogeneity. Different investor tranches have different hold strategies. A model that treats all unlocked supply as uniformly likely to sell misses the distinction between seed investors locked for 36 months and strategic partners locked for 12.
The limitation with ABM is that it requires behavioral assumptions for agent rules. Those assumptions are inherently uncertain, and the model is only as good as the assumptions you feed in. ABM is most defensible when the behavioral rules are grounded in observed on-chain data from comparable protocols. Risk modeling firms publish agent-based and economic stress-test research on live protocols; Gauntlet's research library is a useful public reference for how those behavioral assumptions get grounded in real data.
ABM is also the most resource-intensive approach to build and calibrate. We use it when the design question genuinely depends on agent heterogeneity. We do not use it by default.
#How to Choose the Right Tokenomics Modeling Approach
The three approaches are not competing alternatives. They are tools for different questions. The table below lays out where each one fits before we get to the decision logic.
| Dimension | cadCAD simulation | Monte Carlo analysis | Agent-based modeling |
|---|---|---|---|
| Technical complexity | High. Requires building a full state machine in Python and defining update rules for every mechanism. | Low to moderate. Can run on a spreadsheet model or layer on top of cadCAD. | Highest. Requires specifying behavioral rules for every agent type and calibrating them against on-chain data. |
| Use case | Feedback-loop designs where one mechanism's output feeds the next: staking, supply, price signals. | Sensitivity analysis: how outcomes vary across uncertain inputs like price, growth, and emissions. | Designs that turn on heterogeneous actor behavior: different investor tranches, node operators, and mercenary capital responding differently. |
| Time to insight | Slower. Building and validating the state machine takes the most setup before the first useful run. | Fastest. A parameter sweep on an existing model produces a distribution quickly. | Slowest. Agent rules and calibration are the most labor-intensive to build and defend. |
| Recommended for | Protocols with staking, treasury, and emission loops that interact over 12 to 48 months. | Pre-TGE financial modeling, treasury runway sensitivity, and unlock cliff scenarios. | DePIN incentive design, liquidity mining with mixed actor types, and unlock-cliff heterogeneity. |
Here is the decision logic that follows from that table:
Question 1: Does your token model have feedback loops? If yes, cadCAD is the right foundation. Feedback loops, where the output of one mechanism feeds back as input to another, are what cadCAD was designed to model. If no (linear emission schedule, fixed treasury drawdown, no staking), a Monte Carlo stress-test on a financial model may be sufficient.
Question 2: Is the primary question about the distribution of outcomes under input uncertainty? If yes, Monte Carlo is the right technique, whether as a cadCAD parameter sweep or standalone. Treasury runway sensitivity, unlock cliff scenarios, and investor deck financial projections are Monte Carlo questions. If the question is about mechanism interaction rather than input uncertainty, cadCAD without Monte Carlo sweeps may be sufficient for a first pass.
Question 3: Does the design turn on how heterogeneous actors with different behavioral rules will interact? If yes, ABM is warranted and will produce insight the other two approaches will miss. If the design question can be answered assuming homogeneous aggregate behavior, ABM adds cost without corresponding value.
In practice, sophisticated tokenomics engagements use all three in combination. cadCAD provides the state machine. Monte Carlo sweeps across the parameter space. ABM validates the behavioral assumptions under heterogeneous conditions. The right question to ask before commissioning a modeling engagement is not "which approach do we use?" but "what specific design question does the model need to answer?" Answering that question first is what keeps a modeling engagement from producing outputs nobody acts on.
A tokenomics consulting engagement with a quantitative layer will usually specify the approach in the brief before the model is built. If a firm cannot tell you which approach they are using and why, that is a diagnostic signal worth paying attention to.
#What a Tokenomics Modeling Engagement Actually Produces
The output of a tokenomics modeling engagement is not a model file. The output is a set of design decisions with evidence.
A well-run engagement produces: the model itself (state variables, update rules, parameter ranges, all documented so the assumptions are explicit and auditable), the simulation output (trajectory distributions for key state variables, sensitivity tables showing which assumptions most dramatically change the outcome), and the design recommendations the simulation surfaced.
That last item is what a whitepaper cannot produce. The model may show that the unlock cliff at month 12 generates sell pressure that existing liquidity pools cannot absorb under median assumptions. The design recommendation is: extend the cliff, reduce the unlocking tranche size, or build a liquidity reserve that can absorb the event. The model is the evidence. The recommendation is the deliverable.
The simulation output also lives in the tokenomics data room as a supporting document for investor due diligence. Institutional capital has started asking "was this modeled?" as a standard question in due diligence. The answer matters, and the model needs to be readable. Not just a Python file on GitHub.
Across 80+ projects, the design questions most commonly surfaced by modeling fall into four areas: unlock cliff timing, staking APY sustainability, treasury runway sensitivity, and DePIN node reward decay. These are the questions whose answers are most expensive to discover after launch.
If you want to understand whether your current design holds up under stress, book a discovery call.
#Common Modeling Mistakes (and How to Avoid Them)
Modeling with optimistic assumptions, not realistic ones. The most common failure mode. The model validates the whitepaper instead of stress-testing it. Build the inputs from conservative and median assumptions first; the upside scenarios can come later.
Commissioning a model without a specific design question. "Run a cadCAD model" is not a design question. Without a specific question the model is supposed to answer, the output is trajectories with no interpretation. Define the design question first.
Treating simulation output as a price forecast. The model shows how the mechanism behaves under stated assumptions. It says nothing about what price does in the open market. Any framing of model output as a price forecast is incorrect and, depending on the audience, creates legal exposure.
Skipping Monte Carlo parameter sweeps. A single-run cadCAD model shows one scenario under one set of assumptions. The distribution is where the insight lives. Parameter sweeps surface which assumptions the design is most sensitive to. Skipping them produces false confidence.
Choosing ABM when the design question does not require it. ABM is the most expensive approach to build and calibrate. If the design question can be answered with aggregate modeling, ABM adds cost without corresponding value. Reserve it for designs where actor heterogeneity is genuinely material.
#What the Limits of Tokenomics Modeling Are
Modeling is not a crystal ball. Being clear about what it cannot do is part of using it responsibly.
What modeling cannot capture: market sentiment, coordinated speculation, regulatory events, competitor launches, whale behavior that deviates from programmed agent rules, or any exogenous shock that falls outside the model's defined parameter space.
What this means in practice: a model that shows the design survives under reasonable assumptions is a floor, not a ceiling. The design is stress-tested, not guaranteed.
We've seen designs pass our simulation suite and still underperform in market because of exogenous factors no model could have captured. Simulation reduces the odds of preventable failures. It does not eliminate the unpreventable ones. The distinction matters.
Founders who have been in the space long enough to have watched projects fail in ways that would have been obvious in a model tend to value simulation most. Founders who have not yet seen a mechanism failure tend to under-value it. The honest version of this section is what earns trust from the ones in the first category.
#Getting a Tokenomics Model for Your Project
If your project is approaching a token generation event, or if you have an existing design that has never been stress-tested, there are two paths.
Option 1: build in-house. This requires a quantitative engineer with cadCAD experience, access to reliable on-chain data for behavioral assumptions, and the time to build, calibrate, and interpret the model. The open-source cadCAD framework is publicly available on GitHub with documentation from the original development team.
Option 2: commission a tokenomics consulting engagement that includes modeling as a deliverable. The Tokenomics.net engagement runs cadCAD simulation, Monte Carlo stress testing, and (when the design question requires it) agent-based scenario analysis. Our quantitative layer is run by Abdur Rehman. We design the token model, run the simulation, and deliver the design changes the simulation surfaces. Not just the model output as a PDF the client's team has to interpret.
The TGE window is the best time to run a model. After launch, the design is in production and changes are expensive. Before launch, the model output is still actionable.
If you're building onchain and need your token model to hold up under institutional scrutiny, book a discovery call. We'll assess your project and tell you whether we're the right fit. Sometimes we're not. We'll tell you that too.
Tokenomics modeling is a category with three tools. cadCAD handles feedback-loop designs. Monte Carlo stress-tests assumption sensitivity. Agent-based modeling captures heterogeneous actor behavior. Most serious pre-launch engagements use all three in combination because the design questions that matter most rarely have a clean single-method answer.
The token is infrastructure. The business underneath it is the engine. Tokenomics modeling is how you confirm the infrastructure is built to hold the load before you launch.