Economy, Trading & Security

Deep reference on economy design, trading, item systems, anti-cheating, anti-exploit, moderation, and how these map to an Urbit MUD. Complements the economy overview in 05-mud-game-design.md.

1. Economy Design

1.1 The Faucet/Sink Model

Every MUD economy is a flow system. Currency enters through faucets (mob drops, quest rewards, NPC sell-back) and leaves through sinks (shops, fees, taxes, item decay). When faucets exceed sinks, you get mudflation — the purchasing power of gold collapses, newbies can’t compete, and the economy becomes meaningless.

Core equation: Rate of currency creation ≈ Rate of currency destruction

Alter Aeon implements this literally — it tracks the total gold supply in real time and dynamically adjusts mob drop rates and shop prices to maintain equilibrium. Players holding over 1M gold are taxed 2% on the excess. Result: currency peaks vary no more than 10% over a 2-year period.

1.2 Multi-Currency Systems

The strongest MUD economies use multiple currencies with different properties:

Why non-tradeable currencies matter: Aardwolf’s Quest Points can’t be freely traded between players. You earn them by doing quests. You spend them on powerful gear, character upgrades, and mandatory progression gates (800-1000 QP required per remort to Superhero). Because they can’t be bought with gold or traded P2P, no amount of wealth lets you skip the grind. This separates economic power from progression power.

1.3 Gold Sinks — What Works

Sinks only work when: Motivation + Perceived Utility > Cost

Kingdom of Looting added ultra-expensive vanity items with zero gameplay benefit specifically to soak up gold from a duplication exploit. Ultima Online’s Renaissance expansion introduced luxury items at NPC vendors to drain accumulated wealth.

1.4 NPC Pricing

Static pricing problems: If NPCs buy and sell at fixed prices, they create infinite currency generation (sell items worth more than their ingredients) or become irrelevant (prices disconnected from player economy).

Dynamic pricing approaches:

• Alter Aeon: Tracks global money supply, adjusts drop rates and shop prices automatically
• Supply-based: NPC stock depletes when bought, restocks over time; prices rise with scarcity
• Friction model: Buy at X, sell back at X/2 — the spread is the sink. Simple but effective
• Yesterday’s price: NPCs charge based on recent transaction averages — self-correcting

Key principle: NPC vendors should set price floors and ceilings, not compete with player trading. If NPCs offer better deals than other players, the player economy dies.

1.5 Crafting Economies

Crafting serves as both a sink (consuming raw materials and gold) and a source of player-driven trade. Design considerations:

• Material sources: Mob drops, gathering skills, NPC vendors (at markup)
• Failure rates: Failed crafts that consume materials are a powerful sink but frustrating
• Specialization: If everyone can craft everything, crafting has no trade value
• Crafted vs. dropped: Crafted gear should fill a distinct niche (customizable, repairable, specific stats) rather than being strictly worse than drops
• Repair economy: Only crafters can repair gear → guaranteed ongoing demand
• Resource tiers: Low-tier materials remain valuable if high-tier recipes require them

1.6 Real Money Trading (RMT)

Three philosophical approaches:

1. Prohibit and enforce (most MUDs): Ban RMT, detect it through unusual trading patterns, punish offenders. Difficult to enforce fully. Players find workarounds.

2. Channel and tax (IRE/Achaea model): Sell premium currency officially. If players can buy credits from the developer and sell them to other players for gold, the developer captures RMT revenue, controls supply, and the premium currency acts as a gold sink (gold flows from buyer to seller, credits leave circulation when used).

3. Tolerate and ignore: Accept that RMT will happen. Design the game so it doesn’t matter much (non-tradeable progression currencies, skill-based gameplay).

1.7 Case Study: IRE Credits (Achaea)

Matt Mihaly’s Achaea pioneered microtransactions in gaming — years before Oblivion’s horse armor.

The system:

