Economy Specifications

1. What EW Is (and Is Not)

1.1 Definition and scope

EW (Exchange Weight) is a ledger-based, non-physical unit of trade value. It has no in-game form in Vintage Story — it exists exclusively as a balance in the Vak's Store backend ledger (a Google Sheets database). EW cannot be transferred out of the TOPS server ecosystem and has no real-money value, ever.

The name "Exchange Weight" replaces the older name "BT" (Bartering Tokens) used in earlier documentation. The rename better reflects what the unit measures: the weight of an exchange, not a token of barter.

1.2 What problems EW solves

Problem 1 — Barter friction. Each barter trade required simultaneous agreement on quantity, price, meetup time, meetup location, and mutual trust. EW separates the sell-event from the buy-event: a player can sell items today, hold EW, and buy different items tomorrow — with no counterparty required at either moment.

Problem 2 — Rusty Gear (RG) inflation. RG is produced by mob farms with no economic cost, causing runaway devaluation over a wipe cycle. EW is only created when real items are exchanged with the store, tying the money supply to actual economic activity.

Problem 3 — Price opacity. Before EW, no public price reference existed. Experienced players exploited this to underpay newcomers. EW introduces a publicly posted buy/sell price sheet, public Price History charts, and the Bank Dashboard — giving every player the same information regardless of experience level.

1.3 Intended use cases

Primary: medium of exchange — facilitate trades between players.
Secondary: unit of account — compare item values across the economy.
NOT intended as: long-term savings vehicle, investment instrument, speculation target, or status symbol.

The recommendation is to spend roughly what you earn. Holding large idle balances concentrates wealth in a way that reduces the currency's effectiveness as a medium of exchange for the wider community. Holding a working balance for convenience, however, is accepted and common.

1.4 What EW is NOT

• Not a stablecoin: it has inflation and deflation (see Section 5).
• Not backed by a single commodity: its backing is diversified (see Section 7).
• Not a financial instrument: no real-money implications, ever.
• Not automated: all approvals require a human admin (see Section 9).

2. EW Issuance: How New EW Enters the Economy

2.1 The only issuance mechanism

New EW is created exclusively when a player sells items to the store. There is no other mechanism: no admin top-up, no faucet, no printing. Every unit of EW in circulation was issued in exchange for real in-game items physically delivered to the store.

2.2 Issuance formula

2.3 Worked example — selling Steel Ingots

2.4 What happens to stock

When a sell order is approved, the store's raw stock increases:

The store receives items at the sell price (what it will charge buyers later), while it paid the seller at the buy price. This spread is the foundation of the liquidity guarantee (see Section 7.2).

2.5 Effect on EW supply

This is an inflationary event — total EW in circulation increases.

3. EW Destruction: How EW Leaves the Economy

3.1 Sink 1 — Store purchases (player buys from store)

When a player buys items from the store, EW is deducted and removed from circulation permanently. It does not transfer to the store — it ceases to exist.

3.2 Sink 2 — OCM admin fee (10% on admin-handled trades)

When the admin completes an OCM trade on behalf of a merchant, a 10% fee is charged on the canonical EW value of the trade:

Backend note: canonicalEW is first rounded to 2 decimal places via round2_() before the fee is computed. Simplified here as ceil() for readability.

This feeEW is deducted from the merchant's balance and destroyed — it does not go to the admin or any other player. When a merchant self-services their trade (accepts and delivers personally), no fee is charged: feeEW = 0.

Cumulative effect: OCM fees act as a slow deflationary drain on EW supply.

3.3 Sink 3 — Insurance metal withdrawal (EW nullification)

When a player withdraws physical metals from an insurance policy instead of redeeming units back to EW, the EW allocated to that policy is nullified — destroyed rather than returned to circulation. This creates a natural price stabilizer for metals: when metal prices rise, players are incentivized to physically withdraw their reserves and sell the metals, increasing market supply and eventually bringing prices back down.

Effect on EW supply: decrease (EW permanently removed).

3.4 The dual-sink mechanism

Two independent sinks prevent unlimited supply growth:

