Monetary policy engine

The monetary policy engine is a custom-built automated economic management system developed specifically for Prosperity SMP. It tracks every dollar created and destroyed on the server, decomposes the money supply into policy-relevant buckets, computes a real-time inflation signal from the Consumer Price Index, and generates advisory recommendations to maintain a healthy economy. The entire system — from event capture to controller logic — was purpose-built for this server.

Design philosophy

Real-world central banks use the relationship between money supply, spending velocity, prices, and output to guide policy. The Prosperity SMP engine draws on the same principles but takes a deliberately simpler approach: rather than trying to estimate all four variables (which is unreliable with a small player base), it directly observes price changes through the CPI and reacts proportionally.

The engine was designed through a five-round iterative critique between two AI systems (Claude and ChatGPT). The original v1 draft attempted to directly compute inflation pressure from money supply growth minus output growth. This was rejected during the critique — velocity and output are too noisy with 10-15 players. The v2 design watches CPI directly and uses money supply data for dashboard diagnostics rather than direct control.

Architecture

The system operates across two custom-built layers.

Skript capture layer (Minecraft server)

Three custom Skript files capture every money flow event in real time:

• treasury-grant.sk — a single entry point for all money creation. Every script that pays a player routes through this wrapper, ensuring nothing enters circulation untracked.
• money-supply.sk — classifies every Vault transaction into a five-category taxonomy, computes money supply decomposition with exponential activity decay, runs stock-flow reconciliation, and exports JSON snapshots every 5 minutes.
• cpi-basket.sk — computes a winsorized geometric mean Consumer Price Index from real player-to-player trade data, with manipulation defenses and per-item confidence scoring.

Admin Hub controller layer (TypeScript)

A custom module in the Next.js Admin Hub ingests the Skript-exported JSON and runs the policy controller:

• Loads current money supply, CPI, lagged CPI, reconciliation state, and money flow events
• Computes the inflation gap (observed CPI growth vs target)
• Evaluates a confidence score from four data quality components
• Applies a proportional controller with locked safety bounds
• Aggregates source-flow ratios (sink intensity, bank drain, job faucet)
• Generates a recommendation with reasoning trace and uncertainty band
• Persists an hourly audit log for historical analysis

Event taxonomy

Every balance change on the server is classified into exactly one of five categories:

Category	Definition	Effect on total supply
CREATE	Money appears from nowhere (job wages, contract rewards, crate cash, /eco give)	Increases supply
DESTROY	Money disappears (admin shop purchases, fees, /eco take)	Decreases supply
TRANSFER_TO_PUBLIC	System pays player (Sim Shop payouts)	No change
TRANSFER_FROM_PUBLIC	Player pays system (rent to system landlord)	No change
TRANSFER_PRIVATE	Player pays player (ChestShop sales, /pay)	No change

Currently tracked sources: Jobs payouts, /eco give and /eco take, civic contract rewards, Simulated ChestShop payouts, and Admin shop (EconomyShopGUI) transactions. All hooks are live and producing data.

Money supply decomposition

The engine decomposes total money into three buckets with different policy relevance:

Bucket	What it contains	Why it matters
M_active	Balances of players who logged in within 14 days, weighted by exponential decay	Money actively chasing goods — the primary inflation-relevant pool
M_dormant	Balances of inactive players	Not circulating; a returning player creates a "liquidity shock"
M_reserve	CentralBank and system accounts	Sterilized reserve — only enters circulation when disbursed

The effective supply formula:

M_effective = M_active + (0.20 x M_dormant) + (lambda x M_reserve)

Where lambda estimates how much reserve money will enter circulation in the next 7 days. The activity decay uses:

weight = max(0.05, e^(-days_since_login / 14))

This decomposition appears on the Admin Hub dashboard. The controller itself uses CPI data (not M directly) for recommendations — M decomposition is a diagnostic signal for admins, not a control input in v1.

Stock-flow reconciliation

An hourly integrity check ensures tracked events match reality:

Change in M_total = SUM of CREATE events - SUM of DESTROY events

If the observed total diverges from the predicted total by more than 2%, the engine disables all recommendations. This is the "hard gate" — it prevents acting on bad data. As of deploy, reconciliation passes consistently with error under 0.01%.

Controller: the actual formula