• Credits: Purchasable with real money on achaea.com. Can be traded to other players for gold, sold on the in-game credit market, or converted to bound credits
• Bound Credits: Permanently attached to a character. Used for lessons (skill training), artifacts (powerful items), pets, houses. Cannot be traded or transferred
• Conversion: Any credit can be bound (irreversible). First 1000 credits bound get a bonus: 8.5 lessons/credit instead of 6
• Iron Elite Membership: Monthly subscription → 100 bound credits/month + 10% bonus on all credit purchases

Economic effects:

• Credits act as a gold sink: players spend gold buying credits from other players
• Bound credits prevent inflation of the premium currency itself
• The credit market creates a player-driven exchange rate between gold and real money
• Revenue funds ongoing development — IRE games have run for 25+ years

Criticism: Pay-to-win concerns. A player who spends $5,000 on credits will have vastly more artifacts and skill training than a free player. IRE’s response: the games are free to play, spending is optional, and skill matters more than gear in PvP.

1.8 Case Study: Aardwolf’s Quest Points

Why QP works:

• Non-tradeable (can’t buy progression with gold)
• Earned through active gameplay (quests, campaigns, global events, lasertag)
• Mandatory for progression (remort requires 800-1000 QP)
• Spent on exclusive gear (quest equipment with special effects)
• Convertible to Trivia Points (one-way, for housing/cosmetics)
• Usable in remort auctions (bidding on other players’ quest equipment using QP)

Design insight: QP creates a parallel economy that gold can’t touch. Rich players and quest-grinding players have different advantages, which keeps both playstyles relevant.

2. Auction Systems

2.1 How MUD Auctions Work

MUD auctions are typically channel-based — the auction is broadcast to all players on the auction channel.

Aardwolf’s three-tier system:

Quick Auction flow:

1. Player types auction <item>
2. Item stats broadcast to auction channel
3. Other players bid with bid <amount>
4. ~90 seconds, highest bid wins
5. Seller receives gold minus 10% tax
6. If no bids, item is lost (intentional — discourages spamming junk)

Marketplace flow:

1. Player types market sell <item> <currency> <days>
2. Item listed for up to 7 days, persists through reboots
3. Players browse with market list, bid with market bid <#> <amount>
4. If bid received within 10 minutes of closing, timer resets to 10 minutes (anti-sniping)
5. Minimum bid increments prevent penny-bidding

2.2 Achaea Auctions

Achaea runs periodic auctions (typically 10 days) for rare artifacts and items. Players bid using credits or gold. These are event-driven rather than continuous — creating urgency and competition.

2.3 Auction Taxes as Gold Sinks

The 10% auction tax is one of the most effective gold sinks:

• Scales naturally with economic activity
• Higher-value items drain more gold
• Feels fair — you only pay when you profit
• RuneScape’s Grand Exchange uses a 2% tax, which funds algorithmic item buybacks
• Sweet spot is 2-10% — higher taxes drive trading off-platform (private trades to avoid fees)

2.4 Preventing Auction Manipulation

3. Item Rarity and Power Budgets

3.1 Tier Systems

Most MUDs use a rarity hierarchy for items:

Realm of the Mad God approach: Items roll sequentially through tiers — 50% chance of uncommon, then 37.5% rare, 25% legendary, 12.5% divine. Each tier adds enchantment slots.

3.2 Power Budgets

A power budget assigns each item a numeric “budget” of stat points that scales with tier. This prevents individual items from being disproportionately strong.

Implementation:

• Each stat point costs a fixed amount of budget
• Higher-tier items get more budget
• Enchantments consume budget — you can’t stack everything
• Most power comes from the first 2 stat slots; 4-slot items shouldn’t be dramatically stronger than 2-slot
• Use decimal stat values internally (e.g., +2.1 Wisdom rounds to +2) for fine-grained balancing

Power creep prevention:

• Horizontal progression: New items are side-grades (situationally better) rather than strict upgrades. Old School RuneScape favors this approach
• Equipment limits: Cap the number of legendary/unique items equipped simultaneously (like Destiny’s exotic limit)
• Stat caps: Hard or soft caps on individual stats prevent stacking
• Diminishing returns: Each additional point in a stat gives less benefit

3.3 Bind-on-Pickup (BoP) and Bind-on-Equip (BoE)