• Sink 1 (store purchases) scales with demand for goods.
• Sink 2 (OCM fees) scales with trading activity volume.

Together they maintain a long-run equilibrium between issuance and destruction that is tied to real economic behavior, not a policy target.

3.5 Worked example — net supply change over one day

4. Store Pricing Model

4.1 Buy/sell spread

The store maintains a spread between what it pays sellers (buy price) and what it charges buyers (sell price):

This spread serves three purposes:

1. It ensures the total item value in stock always exceeds total EW in circulation (liquidity guarantee — see Section 7.2).
2. It incentivizes players to trade with each other through the OCM, where they can negotiate better rates than the store spread.
3. It provides the store's long-term operational margin.

4.2 Individual vs bundle pricing

Items are priced per full stack (bundle). Per-unit pricing is derived:

4.3 Algorithmic price adjustment

Each item has a configured price range (minimum and maximum sell price) and a target stock level. The sell price adjusts automatically based on current stock relative to the target, and the buy price is then derived from the sell price via a margin multiplier:

Where:

• sellPrice — what the store charges a buyer for the item
• buyPrice — what the store pays a seller for the item
• margin — a multiplier (0–1) that sets the buy price as a fraction of the sell price; configured per item by the admin
• maxPrice / minPrice — the upper and lower bounds of the sell price range; configured per item by the admin
• currentStockStacks — current stock measured in stacks (= individual units ÷ bundleSize)
• targetStockStacks — the stock level the store wants to maintain, in stacks

At stock = 0 (empty): sellPrice = maxPrice (store charges the most; sellers earn the most).
At stock = target (full): sellPrice = minPrice = maxPrice × margin (store charges the least; sellers earn the least).
Between 0 and target: sell price is linearly interpolated. Buy price always tracks sell price × margin.

The admin sets the price range (min/max) and the margin per item. The price engine applies the adjustment automatically after each approved transaction — no manual intervention is required after each trade.

4.4 Price locking at submission: the bulk trading incentive

When a player submits a trade request, the price is locked at the moment of submission — not at the moment of approval. This has an important consequence: large trades lock in a favorable price before the post-trade price adjustment takes effect.

After a big sell order is approved, the buy price drops (because stock increased). The seller already locked in the high price before that drop. The next seller gets less for the same goods. Similarly, a large buy order locks in a low price — after approval, sell prices rise (stock fell), but the buyer already secured the deal at the pre-adjustment rate.

This mechanism strongly incentivizes bulk trading: the first large trade in a cycle captures the best available price, and subsequent smaller trades operate at the adjusted (less favorable) rate. There is no explicit bulk discount — the incentive is structural, created by the price adjustment mechanics rather than a separate pricing tier.

5. EW Inflation and Deflation

5.1 Why EW has both

EW is not a fixed-supply or pegged currency. Its purchasing power relative to any individual item fluctuates with supply and demand for that item:

• High demand for item X → price of X rises (buying X costs more EW; selling X earns more EW).
• High supply of item X → price of X falls (selling X earns less EW; buying X costs less EW).

This is intentional: price signals direct player behavior, and player behavior is what creates the dynamic, self-correcting economy.

5.2 Price shock self-correction

If item X becomes expensive: players are incentivized to gather and produce more X → supply of X increases → price of X falls back toward equilibrium.

If item X becomes cheap (over-supplied): less incentive to gather X → supply naturally decreases → price rises back toward equilibrium.

The price adjustment system (Section 4.3) makes this self-correction automatic and near-instantaneous rather than requiring manual price reviews.

5.3 Why EW is more stable than RG

RG inflation is supply-driven: mob farms produce unlimited RG at zero economic cost, so the RG supply grows faster than demand regardless of player behavior. EW inflation is activity-driven: EW is only issued when a player sells real items. If no items are sold, no EW is created.

Key structural differences:

• EW supply is bounded by real economic activity.
• No "mob farm equivalent" for EW exists.
• Earning large amounts of EW requires bringing proportionally large amounts of goods to the market.

5.4 Wealth concentration risk

