Autonomous AgentsMetaverse439 lines
Virtual Economy Design
Quick Summary18 lines
This skill covers designing, implementing, and balancing economic systems within virtual worlds and metaverse platforms. It addresses currency design, marketplace mechanics, pricing strategies, inflation control, player-driven economies, digital asset ownership, and the regulatory landscape around virtual goods and currencies. ## Key Points 1. Never let hard currency buy gameplay advantages (pay-to-win) 2. Soft currency should always be earnable through play 3. Hard currency items should be cosmetic or convenience 4. Provide clear value proposition for hard currency purchases 5. Conversion ratio (soft → hard) should not exist or be very expensive 1. Fixed Pricing (developer-set): 2. Player-Set Pricing (marketplace): 3. Auction Pricing: 4. Dynamic Pricing (algorithm-adjusted): 1. Consumables that are genuinely useful 2. Cosmetic items from NPC vendors 3. Transaction taxes
skilldb get metaverse-skills/virtual-economy-designFull skill: 439 linesPaste into your CLAUDE.md or agent config
Virtual Economy Design
Purpose
This skill covers designing, implementing, and balancing economic systems within virtual worlds and metaverse platforms. It addresses currency design, marketplace mechanics, pricing strategies, inflation control, player-driven economies, digital asset ownership, and the regulatory landscape around virtual goods and currencies.
Economy Architecture
Types of Virtual Economies
Economy Models:
┌──────────────────┬───────────────────────────────────────┐
│ Model │ Characteristics │
├──────────────────┼───────────────────────────────────────┤
│ Closed economy │ Currency earned and spent in-world │
│ │ No real-money exit (e.g., most MMOs) │
├──────────────────┼───────────────────────────────────────┤
│ Semi-open │ Real money → virtual currency (buy) │
│ │ No virtual → real money (no cashout) │
│ │ (e.g., Fortnite V-Bucks) │
├──────────────────┼───────────────────────────────────────┤
│ Open economy │ Bidirectional exchange possible │
│ │ Virtual goods have real-money value │
│ │ (e.g., Second Life Linden Dollars) │
├──────────────────┼───────────────────────────────────────┤
│ Token-based │ Blockchain tokens as currency │
│ │ NFTs for asset ownership │
│ │ Decentralized exchange │
│ │ (e.g., Decentraland MANA) │
└──────────────────┴───────────────────────────────────────┘
Dual Currency Design
Most successful virtual economies use two (or more) currency types:
Dual Currency Pattern:
┌──────────────────┬──────────────────┐
│ Soft Currency │ Hard Currency │
├──────────────────┼──────────────────┤
│ Earned in-world │ Purchased with │
│ (quests, sales, │ real money │
│ activities) │ │
├──────────────────┼──────────────────┤
│ Abundant supply │ Scarce/controlled│
├──────────────────┼──────────────────┤
│ Buys common items│ Buys premium, │
│ │ cosmetic, or │
│ │ convenience items│
├──────────────────┼──────────────────┤
│ Can be inflated │ Stable value │
│ (more play = │ (pegged to real │
│ more currency) │ currency) │
├──────────────────┼──────────────────┤
│ Not convertible │ One-way purchase │
│ to hard currency │ (real → virtual) │
└──────────────────┴──────────────────┘
Design Rules:
1. Never let hard currency buy gameplay advantages (pay-to-win)
2. Soft currency should always be earnable through play
3. Hard currency items should be cosmetic or convenience
4. Provide clear value proposition for hard currency purchases
5. Conversion ratio (soft → hard) should not exist or be very expensive
Currency Flow Diagram
Sources (Faucets) Sinks (Drains)
───────────────── ───────────────
Quest rewards ──────┐ ┌──── Item purchases
Activity rewards ───┤ ├──── Repair/maintenance costs
Selling to NPCs ────┤ ├──── Transaction fees/taxes
Login bonuses ──────┤ ├──── Consumables (used up)
Achievement prizes ─┤ ├──── Crafting material costs
▼ ▼
┌────────────────┐
│ Player │
│ Wallet │
│ Balance │
└───────┬────────┘
│
Player-to-Player
Trading/Marketplace
(Currency circulates,
not created/destroyed)
Balance Rule:
Total faucets ≈ Total sinks (over time, per player)
If faucets > sinks → Inflation (prices rise, currency worthless)
If sinks > faucets → Deflation (new players can't afford anything)
Marketplace Design
Marketplace Architecture
Marketplace System Components:
┌─────────────────────────────────────────────┐
│ Frontend │
│ ├── Browse/search listings │
│ ├── Item detail pages │
│ ├── Purchase flow │
│ ├── Seller dashboard │
│ └── Price history/analytics │
├─────────────────────────────────────────────┤
│ Matching Engine │
│ ├── Order book (buy/sell orders) │
│ ├── Auction system (timed bidding) │
│ ├── Fixed-price listings │
│ └── Price suggestion algorithm │
├─────────────────────────────────────────────┤
│ Transaction Engine │
│ ├── Escrow (hold funds during trade) │
│ ├── Atomic swap (item ↔ currency) │
│ ├── Fee calculation │
│ ├── Tax/sink application │
│ └── Transaction logging/receipts │
├─────────────────────────────────────────────┤
│ Safety Systems │
│ ├── Price floor/ceiling guards │
│ ├── Rate limiting (anti-manipulation) │
│ ├── Fraud detection │
│ ├── Dispute resolution │
│ └── Rollback capability │
└─────────────────────────────────────────────┘
Pricing Strategies
Item Pricing Approaches:
1. Fixed Pricing (developer-set):
├── Simple, predictable
├── Good for consumables and standard items
├── Requires manual rebalancing over time
└── Risk: Price becomes misaligned with player value perception
2. Player-Set Pricing (marketplace):
├── Sellers choose listing price
├── Market finds equilibrium
├── Requires sufficient liquidity (many buyers/sellers)
└── Risk: Price manipulation, undercutting races
3. Auction Pricing:
├── English auction: Ascending bids, highest wins
├── Dutch auction: Descending price until someone buys
├── Sealed bid: Everyone bids once, highest wins
└── Best for rare/unique items
4. Dynamic Pricing (algorithm-adjusted):
├── Price changes based on supply/demand
├── More purchases → price increases
├── Less demand → price decreases
└── Good for NPC vendors to control inflation
Dynamic Pricing Formula:
price = base_price * (1 + demand_modifier)
demand_modifier = (recent_purchases - target_rate) / target_rate
Clamp demand_modifier to [-0.5, +2.0] to prevent extremes
Transaction Fee Design
Fee Structures:
├── Flat fee: Fixed amount per transaction
│ └── Simple, predictable, regressive on high-value trades
├── Percentage fee: % of transaction value
│ └── Scales with value, standard in real markets
├── Tiered fee: Lower % for higher-volume sellers
│ └── Encourages active participation
└── Listing fee: Cost to list item for sale
└── Prevents spam listings, creates sink
Recommended Approach:
├── Listing: Free (or very cheap soft currency)
├── Sale commission: 5-10% of sale price
│ ├── 3-5% to platform (currency sink)
│ └── 2-5% tax (additional currency sink)
├── Cancellation: Free (don't punish listing)
└── Gifting: No fee (encourage social behavior)
Inflation Control
Monitoring Metrics
Economy Health Indicators:
├── CPI (Consumer Price Index):
│ └── Track average price of a basket of common items over time
│ └── Rising CPI = inflation; target: stable or slight increase
├── Money Supply:
│ └── Total currency in circulation across all players
│ └── Monitor growth rate; should match player base growth
├── Velocity of Money:
│ └── How quickly currency circulates (transactions per period)
│ └── High velocity + high supply = inflation
├── Gini Coefficient:
│ └── Wealth distribution inequality (0 = equal, 1 = all to one)
│ └── Target: 0.3-0.6 (some inequality is natural, too much is toxic)
├── New Player Purchasing Power:
│ └── Can new players afford basic items within reasonable playtime?
│ └── If declining over time, economy is unhealthy
└── Active Listings / Sold Ratio:
└── If listings >> sales, prices are too high or demand is low
Anti-Inflation Mechanisms
Currency Sinks (ordered by effectiveness):
1. Consumables that are genuinely useful
└── Potions, fuel, repair kits, entry fees
2. Cosmetic items from NPC vendors
└── Regularly release new desirable cosmetics
3. Transaction taxes
└── Small % on every marketplace sale
4. Maintenance/upkeep costs
└── Housing maintenance, vehicle fuel, equipment decay
5. Gambling/chance mechanics (ethically designed)
└── Mystery boxes, crafting chance (disclose odds)
6. Limited-time events
└── Seasonal items that cost significant currency
7. Prestige systems
└── Expensive titles, badges, privileges
Emergency Inflation Controls:
├── Increase sink rates temporarily
├── Release high-value limited items
├── Reduce faucet output (lower quest rewards)
├── Introduce new currency tier
└── Nuclear option: Currency reset (extremely unpopular)
Digital Asset Design
Item Rarity Framework
Rarity Tiers (standard model):
┌──────────┬────────────┬───────────────────────────┐
│ Tier │ Drop Rate │ Design Purpose │
├──────────┼────────────┼───────────────────────────┤
│ Common │ 60-70% │ Functional basics │
│ Uncommon │ 20-25% │ Slight visual distinction │
│ Rare │ 8-12% │ Notable, desirable │
│ Epic │ 3-5% │ Status symbol │
│ Legendary│ 0.5-1% │ Prestigious, memorable │
│ Unique │ 1 exists │ Historic, event-specific │
└──────────┴────────────┴───────────────────────────┘
Rarity should affect:
✓ Visual distinctiveness (more elaborate appearance)
✓ Customization options (more color slots, effects)
✓ Social signaling (prestige, achievement)
✗ NOT gameplay power (avoid pay-to-win)
✗ NOT access to content (avoid paywall frustration)
Crafting Economy
Crafting System Economics:
┌─────────────┐ ┌─────────────┐ ┌──────────────┐
│ Raw Material│────→│ Intermediate│────→│ Finished │
│ (gathered) │ │ (processed) │ │ (usable/sell)│
└─────────────┘ └─────────────┘ └──────────────┘
Value: Low Value: Medium Value: High
Design Principles:
1. Crafting should add value (output worth more than inputs)
2. But not too much (or gathering becomes pointless)
3. Failure chance creates additional sink (materials consumed)
4. Specialization rewards depth (master crafter bonus)
5. Recipes as rare drops create their own economy
6. Time investment should be meaningful but not abusive
Value Ratio Guidelines:
├── Input materials cost: 40-60% of output value
├── Crafter profit margin: 20-30%
├── Material loss from failures: 10-20%
└── This encourages: gathering, crafting, and trading all stay viable
Regulatory and Ethical Considerations
Legal Landscape
Regulatory Areas to Address:
├── Gambling Regulations:
│ ├── Loot boxes may be classified as gambling in some jurisdictions
│ ├── Belgium, Netherlands: Paid loot boxes banned
│ ├── China, Japan: Must disclose odds
│ └── Best practice: Always disclose probabilities
├── Virtual Currency Regulations:
│ ├── If convertible to real money → potential money transmitter
│ ├── Tax implications for players earning real value
│ ├── KYC/AML requirements for open economies
│ └── Age restrictions for purchases
├── Consumer Protection:
│ ├── Right to refund (varies by jurisdiction)
│ ├── Clear pricing and terms
│ ├── No deceptive practices (dark patterns)
│ └── Data privacy for transaction history
└── Digital Ownership:
├── Terms of Service define ownership rights
├── Account termination and asset fate
├── Inheritance of digital assets
└── Platform shutdown obligations
Ethical Design
Ethical Economy Design Principles:
1. Transparency: All odds, fees, and mechanics clearly communicated
2. No predatory monetization: No targeting vulnerable users
3. Spending limits: Allow users to set their own spending caps
4. No pay-to-win: Purchased items should not confer gameplay advantages
5. Earn-ability: All meaningful content achievable through play
6. Fair pricing: Prices should reflect genuine value
7. No artificial scarcity manipulation: Don't fake "only 3 left!"
8. Respectful of time: Don't design systems to waste time to push purchases
9. Child safety: Extra protections for platforms with minors
10. Exit rights: Users should be able to leave without losing everything
Implementation Architecture
Database Schema
-- Core economy tables
CREATE TABLE currencies (
id UUID PRIMARY KEY,
name VARCHAR(50) NOT NULL, -- "Gold", "Gems"
type VARCHAR(20) NOT NULL, -- "soft", "hard"
decimal_places INT DEFAULT 0
);
CREATE TABLE wallets (
user_id UUID NOT NULL,
currency_id UUID NOT NULL,
balance BIGINT NOT NULL DEFAULT 0, -- Use integers, not floats
PRIMARY KEY (user_id, currency_id),
CHECK (balance >= 0) -- Prevent negative balances
);
CREATE TABLE transactions (
id UUID PRIMARY KEY,
timestamp TIMESTAMPTZ NOT NULL DEFAULT NOW(),
type VARCHAR(30) NOT NULL, -- "purchase", "reward", "trade", "fee"
from_user_id UUID, -- NULL for system-generated
to_user_id UUID, -- NULL for sinks
currency_id UUID NOT NULL,
amount BIGINT NOT NULL,
reference_type VARCHAR(50), -- "quest", "marketplace", "shop"
reference_id UUID,
metadata JSONB
);
CREATE TABLE marketplace_listings (
id UUID PRIMARY KEY,
seller_id UUID NOT NULL,
item_id UUID NOT NULL,
quantity INT NOT NULL DEFAULT 1,
price_currency_id UUID NOT NULL,
price_amount BIGINT NOT NULL,
status VARCHAR(20) DEFAULT 'active', -- active, sold, cancelled, expired
listed_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
expires_at TIMESTAMPTZ,
sold_at TIMESTAMPTZ,
buyer_id UUID
);
-- CRITICAL: All balance changes via transactions
-- Never directly UPDATE wallet.balance
-- Use serializable transactions or advisory locks
Transaction Safety
Transaction Processing Rules:
1. ACID compliance — Every trade must be atomic
2. Double-entry bookkeeping — Every debit has a matching credit
3. Idempotency — Retrying a transaction doesn't double-spend
4. Audit trail — Every balance change logged with reason
5. Rate limiting — Prevent transaction flooding
6. Validation — Check balance before debit, item ownership before transfer
Atomic Trade Example:
BEGIN TRANSACTION;
-- Verify buyer has funds
SELECT balance FROM wallets WHERE user_id = buyer AND currency_id = gold
FOR UPDATE; -- Row lock
-- Verify seller owns item
SELECT owner_id FROM items WHERE id = item_id
FOR UPDATE; -- Row lock
-- Transfer funds
UPDATE wallets SET balance = balance - price WHERE user_id = buyer;
UPDATE wallets SET balance = balance + (price - fee) WHERE user_id = seller;
UPDATE wallets SET balance = balance + fee WHERE user_id = system_sink;
-- Transfer item
UPDATE items SET owner_id = buyer WHERE id = item_id;
-- Log transaction
INSERT INTO transactions (...) VALUES (...);
COMMIT;
When to Apply This Skill
Use this skill when:
- Designing a virtual economy for a metaverse platform
- Building a marketplace for player-to-player trading
- Implementing currency systems and transaction processing
- Diagnosing and fixing inflation in a virtual economy
- Evaluating monetization strategies for ethical compliance
- Planning digital asset ownership and rarity systems
Install this skill directly: skilldb add metaverse-skills