economy APIforumDiscord archiveBlueMapinferred
Power ranking
A single 0–100 index fusing economic standing, political clout, and engagement.
Power = 0.45·Wealth + 0.45·Political + 0.10·Engagement
Wealth = max( cash, 0.90·commerce, 0.85·property ) (log-scaled, normalized to the richest actor)
cash = 100 · log10(1+netWorth) / log10(1+maxNetWorth)
commerce = 100 · log10(1+shopCount) / log10(1+maxShops) [ChestShops owned]
property = 100 · log10(1+plotsOwned) / log10(1+maxPlots) [realty titles held]
Political = 100 · politicalRaw / maxPoliticalRaw (normalized to the strongest current actor)
politicalRaw = office points + track record + judicial + legislative
President 100 (× term progress) · VP 60 · Speaker/Senate-Pres 50 · Justice 40
Senator 35 · Rep 30 · Cabinet 30 · other office 15
+ 8·presidentialWins + 3·candidacies + 5·runoffs
+ 4·casesWon + 1·casesFiled + 1.5·commonwealthCases
+ 6·actsSponsored + 2·billsSponsored
Engagement = 100 · min(1, playtimeHours / 300) (or 50 if office-holder & playtime unknown, else 0)
Why log-scaled & weighted
The top 1% holds ~43.5% of all wealth (Gini ~0.734), so a linear wealth scale would crush everyone below the whales to zero. Wealth is therefore taken on a log scale and defined as the strongest of three economic signals — liquid cash often misses business wealth, so commercial footprint (ChestShops, capped at 90%) and real-estate footprint (plots owned, capped at 85%) can carry a player whose bank balance is low. Political strength is normalized so the sitting President anchors near 100.
Data sources
economy APIforumDiscord archiveinferred
Update cadence
Recomputed nightly from the latest snapshot and persisted as a ranking. If the nightly job hasn't run yet, the page falls back to a live wealth-only ranking.
Known gaps
Office, election, court, and legislative counts are parsed from forum and Discord archives — gaps there understate a player's political score. Net worth is personal cash from the economy API and excludes firm treasuries the player controls (commerce and property signals partially compensate). Engagement defaults to a flat 50 for office holders when no playtime is recorded, so it is a coarse proxy, not a true activity log. The default weights (0.45 / 0.45 / 0.10) are an editorial choice, not a measured ground truth.
CMA plot valuation
A comparative-market-analysis estimate for any plot, plus an explainable premium multiplier.
Estimate = weighted comps (recent, nearby, same-type sales weigh more)
Premium = Estimate · Π (1 + factorᵢ) clamped to 0.40×–2.50×
Factors (each only applies where it's predictive):
size 0.28·log2(area / type-median area) clamped −33% … +50%
location commercial only: +55% <500b to core · +6% <1200b · −28% if satellite
metro commercial only: +10% <75b to a station · −12% if isolated (>300b)
district Reveille Hills +20% · Reveille/Willow 0% · Aventura −5% · Oakridge / unmapped −30%
demand sold comps only: +58% (16–20 bids) · +120% (21–30) · +141% (>30)
traffic +up to 10% busy / −6% dead, from the foot-traffic score
How the factors were chosen
Every factor and magnitude was validated against the ~310 realized DemocracyCraft sales, residualized by plot-type median so plot type can't masquerade as a factor. Non-predictive candidates were dropped: resale appreciation (mean-reversion, not a plot trait), bus proximity (wrong sign), civic landmarks (non-monotonic), and location/metro for non-commercial plots (residential reverses the sign). The UI only ever shows a justification the model actually computed.
Data sources
Discord archiveforumBlueMapinferred
Update cadence
The comp set updates as new sales are parsed from Discord and forum listings; the structural premium (size/location/metro/district) is deterministic and recomputes on every page load. The foot-traffic factor updates as the BlueMap collector feeds samples.
Known gaps & the outlier caveat
Most plots have norecorded owner, and that is correct — we only name an owner when our own data does (a recorded sale buyer, an in-game realty title, or a forum eviction notice). Sale prices are parsed from free text and can be noisy. We run an outlier audit: when the latest recorded sale diverges from the model by more than ±60% (ratio <0.4 or >2.5) we flag it, because such a print is usually a rental, a title transfer, a distressed sale, or a parse artifact — not a true market comp. Treat the estimate as a loose guide, never an appraisal.
Foot-traffic score (0–100)
How busy a plot is, ranked against every other plot we sample.
raw = 0.5·ln(1+uniquePlayers) + 0.3·ln(1+visits) + 0.2·ln(1+samples) (14-day window)
score = percentile-rank of raw across all scored plots, scaled to 0–100
How sampling works
A collector polls the public BlueMap live player layer and records each online player's position. Points are resolved to plots by a plain spatial-hash point-in-box lookup, then rolled up per plot over a rolling 14-day window. The score is rank-based, not absolute: 100 means the single busiest plot, 50 the median. We also build a heatmap grid (32-block cells) from the same samples.
Data sources
BlueMap
Update cadence
Continuous while the collector is running; rollups and ranks refresh as new samples land. A plot with zero samples in the window is simply absent.
Known gaps
This only sees players the live map exposes, only while the collector is up, and only at the polling interval — short visits between polls are missed. Because the score is a percentile, it measures relative popularity, not absolute footfall: in a quiet period a modestly-visited plot can still rank high. It is a behavioral signal, not a headcount.
Playstyle classification
A readable label for a player's movement signature, from the same position samples.
Sessions split by inactivity: a gap > 12 min between samples ⇒ a new session.
Homebody — ≤2 distinct plots AND top plot > 50% of visits
Commuter — top transition > 50% of moves AND ≤4 distinct plots
Wanderer — ≥8 distinct plots
Explorer — 5–7 distinct plots
Regular — everything else
What it's built from
For each player we sessionize their visits, then derive favorite plots, login/logout spots, plot-to-plot transitions, and the distinct-plot count. The thresholds above turn that signature into one of five labels. We also surface co-presence (players repeatedly at the same plot in the same 5-minute bucket = associates) and an hour-of-day activity rhythm.
Data sources
BlueMapinferred
Update cadence
Recomputed from the live sample stream; profiles get richer the longer the collector runs.
Known gaps
The labels are heuristic thresholds, not a trained classifier — a player straddling two styles falls to whichever rule fires first. A thin sample history makes everyone look like a Homebody. The 12-minute session gap and 5-minute co-presence bucket are tuned constants, not derived from server logs.
Real-estate price index
A weekly housing-market index, base 100 at the first recorded week.
For each ISO week (Mon-anchored): index = 100 · medianSale(week) / medianSale(firstWeek)
Sales filtered to $200 … $3,000,000 to drop rent/title-transfer noise and parse errors.
Why median, why weekly
The median resists the outliers that wreck a mean in a thin market, and weekly buckets smooth the low sale count. The index is rebased to 100 at the first week we have data, so it reads as a percentage move from launch, not an absolute price.
Data sources
Discord archiveforum
Update cadence
Recomputes whenever new property transactions are parsed; a new point appears each week that has at least one qualifying sale.
Known gaps
Low weekly volume makes the index jumpy — a single week with few sales can swing it. It tracks all plot types together, so a mix shift (e.g. a run of commercial sales) can move the index without any true price change. The $200 floor / $3M ceiling is a blunt noise filter that may also clip a few legitimate sales.
Market move & breadth (commodities)
A crude commodity-index move and how broad it is, from our own snapshot diff.
Market move = median per-item % change between two ChestShop snapshots
Breadth = share of tracked items that rose
Sectors = ChestShop volume grouped by item category (share of total)
How it's computed
We compare the latest ChestShop pricing snapshot against the prior one and take the medianitem's percent change as the headline market move — the median, not the mean, so a single spiking item can't hijack the index. Breadth is the fraction of items up, distinguishing a broad rally from a narrow one. Crucially we diff our own captured snapshots and ignore the noisy in-API bot price field.
Data sources
economy API
Update cadence
Per snapshot — moves need two snapshots to exist, so history builds over the first few captures.
Known gaps
Only items priced in both snapshots count. Thinly-traded items can show large, mostly meaningless swings. Sector categories are our own mapping and a few items may land in "Other". This measures shop-listed prices, not cleared trade volume.
Risk read — The Mint (peg health)
Whether the Mint's listed instruments can actually be redeemed at their stated peg.
For each instrument we track: redeem ratio, peg health, listed face, circulation, par buy/sell.
Stress flag fires when peg health reads "partial", "no market", or "redeem" (constrained redemption).
What it means
The Mint issues instruments meant to redeem at a fixed peg. The redeem ratio and a peg-health label tell you whether redemption is actually honored at face. When health reads partial, no market, or redeem-constrained, the peg is under stress — the instrument may not convert back to cash at its stated value. Our home pages count broken pegs and flag the Mint as "HOT" when any are stressed.
Data sources
economy APIinferred
Update cadence
Per Mint snapshot — we read the most recent capture of each instrument.
Known gaps
Redeem ratio and peg-health labels are captured as reported, not independently audited — if the upstream feed is stale or mislabels an instrument, the read inherits that. The stress test is a keyword match on the health label, so an unusual phrasing could be missed. This is a liquidity/redemption flag, not a full solvency model of the Mint.
Found a number that looks wrong? Most likely it's a parse caveat described above — these are models over public data, not official server statistics.