The Bank Dashboard tracks wealth distribution daily across four bands: top 1%, next 9%, next 20%, and bottom 70% of active players by EW balance. Concentrated wealth means a small number of players control most of the trade capacity — a known risk in any economy of any size. Publishing this data openly is an intentional design choice: it allows the community to observe whether concentration is worsening over time and to respond.

5.5 Comparison: EW vs RG vs informal commodity currencies

6. OCM Peg System

6.1 What a peg is

An OCM listing's peg defines how a customer can pay for an item using goods instead of EW. The peg specifies the peg item (what the customer pays with, e.g. Fat, Resin, Copper Ingots) and the peg quantity (how many units of the peg item are required per unit of the listed item).

The peg converts an item-for-item trade into the EW accounting system so that the canonical EW value can be computed, the fee (if any) can be charged correctly, and both parties receive accurate transaction history.

6.2 STORE mode

The listing price is pegged to the store's published price for the peg item. The merchant chooses which side of the store's price to use:

Where side is either BUY or SELL, chosen by the merchant at listing creation. Store mode listings automatically reprice if the store's price sheet is updated before the trade is submitted. Once the trade request is submitted, the price is locked in the immutable snapshot.

6.3 HALF mode

The merchant sets a custom peg ratio (pegQtyPerInd) — how many units of the peg item a customer pays per individual unit of the listed item.

HALF mode listings do not automatically reprice. The merchant controls the exact exchange ratio regardless of store price changes.

6.4 Multi-peg configuration

A listing can have one primary peg and up to 10 alternate pegs, for a maximum of 11 accepted payment items. (Backend: validatePegsAndNormalize_() throws if altPegs.length > 10.)

Example: a merchant can accept Fat, or Resin, or Copper Ingots, or direct EW payment — all on the same listing. The customer selects which peg to use when submitting the trade request.

6.5 selectedPegEW vs canonicalEW

canonicalEW is the EW-equivalent value at primary peg store prices. It is used for: fee calculation, merchant balance credit, and transaction records.
selectedPegEW is the EW-equivalent value of the customer's chosen peg. It may differ from canonicalEW if the customer chose an alternate peg with a different store price, or if prices have shifted since the listing was created.

The immutable trade snapshot locks both values at the moment the trade request is submitted, protecting both parties from price changes during the approval window.

6.6 Item quantity rounding

When the customer pays in items, the quantity is always rounded up to the nearest whole integer — you cannot pay with a fractional item:

This protects the merchant from receiving less than the agreed quantity.

6.7 Fee calculation

The fee is charged to the merchant and destroyed — it does not go to the admin. It is always computed from canonicalEW (the primary peg value), regardless of which peg the customer chose to pay with. Item-based payments are never subject to a deduction: if the customer pays in items, the merchant receives 100% of the agreed item quantity. Only the EW equivalent is used to compute and charge the fee.

6.8 Worked example — STORE mode trade with Fat peg

7. Liquidity Guarantee and Metal Backing

7.1 The liquidity guarantee

The store maintains both buy AND sell orders at all times: a player can always sell items to the store (receive EW), and a player can always spend EW at the store (receive items). No willing counterparty is required at the moment of exchange. This is the fundamental property that makes EW a reliable medium of exchange.

Contrast with barter: both parties must want what the other has, at the same time, and must agree on a price. Contrast with RG: RG-based stores do exist on TOPS, but they are vulnerable to exploitation because RG itself inflates — any player with a mob farm can generate enough RG to strip a store of its inventory at the originally posted prices.

7.2 Why the store's item value exceeds EW in circulation

Every time a sell order is approved:

Because the spread is always positive, the store accumulates more item value than EW it issues. Over time:

This means EW can always be exchanged for something of real in-game value as long as the store has any stock at all.

Additional nuance: the spread varies by item, and the post-trade price adjustment changes how much the store effectively earns per transaction. In the worst case — if a single large transaction moves the stock from 0 to the full target — the store may end up paying out close to what it will eventually sell the goods for, making little margin on that particular trade. In better cases, many small transactions accumulate a larger effective spread before prices converge.

7.3 Metal backing and the insurance reserve