BoP: Item becomes permanently bound to the character who loots it. Prevents trading of the best gear, ensuring players earn their own.

BoE: Item can be traded until first equipped. Allows a market for unequipped rare drops while preventing infinite circulation of top-tier gear.

Arguments for BoP:

• Prevents best gear from concentrating among wealthy players
• Maintains incentive to run content (can’t just buy everything)
• Keeps content relevant (gear has to be farmed, not purchased)

Arguments against BoP:

• Feels artificial — why can’t I give my friend a sword?
• Reduces player trading (a core MUD social feature)
• Players who get unlucky on drops can’t compensate through trading

Alternative: Item decay — items degrade with use and eventually break. Serves the same economic function (removing items from circulation) but feels more organic. Games like Ryzom and EVE Online use decay/destruction as their primary item sink, making BoP unnecessary.

3.4 Item Decay and Durability

3.5 Unique and Artifact Items

Some items should exist as one-of-a-kind in the game world:

• Narrative artifacts: The Sword of the First King — only one exists, quest reward
• Competition prizes: Tournament winner gets a unique item
• Discovery rewards: First player to find a hidden area gets a unique
• Rotating uniques: Only one can exist at a time; when holder dies/quits, it respawns

Design risk: Unique items that are too powerful create “haves vs. have-nots” permanently. Keep uniques interesting (unique effects, lore significance) rather than strictly powerful.

3.6 Enchanting Systems

Enchanting adds controlled randomness and serves as both a gold sink and crafting engagement driver:

• Slot-based: Items have enchantment slots based on rarity; fill slots with specific enchantments
• Risk-based: Enchanting can fail, destroying the item or removing existing enchantments (powerful sink)
• Material-gated: Enchanting requires rare consumable materials
• Diminishing returns: Each additional enchantment on an item costs exponentially more
• Awakened enchantments: Item-specific enchantments designed and balanced for that particular item

4. Anti-Cheating and Botting Prevention

4.1 The Scripting Spectrum

MUDs exist on a spectrum of automation tolerance:

Manual only ←——————————————————————————→ Full automation
   |              |              |              |
No triggers   Aliases &     Complex        Full bots
              basic triggers  scripting      (AFK play)

Aliases: Shorthand commands (k orc → kill orc). Universally allowed.

Triggers: Automated responses to game output. The gray area:

• ✅ Typically allowed: Auto-quaff healing potion when HP drops, re-wield weapon after disarm, highlight important text
• ⚠️ Gray area: Auto-cast buffs when they expire, auto-loot corpses, combat scripting while at keyboard
• ❌ Typically banned: Auto-kill next mob after current dies, AFK leveling, auto-quest completion, area scanning for resources

Aardwolf’s line: “If you walk away from the screen once your current fight is done you will no longer be playing the game.” Triggers that let you play AFK are illegal. Triggers that assist active play are fine. Deliberate bots are removed on sight; borderline cases get warnings.

Alter Aeon’s approach: Bots are legal. But the “Bot Thwacker” automated system penalizes detected bots through XP loss, skill deterioration, and reduced kill rewards. It’s an arms race — bots are allowed, but the game actively makes them less rewarding. Rules still apply: no auto-relogging, no group botting, no botting in newbie areas or social hubs.

4.2 Bot Detection Techniques

Pattern analysis:

• Consistent action timing (humans have variable delays; bots repeat at fixed intervals)
• Repetitive command sequences (kill → loot → heal → move → repeat)
• Lack of typos or command corrections
• No social interaction (never responds to tells, never uses chat channels)
• Plays 24/7 without breaks

Timing analysis:

• Sub-human reaction times to game events
• Zero idle time between actions
• Consistent microsecond-level response to triggers
• Clock-aligned action patterns

Interaction tests (CAPTCHAs):

• Random questions from the game (“A wizard appears and asks: what is 7+3?”)
• Required response within a time window
• Failure results in penalties (teleport to jail, XP loss, forced disconnect)
• Should be infrequent enough not to annoy legitimate players

Behavioral fingerprinting:

• Machine learning models trained on “normal” player behavior
• Random forest and SVM classifiers using action frequencies, types, and intervals
• Flag players whose behavior deviates significantly from human baselines
• Alter Aeon’s Bot Thwacker uses a secret, regularly-updated algorithm

Heuristic flags (any single flag isn’t proof, but multiple flags warrant investigation):

• Never uses social channels
• Plays identical hours every day
• Movement patterns are shortest-path optimal
• Never explores — always goes to known profitable areas
• Responds to game events faster than network latency should allow

4.3 Speed Limits and Rate Limiting

• Command throttle: Maximum commands per second (typically 3-5). Exceeding = dropped commands or temporary mute
• Action cooldowns: Skills/spells have minimum time between uses
• Movement rate: Maximum rooms moved per second
• Commerce limits: Maximum trades/auctions per hour
• Connection throttle: Maximum connections per IP per time window

4.4 Multi-Playing Detection

The problem: One person controlling multiple characters to gain unfair advantages (trading between alts, PKing their own alts for drops, manipulating auctions).

Detection methods:

• IP address tracking: Same IP = flagged. Simple but defeated by VPNs/proxies
• Session overlap: Characters that are always online simultaneously, never at the same time as each other, or always in the same areas
• Trading patterns: Characters that only trade with each other
• Behavioral similarity: Identical typing patterns, same client fingerprint, correlated login/logout times
• Manual verification: Discworld’s approach — liaisons interview both players together and watch them play to confirm they’re different people before granting multi-play permission

Policies vary:

• Strict: One character per player, ever. IP-blocked from creating more (most DikuMUDs)
• Limited multi-play: Multiple characters allowed but they cannot interact in any way (Valheru)
• Permitted with restrictions: Multiple characters fine, no cross-character assistance
• Open: Do whatever you want (rare, usually sandbox MUDs)

4.5 Scripting Policies

Most MUDs publish explicit rules. Common policy elements:

1. Allowed: Aliases, highlights, simple triggers (auto-quaff, re-wield), speedwalking macros
2. Requires presence: Complex combat scripting allowed only if player is at keyboard and responsive
3. Banned: AFK automation, auto-leveling, automated quest completion, auto-relogging after admin disconnect
4. Testing: Admins may test responsiveness at any time (send a tell, ask a question)
5. Consequences: Warning → temporary ban → permanent ban. Deliberate/egregious botting = immediate ban

5. Anti-Exploit Measures

5.1 Input Validation

MUDs accept arbitrary text input over telnet, making them vulnerable to:

• Buffer overflows: Extremely long input strings. Prevention: truncate input at a maximum length (typically 256-1024 chars)
• Command injection: Malformed input that triggers unintended code paths. Prevention: strict command parsing, whitelist of valid commands
• Encoding attacks: Non-ASCII characters, control sequences. Prevention: strip/sanitize input before processing
• Argument abuse: Commands with unexpected argument counts or types. Prevention: validate argument count and types per command

5.2 Rate Limiting (Server-Side)

5.3 Economy Exploits

Duplication bugs (the nuclear option of MUD exploits):

Common dupe vectors:

• Simultaneous login: Multiple connections to same account, trade item away, both sessions save with the item. Prevention: thread-safe login management, enforce single concurrent session
• Race conditions: Exploit timing between NPC interactions (trade + pack + cancel = duped item). Prevention: state machine validation — mutually exclusive operations block each other
• Database desync: Force map transition between servers, maintain connections to both, trade on new server, old server saves stale state. Prevention: centralized state management, no client-controlled server switching
• Save timing: Crash/disconnect at exact moment of trade completion. Prevention: atomic transactions — trade either fully completes or fully rolls back

Prevention architecture:

• Assign unique GUIDs to every item instance
• Database-level uniqueness constraints on item IDs
• Item provenance logging (who created, who held, when transferred)
• Periodic audits comparing expected vs. actual item/gold totals
• Kill switch: ability to roll back or freeze economy if exploit detected

Stat manipulation:

• Validate all stat changes server-side; never trust client-reported values
• Range-check all stat values on every game tick
• Log anomalous stat changes for review
• Ensure stat modifiers from equipment are recalculated on equip/unequip, not cached

Economy manipulation:

• Monitor for unusual wealth accumulation (player gains 10x normal gold in an hour)
• Track vendor buy/sell patterns for circular trading exploits
• Detect and prevent negative-price exploits
• Cap maximum transaction values as a safety net

5.4 Defensive Design Principles

1. Server authority: All game logic runs server-side. The client is a display terminal, nothing more. In a telnet MUD this is natural; in a web-client MUD, resist the temptation to put logic in JavaScript
2. Atomic operations: Every state change (trade, combat round, item pickup) either fully succeeds or fully fails. No partial states
3. Idempotent commands: Processing the same command twice should not produce different results than processing it once
4. Audit logging: Log every economically significant action (trades, drops, pickups, purchases, sales). Storage is cheap; investigation without logs is expensive
5. Sanity checks: Periodic validation that the total currency in circulation matches expected values. If it doesn’t, something is wrong

6. Moderation and Governance

6.1 Admin Hierarchy

Traditional MUD admin structure (DikuMUD-derived):

Key principle: Separate content creation from moderation from technical administration. A great builder shouldn’t automatically have ban powers, and a coder shouldn’t be doing player relations.

6.2 Reporting Systems

• Bug command: bug <description> — logs directly to immortal review queue
• Typo command: typo <description> — low-priority content fixes
• Idea command: idea <description> — player suggestions
• Report command: report <player> <reason> — player misconduct reports
• Petition / pray: Direct message to online immortals for urgent issues

6.3 Punishment Ladder

Graduated punishment prevents over-reaction and establishes clear expectations:

Jail mechanics: Player is teleported to a restricted room. Cannot interact with the game world, use channels, or log out. Must wait for sentence to expire or petition an immortal. Serves as both punishment and cooling-off period.

MuDream example: Insults and swearing → 24-hour mute. Fake evidence or impersonating admin → 7-day to permanent ban. Nicknames similar to admin names → immediate permanent ban.

6.4 Logging

What to log (minimum):

• All administrative actions (who did what, when, to whom)
• All punishments with reasons
• Player reports and their resolution
• Economically significant events (large trades, unusual wealth changes)
• Login/logout with IP addresses
• Character creation and deletion

Transparency principle: Players should be told why they’re being punished. “You were jailed for 2 hours for using an illegal trigger. Contact [admin] if you believe this is in error.” Unexplained punishment breeds resentment and distrust.

6.5 Governance Models

From the Discworld MUD’s analysis of governance structures:

Most successful long-running MUDs use a hybrid: bureaucratic structure for routine operations (clear rules, defined roles) with an absolutist override for emergencies (imp can act unilaterally when needed). Player input through advisory channels, not direct governance.

LambdaMOO experiment: Moved to near-full egalitarian governance with elected mediators as judges and elected resource boards. Demonstrated that pure democracy works in theory but decision-making becomes painfully slow for a game that needs active administration.

7. Implications for an Urbit MUD

7.1 @p as Anti-Sybil

Urbit’s identity system is the single most important architectural advantage for a MUD on Urbit.

Traditional MUD problem: Creating accounts is free. Banned? Make a new account. Want to multi-play? Make ten accounts. Want to manipulate the auction? Create a dozen alts.

Urbit solution: Every player connects from a ship with a known @p. Planets cost real money (~$10-50). Comets are free but carry less reputation by default. Stars and galaxies are expensive and highly visible.

Anti-Sybil properties:

• Finite identity supply (4.29 billion planets max, but practically far fewer active)
• Each identity has economic cost to obtain
• Identities are persistent and carry reputation across the entire Urbit network
• Burning an identity (getting it banned) has real cost
• No need for email verification, CAPTCHAs, or IP tracking — the PKI handles identity

Design implications:

• Ban by @p, not by IP. A banned planet stays banned permanently
• Comet players could have reduced privileges (limited trading, no auction access) until they prove themselves
• Planet-level reputation: track player behavior across sessions, even if they change character names
• Star operators could vouch for their planets, creating a chain of accountability