The v1 controller is a CPI-gap proportional controller. It directly observes price changes and reacts:

gap = (current_basket_index / lagged_7d_basket_index) - 1 - target_growth

new_multiplier = old_multiplier x (1 - confidence x 0.20 x gap)

In words: the engine computes how fast the CPI basket is growing relative to the admin-set target (+0.5% per week default). If prices are rising too fast, it recommends lowering the Sim Shop multiplier. If too slow, it recommends raising it. The magnitude is scaled by data confidence.

Locked constants

Parameter	Value	Meaning
K_p	0.20	Proportional gain (intentionally conservative — actuator response is unknown)
Target growth	+0.5%/week	Default healthy inflation rate
Dead-band	+/- 0.3%	Below this gap magnitude, engine outputs NO_OP
Max weekly change	+/- 5%	Hard clamp on multiplier movement per week
Multiplier bounds	0.7 to 1.3	Absolute floor and ceiling
Min confidence (display)	0.30	Below this, recommendations are suppressed
Min confidence (auto-apply)	0.70	v2 auto-apply threshold (not active in v1)

Why proportional-only

The spec includes provisions for adding derivative (D) and integral (I) control terms later, forming a full PID controller. These are deferred because:

• The D term requires smoothed historical data (EWMA, not yet accumulated — needs ~14 days)
• The I term can accumulate error during bad-data periods and needs anti-windup
• The actuator gain (how much multiplier change produces how much CPI change) is unknown until perturbation experiments run at day 30+

v1 ships the simplest controller that makes correct directional decisions. More sophisticated control is a future upgrade backed by accumulated data.

Confidence scoring

Component	Measures	Maximum when
Basket coverage	Fraction of CPI basket items with valid trade data	All items pass depth gates
Sample depth	Average transactions per basket item	50+ transactions per item
Diversity	Unique buyers + sellers across basket	8+ unique participants
Maturity	Days since server deploy	90+ days

confidence = (coverage x depth x diversity x maturity) ^ (1/4)

The geometric mean ensures all four components must be healthy. Each is floored at 0.1 to prevent any single zero from killing the score entirely.

NO_OP conditions

The engine outputs "no action" when any of:

1. Confidence below 0.30
2. Gap within dead-band (+/- 0.3%)
3. Reconciliation failing (hard gate)
4. Fewer than 5 active players in 7 days
5. Previous action not yet observed (one-week cooldown)
6. New-player spike (3+ new players in 48 hours)
7. Within first 14 days of operation (Phase A bootstrap)

NO_OP is the most common output on a young server. The engine is designed to be cautious — doing nothing is better than acting on insufficient data.

Bootstrap schedule

Period	Behavior
Day 0-14	Advisory disabled. Dashboards live. Data collection running.
Day 14-30	Advisory enabled with confidence scaling. No auto-apply.
Day 30-90	Category-level perturbation experiments to measure actuator response.
Day 90+	Auto-apply eligible if confidence sustained above 0.70.

Source-flow ratios

The controller also computes diagnostic ratios displayed on the Admin Hub:

Ratio	Formula	What it tells admins
sink_ratio	(DESTROY + TRANSFER_FROM_PUBLIC) / M_active	How fast money leaves active circulation
bank_drain_ratio	TRANSFER_TO_PUBLIC / M_active	How fast the bank injects liquidity
jobs_faucet_ratio	CREATE from Jobs / M_active	Job wage intensity vs the active money pool
net supply change	CREATE - DESTROY over 7 days	Bottom-line money supply movement

Design lineage

The engine spec was refined through five rounds of Claude/ChatGPT iterative critique, correcting three material flaws in the original v1 draft:

1. CentralBank counted as active money — corrected to sterilized reserve with lambda-weighted disbursement forecast
2. Policy response was inverted — the v1 draft raised the inflation target during high pressure (accommodation); corrected to proportional tightening toward a fixed target
3. "Deflation via fewer purchases" was mislabeled — reducing the faucet slows growth (disinflation) but does not contract existing supply (real deflation requires sinks)

The locked v2 spec is maintained in the server's internal documentation.

See also

• Consumer Price Index — the CPI basket the engine observes
• Economy — how money flows through the server
• Simulated ChestShop — the custom market activity system
• Admin shop — server-run shop (a money sink)
• Prestige — endgame money sink at scale