A portion of the store's reserves are held specifically as precious metals: Silver, Gold, Steel, Copper, Iron, Tin, Zinc, Bismuth, Nickel, Lead, and Meteoric Iron. These metals serve as the redemption asset for EW insurance policies.

When this goal is met, the system can in theory redeem all EW in circulation for metals simultaneously — surviving a full "bank run" scenario. This goal was achieved during the previous wipe cycle. The current wipe is rebuilding reserves as quickly as player participation allows.

7.4 Why low metal reserves do NOT mean EW has lost value

EW is backed by the full diversified stock of all items the store trades, not just metals. Low metal reserves mean metal prices are temporarily high (supply low relative to demand), which incentivizes players to gather and sell metals. Once reserves refill, metal prices stabilize.

EW can still be spent on all non-metal items even when metal reserves are low. Diversified backing makes EW resilient to shortages in any single item category — a structural advantage over single-commodity-backed systems.

7.5 Insurance: how EW converts to metals

When a player deposits into an insurance policy, the backend computes exactly which metals and quantities they receive. (Backend function: ins_calcMetalsForEW_())

Inputs:

• ewAmount = total EW being insured (units × INS_EW_PER_UNIT, where INS_EW_PER_UNIT = 500)
• allocObj = allocation percentages per metal (must sum to ≤ 100%)
• priceItems = live metal prices from the public price sheet

Special case: Meteoric Iron uses a nugget ratio of 2 nuggets per ingot. All other metals use the standard ratio of 20 nuggets per ingot.

The totalLeftoverEW is returned to the player's circulating EW balance — it is not lost. It arises because item quantities must be whole numbers (you cannot receive 2.7 ingots).

7.6 Insurance policy lifecycle (state machine)

  ┌─────────┐
│  Empty  │
  └────┬────┘
     │ set allocation (immediate — no admin approval)
       ▼
  ┌──────────────────────┐
  │  Empty (ready)       │
  └──────────┬───────────┘
         │ requestDeposit → admin approves
         ▼
  ┌──────────────────────┐
  │   Active (funded)    │◄────────────────────────────┐
  └──────────┬───────────┘          │
             │           │
    ┌────────┼────────────────────┐             │
    │    │        │       │
    ▼    ▼         ▼ │
requestWi- updateAlloc-      requestWithdraw-         │
thdrawUnits ation          Metals          │
    │        │ → REALLOC         │    │
    │        │   Pending │          │
    │        │   → admin   │   │
  │        │   approves    │             │
    │        ▼     ▼             │
    │  Active (realloc-  Empty (EW nullified —│
    │  ated)    metals delivered,          │
    │     │         not returned)      │
    │        └────────────────────────────────────────┘
    │
    ▼ admin approves withdrawal
  ┌───────┐   ┌───────────────────────────┐
  │ Empty │    or    │ Active (partial withdrawal │
  └───────┘       │ remains) │
      └───────────────────────────┘

Key rules:

• 1 unit = 500 EW (INS_EW_PER_UNIT constant in backend)
• Maximum 5 policies per player
• Allocation percentages must sum to ≤ 100%
• Unallocated remainder (100% − sum of allocations) is returned to the player's circulating EW balance when any EW is redeemed
• Admin actions bypass the Pending step (direct deposit/withdraw/realloc)
• Up to 5 independent policies with different allocations can be held simultaneously

8. Research Context: What This Economy Is Studying

8.1 Research framing

Vak's Store is not just a trading tool — it is an ongoing study of small-scale player-driven economics. The system was built with observability as a first principle: every transaction is logged, every balance change is recorded, and aggregate economy-wide metrics are published daily. This section documents what the study is measuring and what has been observed so far.

8.2 Research questions being studied

The system continuously collects data relevant to the following questions:

• Can a non-inflationary currency operate sustainably in a multiplayer game environment where the official currency is inflationary?
• Do players naturally gravitate toward a stable medium of exchange when one is available, or do they default to barter?
• How does public price transparency affect trading behavior? Do players trade more fairly when prices are observable by everyone?
• Does wealth concentration emerge over time even in a small economy? (Gini-coefficient equivalent for a 30–100 player economy.)
• Can a one-person, admin-operated store function as a central bank analog: issuing currency, setting prices, and maintaining reserves?
• How do players respond to price signals? When a price rises, do they gather more of that item, as the self-correction mechanism predicts?

8.3 Observable findings (current and previous wipe cycles)

The store has attracted consistent participation from both new and veteran players. Veterans with mob farms do participate and can trade at large volumes, but they don't dominate EW acquisition — the store accepts a wide range of items, and many players earn EW through crafting, gathering, or farming items that have nothing to do with mob drops. That's been one of the more pleasant surprises: the breadth of participation has stayed healthy even as a few high-volume traders have emerged.

Price history charts confirm supply-and-demand behavior: over-supplied items drop in price; under-supplied items rise. The insurance system saw meaningful uptake during the previous wipe, with total metal reserves exceeding total EW in circulation — the solvency goal was achieved. Wealth distribution data shows moderate concentration consistent with typical small-economy distributions, without extreme outliers dominating.

8.4 Limitations of the research

The sample size is small — 30–100 active players per wipe — nowhere near statistically significant by any academic standard. There's an observer effect: players know they're participating in a designed system, which probably affects how they behave. There's a single point of trust (one admin handles all approvals), which introduces both a bottleneck and a potential source of bias. There's no control group, no EW-free version of the same server to compare against. And each server wipe resets the economy, which disrupts any attempt at long-run continuity.

The research is informal. No institutional review, no academic publication. This is a community project that happens to collect economically interesting data. (For now.)

8.5 Comparison to academic small-scale economy research

Several academic studies have investigated player-driven economies in games including Eve Online, Runescape, and Ultima Online. Key comparisons:

Similarities: spontaneous price discovery, occupational specialization, and wealth concentration emerge in all of these systems.

Differences: EW is not tradeable outside the system (no real-money speculation or external arbitrage), the market size is much smaller, and the "central bank" (Vak) has a direct personal relationship with all market participants — a condition not present in larger game economies.

8.6 What would falsify the EW model

The EW model would fail — in an economically interesting way — if:

• Players collectively stopped trusting EW as a medium of exchange, reverting to barter despite EW being available.
• Admin availability dropped to the point where trade throughput collapsed and EW became effectively unspendable.
• A mechanism was discovered to generate EW without delivering real items — the equivalent of a mob farm applied to the currency system.

None of these failure modes have occurred. The system has functioned as designed across multiple wipe cycles.

9. Limitations

9.2 No in-game enforcement. The system records that item delivery must occur and tracks confirmation. It cannot force delivery in-game. If a player picks up items without fulfilling their end of a trade, resolution depends on admin action (balance clawback) and community trust.

9.3 Google Sheets concurrency. Write operations on Google Sheets are not fully atomic. Simultaneous writes to the same row can theoretically conflict. The backend mitigates this with LockService but does not completely eliminate the risk under extreme concurrency.

9.4 Price adjustment lag on manual items. While the price adjustment formula is algorithmic (Section 4.3), the spread itself (min/max) is set manually per item by Vak. Setting the spread for a new item or revising it for an existing item requires manual intervention. Items with an outdated spread may not respond correctly to real market conditions.

9.5 Insurance reserves are rebuilding. The solvency goal (metal reserves ≥ EW in circulation) was met in the previous wipe cycle. The current wipe started from zero and is rebuilding. Until the goal is met, not all EW can be simultaneously redeemed for metals.

9.6 Wipe dependency. The EW economy exists only while the TOPS server is active and players are participating. Each server wipe resets all in-game items. EW balances are handled per-wipe at Vak's discretion, with fairness and continuity considered. There is no guaranteed balance rollover between wipes.

9.7 Experimental scope. Vak's Store is a community project run by one person. It is not a regulated financial system and has no real-money implications. It should be understood as a social experiment in in-game economics, not as a product or service.

10. Full Transaction Type Reference

Quick-reference table for all transaction types, their EW supply effect, and the backend event that triggers each one.