7.2 Identity Tiers for Trust

This replaces the entire traditional anti-cheat identity stack (email verification, IP tracking, hardware fingerprinting, phone number verification) with a single cryptographic identity that has built-in economic cost.

7.3 Decentralized State Validation

Arvo’s guarantees that matter for a MUD:

• Deterministic computation: Given the same event log, any ship will produce the same state. This means game state can be verified independently
• Atomic events: State transitions either fully succeed or fully fail — no partial states, no database desync, no dupe bugs from interrupted transactions
• Event log: Complete history of every state change is preserved. Perfect audit trail for economy monitoring
• Kelvin versioning: The system is designed to freeze — once the game rules are set, they can’t be silently changed

Architecture choice: Run game state on a single host ship (star or galaxy) for consistency, with player ships connecting as clients. The host ship’s Arvo event log IS the game’s database — atomic, ordered, and deterministic. This eliminates entire categories of exploits:

• No simultaneous-login dupes (Arvo processes events sequentially)
• No database desync (single source of truth)
• No race conditions in state transitions (events are atomic)
• Full audit trail by default (event log)

7.4 Economy Design for Urbit

Recommended currency structure:

Why not premium currency?: On Urbit, the @p itself is the premium currency. Planets already cost money. Adding another paid currency layer feels redundant and against the ethos. Revenue model can come from hosting (star operator charges for game hosting) rather than microtransactions.

Inflation control:

• Track total gold supply on the host ship
• Dynamic drop rates based on total circulating gold (Alter Aeon model)
• Auction tax (5-10%) as primary sink
• Equipment repair costs as secondary sink
• Mandatory progression fees as tertiary sink

7.5 Moderation on a Decentralized Network

The tension: Urbit values sovereignty and censorship resistance. A MUD needs enforceable rules and admin authority.

Resolution: The game host ship IS the authority. Playing the game means connecting to someone’s ship and accepting their rules. This is no different from joining any Urbit group — the host sets the rules. Players who don’t like the rules can fork the game and run their own instance.

Admin model for Urbit MUD:

• Host ship operator = Implementor (has final authority over game state)
• Designated admin @p’s = Immortals (granted specific powers via Gall agent permissions)
• Player @p’s = Players (standard game access)
• Comet @p’s = Restricted players (limited trust tier)

Punishment mechanics:

• Mute: Remove from game chat channels (trivial in Urbit — just unsubscribe their ship)
• Jail: Move character to restricted room, limit commands
• Ban: Block @p from connecting to the game agent entirely
• Reputation mark: Flag @p’s behavior history — visible to other Urbit apps if shared

7.6 What Urbit Makes Easier

7.7 What Urbit Makes Harder

Sources

• Gold Sink — Wikipedia
• Mudflation — Muds Wiki
• Sinks & Faucets: Lessons on Designing Effective Virtual Game Economies — 1kx
• Aardwolf Triggers and Bots Policy
• Aardwolf Auction System — AardWiki
• Aardwolf Quest Points — AardWiki
• Aardwolf Marketplace — Aardwolf Blog
• Bots and Botting on Alter Aeon
• Credits — AchaeaWiki
• Credits — Achaea
• Payment FAQ — Iron Realms Entertainment
• Meet the man who invented microtransactions — PCGamesN
• On Item Duplication Exploits and How to Prevent Them — Munique
• Item Decay: Good, Bad, or Ugly? — MMORPG.com Forums
• Discworld MUD — MUD Governments
• Discworld MUD — Multiplay Allow
• Immortal — Muds Wiki
• Wizard (MUD) — Wikipedia
• I Designed Economies for $150M Games — Gamedeveloper.com
• The Urbit Address Space — Urbit Blog
• Arvo Overview — Urbit Developers
• Ames Security Audit — Urbit Blog
• Toward a Frozen Operating System — Urbit Blog
• Virtual Economy — Wikipedia
• MuDream Rules
• Apocalypse MUD Rules
• Valheru MUD Rules of Play