Machine Economy Simulator
An economy with 1,000 users and 100 agents. Set nine rules, face nine crisis categories, and see whether it survives.
This is the playable version of Create a Machine Economy, the most advanced capstone.
The setting is identical: 1,000 users, 100 agents, one settlement stablecoin, one chain, and one market. Set a rule for each of nine areas, then the system randomly triggers five of nine crisis categories.
You are examining how your rules fail, not guessing the future.
What it is
This is a rule model, not a forecasting model.
It does not claim to predict the evolution of real machine economies. Nobody can. It guarantees one thing:
The same rules and seed always produce the same result.
Every loss can therefore be traced to a specific rule. That is its teaching value: controlled experiments rather than gambling. Change one rule, rerun, and inspect the difference.
We set every number in the model; they were not measured. Question those numbers, but pay closer attention to structure: which rule blocks which event, and what each rule costs.
None of the nine rules is free
This is the simulator's main lesson. Every option states both its benefit and its cost.
Choosing all the safest options lets you survive, but transaction volume is tiny and user growth nearly stops. Choosing all the aggressive options makes early numbers look excellent, until one event empties the treasury.
No configuration optimizes every dimension. This is the same principle as the capstone's six follow-up questions after every institutional change.
Start
The defaults pursue growth without defenses: open entry, a hot wallet, service before payment, no reputation, no fee take, token subsidies, and no circuit breaker. Run once to see how it fails, then change rules individually.
The simulation stops at collapse, so the deficit and losses count only up to that tick. A system that lasts longer can accumulate a deeper deficit. Compare configurations by ticks survived first.
- Tasks completed 1,080; protocol revenue $0
- Subsidy spending $18,000
- Tasks completed 1,123; protocol revenue $0
- Subsidy spending $18,720
- Tasks completed 1,166; protocol revenue $0
- Subsidy spending $19,440
- Event: Regulatory changes — The main market requires every participant to complete identity checks or it closes deposit and withdrawal channels.
- User churn 361: identity verification cannot be completed, so deposit and withdrawal channels close
- Loss $44,384: Build a compliance process in a hurry
- Tasks completed 1,210; protocol revenue $0
- Subsidy spending $20,160
- Tasks completed 1,253; protocol revenue $0
- Subsidy spending $20,880
- Tasks completed 1,307; protocol revenue $0
- Subsidy spending $21,780
- Tasks completed 1,361; protocol revenue $0
- Subsidy spending $22,680
- Event: Liquidity crisis — Many agents try to convert earnings into stablecoins and exit at once; market depth cannot absorb them.
- Loss $18,837: No buyers remain in the auction market and the execution price collapses
- Loss $15,698: With no revenue source, the treasury must dip into principal to defend the market
- Tasks completed 1,415; protocol revenue $0
- Subsidy spending $23,580
- Tasks completed 1,469; protocol revenue $0
- Subsidy spending $24,480
- Tasks completed 1,523; protocol revenue $0
- Subsidy spending $25,380
- Tasks completed 1,588; protocol revenue $0
- Subsidy spending $26,460
- Event: Oracle failure — The price feed stops updating, so all pricing and settlement use stale data.
- Loss $32,314: Without a circuit breaker, the system keeps settling at stale prices until someone notices
- Tasks completed 1,652; protocol revenue $0
- Subsidy spending $27,540
- Tasks completed 1,717; protocol revenue $0
- Subsidy spending $28,620
- Tasks completed 1,782; protocol revenue $0
- Subsidy spending $29,700
- Tasks completed 1,858; protocol revenue $0
- Subsidy spending $30,960
- Tasks completed 1,933; protocol revenue $0
- Subsidy spending $32,220
- The treasury runs dry and the economy stops.
What the nine events test
Each event tests particular rules. You cannot control the event, but your rules determine the damage.
| Event | What happened | Rules tested | Read more |
|---|---|---|---|
| Liquidity crisis | Many agents try to convert earnings into stablecoins and exit at once; market depth cannot absorb them. | Market, Protocol Fee | Chapter 15 |
| Oracle failure | The price feed stops updating, so all pricing and settlement use stale data. | Market, Security | T21 |
| Agent attacks | Someone registers agents in bulk and uses fake tasks between them to inflate activity and claim subsidies. | Agent Identity, Reputation, Token | T29 |
| Stablecoin depeg | The stablecoin used for settlement drops to 0.93, shrinking every balance denominated in it. | Payment, Security | Chapter 13 |
| Token crash | The protocol token falls 70% in a week. | Token, Protocol Fee | Chapter 21 |
| AI hallucinations | Many agents produce wrong results from a fabricated claim, and users demand compensation. | Reputation, Payment, Security | Chapter 31 |
| Model fails | The underlying model service goes down for six hours; no agent can finish its task. | Reputation, Payment | T35 |
| Wallet compromised | A batch of agent signing keys leaks; attackers begin draining balances. | Wallet, Security | T34 |
| Regulatory changes | The main market requires every participant to complete identity checks or it closes deposit and withdrawal channels. | Agent Identity, Governance | Chapter 24 |
How to use it
Run the defaults and read the full log.
Do not rush to change anything. Identify the first deficit tick, the final blow, and the rule listed after each loss.
Change one rule at a time and keep the seed fixed.
This controls variables. Replace the single main wallet with session keys and limits, leave everything else unchanged, and rerun. Theft losses fall by an order of magnitude.
Change two rules together and you cannot tell which caused the difference.
Change the seed and run the same rules three more times.
Different seeds produce different event combinations. Surviving one seed alone is luck, not robustness.
Identify the event your configuration fears most.
Every configuration has a weakness. Find it, then decide whether to fix it or accept it and document what you explicitly do not defend against.
Acceptance is a legitimate answer if documented. T30's threat modeling discusses this.
Write your design explanation.
The simulator output is not the artifact; your explanation is. Give every rule three lines: what you chose, why, and how you will bear its cost.
This begins that capstone's design document.
Conclusions worth verifying yourself
These relationships hold within the model. Do not take my word for them; run it yourself.
Choose token issuance with subsidies. Early task volume and agent growth rise faster.
Then watch subsidies consume the treasury each tick and amplify agent attacks or token crashes. Free registration plus subsidies creates a cash machine for farming operations.
Compare chapter 17 on yield sources and chapter 28 on users after airdrops stop.
Keep other rules fixed and find a seed triggering wallet theft:
A single main wallet loses 30% of the treasury, session keys lose 6%, and multisig almost nothing.
The cost remains: multisig cuts transaction volume by a quarter. This is the numeric version of T34's claim that session keys limit blast radius.
With no fee take, the treasury only pays out and never earns. Ordinary operation already drains it.
Any event may then be the final blow, because there is no buffer rather than because the event is exceptionally severe.
Compare chapter 26: high TVL does not mean revenue.
With no circuit breaker, oracle failure and stablecoin depeg losses grow because the system runs on incorrect data until someone notices.
Limits plus human approval block almost everything but cut volume by 30%.
There is no universal answer. Choose which cost your economy can bear.
Add only a circuit breaker and then a 5% fee to the defaults. Counterintuitively, the treasury becomes more negative, roughly from -2,000 to -38,000.
It looks as though fees worsen things. Inspect ticks survived instead:
Default collapses at tick 16 deficit -1,833 losses 111,233
Circuit breaker collapses at tick 17 deficit -2,129 losses 78,049
Circuit breaker + 5% fee collapses at tick 18 deficit -38,005 losses 67,547
Subsidies also disabled survives 24 ticks treasury +336,277 losses 165,435Fees actually buy two more ticks. The deeper deficit comes from surviving longer while subsidies keep draining money.
The conclusion is that fees cannot rescue a protocol bleeding subsidies. This configuration survives only after subsidies stop.
Also notice the final row: the survivor has the highest cumulative losses, because it encounters all five events. Early failures show smaller losses because they never reach later events.
The trap teaches that a bad metric can make longer survival look like worse performance. Chapter 26's TVL-versus-revenue distinction is the same kind of mistake.
No token means slow growth, low task volume, and unimpressive numbers.
But token crashes barely affect it, and agent attacks lose their biggest incentive.
This numerically illustrates chapter 30's question: when is a token entirely unnecessary?
Relationship to the capstone
The simulator covers only part of the capstone. It executes rules for you but does not design them.
The capstone asks you to define event impact paths, justify every change, and explain who benefits, who bears costs, and under which conditions it works. The simulator is a repeatable sandbox for making mistakes before writing the explanation.
See the final section of the capstone for complete requirements.
Where the engine lives
Simulation logic lives in packages/curriculum/src/simulator.ts, with twelve unit tests covering determinism, event scheduling, and causal assertions such as defensive configurations losing less than aggressive ones.
The UI contains no simulation logic. Once logic spreads into components, why losses occurred becomes hard to test. This also applies T32's principle: the decision-making part must be deterministic and testable.