Vak's Store — Whitepaper

1. Abstract

Vak's Store is a community-run trading platform and experimental in-game economy operating on the Vintage Story TOPS server (The Official Public Server). It was built to address three persistent problems in the server's economic environment: barter friction, Rusty Gear (RG) inflation, and price opacity.

At its core, Vak's Store introduces EW (Exchange Weight) — an internal ledger currency that serves as a medium of exchange entirely outside the game's built-in systems. EW (Exchange Weight) is the current name for what older documentation called BT (Bartering Tokens). EW is used throughout this document.

The system operates across three layers: a static frontend served via Cloudflare CDN, a Cloudflare Worker acting as an edge proxy, and a Google Apps Script backend with Google Sheets as the data store. The frontend source code is open on GitHub. The backend is kept private for security, but its behavior is fully described in this document.

EW solves the inflation problem by tying every unit of currency to a real item exchange. New EW is only created when a player sells items to the store; EW is destroyed when players buy items or complete trades on the Open Community Market. The Bank Dashboard, which is publicly accessible without login, allows any visitor to observe the economy's health in real time: total EW in circulation, daily issuance and destruction, metal backing ratio, and wealth distribution.

2. Project Background

2.1 The Problem with Rusty Gears (RG)

Rusty Gears are the official in-game currency of Vintage Story. Their fundamental weakness is that they can be produced without limit using mob farms — automated constructions that kill enemies en masse and collect the RG they drop. A well-built mob farm can produce hundreds of RG per hour, with essentially zero player effort.

The effect on the economy is predictable: over a typical server wipe cycle, RG inflates significantly. A steel ingot that cost around 5–6 RG early in a wipe can cost 12–13 RG twelve months later — not because steel became harder to obtain, but because RG became worth less. Players who understand this stop holding RG and stop accepting it as payment. New players, who lack mob farms, find themselves unable to compete with veterans who can generate thousands of RG effortlessly.

RG is, in effect, a depreciating asset. Rational economic actors eventually refuse it, which makes it useless as a medium of exchange despite being the game's intended currency.

2.2 Barter Friction Before Vak's Store

Before Vak's Store existed, player-to-player trade required both parties to separately agree on the quantity of items to exchange, a mutually acceptable price, a time and place to meet, and — critically — that they trusted each other not to scam the deal. Each of these steps represented an opportunity for the trade to fall through.

Players live scattered across an enormous map. The common meeting point near coordinates 0,0 (the server spawn) is a long journey from most bases. Experienced players regularly exploited the price ignorance of newcomers, offering to "buy" items at a fraction of their actual value since no public price reference existed. This created an adversarial dynamic that discouraged trading, particularly for new players who had the most to gain from a functioning market.

2.3 Origins of Vak's Store and FSFTC

I started as a small seller near the center of the world. I noticed that I had more goods to offer than I could carry around, and that other players often needed exactly what I had — but finding each other and agreeing on a price was exhausting. The obvious solution was a permanent, always-open store.

As demand grew, I needed a way to accept almost any item as payment without requiring each trade to be individually negotiated. That need became EW: a ledger-based unit of value that players could earn by selling to me and spend by buying from me or from other players.

The company behind the store was originally called the Finnish Small Fox Trading Company (FSFTC). Over time, the community settled on a simpler name: Vak's Store. The store is located at approximately coordinates 300, 100 — a short walk from spawn, visible from the main transit paths. Every customer has their own deposit box (a personal mailbox in-game) where items are deposited and picked up without requiring the parties to be online simultaneously.

3. System Overview

Vak's Store consists of several interconnected components. Together they form a self-contained economy that operates alongside, but independently of, Vintage Story's built-in game mechanics.

3.1 The Store (Central Liquidity Provider)

The store maintains always-open buy and sell orders for hundreds of items. Prices are set by Vak and published on a public Google Spreadsheet (the price sheet). When a player sells items to the store, new EW is issued to their account. When a player buys items from the store, EW is destroyed. This creates a currency that is directly tied to the flow of real in-game goods.

Physical item flow works through in-game deposit boxes (mailboxes). Players deposit items they are selling and pick up items they have purchased, all at their personal deposit box. The store processes these requests as they come in; no real-time presence from either party is required.

3.2 OCM — Open Community Market

The Open Community Market (OCM) is a player-to-player trading layer built on top of the EW system. Any player can list items for sale at a price they set themselves, using one of two pricing modes: STORE mode (price pegged to the store's published prices) or HALF mode (a custom peg ratio). The fee structure depends on who handles the customer service for the trade. If the merchant accepts the trade directly from their OCM merchant panel (“Incoming pending requests (I am Merchant)”) and personally delivers the items to the customer’s deposit box, the fee is 0% — making OCM a free advertising and sales platform for the merchant. If instead the admin performs the customer service on the merchant’s behalf — physically moving items between deposit boxes and handling the logistics of the trade — a 10% fee is taken from the merchant’s EW account as the cost of that service, and that EW is destroyed, functioning as a deflationary sink. If the customer paid in items rather than EW (a peg-based payment), the merchant receives 100% of the full item quantity specified in the peg; no item deduction occurs. The 10% fee applies only to the EW side of a transaction, and only when the admin completes it on the merchant’s behalf.

Customers can also post buy requests, specifying both the item they want and the payout they are offering — either as a fixed EW amount (for example, 10 EW per Resin) or as items (for example, 3 Fat per Resin). This allows players to source items the store does not currently stock, and to negotiate payout terms that may be more attractive to gatherers than a straight EW offer.

3.3 EW Accounts and Transaction History

Every player has an EW balance stored in a secure backend ledger. Every balance change — whether from a store trade, an OCM transaction, a direct transfer, or an insurance operation — creates a permanent, immutable transaction history record. Players can view their complete history on the Account History page. Administrators can view any account for dispute resolution purposes.

3.4 Bank Dashboard

The Bank Dashboard is a fully public page that displays economy-wide metrics: total EW in circulation, daily EW issuance and destruction, metal backing ratio, store net worth, and wealth distribution across the player base (segmented as top 1%, next 9%, next 20%, and bottom 70%). All data is refreshed automatically each day by scheduled backend jobs. No login is required to view it.

3.5 EW Insurance

Players holding 500 or more EW can allocate units to a metals-backed reserve. One insurance unit costs 500 EW, and each player may hold up to five policies. Upon admin approval, the EW is converted to physical in-game metals (silver, gold, steel, and others) delivered to the player's deposit box. The long-term goal is to maintain total metal reserve value greater than total EW in circulation — a target that was achieved during the previous wipe cycle. The current wipe is rebuilding reserves as quickly as participation allows.

3.6 Tools and Supporting Pages

Several supporting tools accompany the core trading system. The Price History page charts buy and sell prices and trade velocity over time. The Work Pay Rates page lists publicly recommended wages for common in-game jobs. The Leaderboards page shows top traders by EW bought and sold, with each player controlling their own privacy (full name, anonymous alias, or opt-out). The Calculator on the main store page helps players compute individual vs. bundle pricing. The Instructions page explains how to use every part of the system.

4. EW Currency Design (Summary)

This section provides a conceptual overview of how EW works. Full formula derivations, worked examples, and detailed mechanics are documented on the Economy Specifications page.

4.1 Definition

EW is a ledger-based, non-physical unit of trade value. It does not exist as an item inside Vintage Story — it exists only as a balance in the Vak's Store backend ledger. EW can be transferred between players via direct P2P transfer and has no real-money value; it exists exclusively within the TOPS server ecosystem.

4.2 Issuance (EW Creation)

New EW enters the system when a player sells items to the store. For example, selling ten steel ingots at the current store buy price credits the seller's account with the corresponding amount of EW. Conceptually: the EW supply increases by the store's buy value of each approved transaction. No other mechanism creates EW; there is no "printing" from thin air.

4.3 Destruction (EW Removal)

EW leaves the system through two sinks. The first is store purchases: when a player buys items from the store, the corresponding EW is deducted and removed from circulation. The second is the OCM admin fee: 10% of the EW value of every completed OCM trade is destroyed. This dual-sink mechanism prevents the supply from growing without bound.

4.4 Liquidity Guarantee

Unlike barter or the game's built-in auction house, Vak's Store always maintains both buy and sell orders. A player can always convert goods into EW or EW into goods without needing a willing counterparty at that moment. This “always-open” property makes EW reliably spendable, which is the foundation of its value as a medium of exchange.

The store is also backed by the physical items it holds in stock. Because every store transaction includes a buy/sell spread, the total value of items available for purchase always exceeds the total EW in circulation. This means EW can always be exchanged for something of value as long as the store has any stock at all.

It is important to note that low metal reserves do not mean EW has lost value. EW can still be used to purchase all other items in the store. What low metal reserves mean is that metal prices are temporarily higher — and that higher price incentivizes players to gather and sell metals, which refills the reserves. Once reserves are restored, prices stabilize. This self-correcting mechanism makes EW fundamentally different from a single-commodity-backed currency: EW’s backing is diversified across every item the store trades, making it resilient to shortages in any one category.

4.5 Metal Backing / Insurance Reserve

When reserves are funded, each 500 EW can be redeemed for its equivalent value in physical in-game metals. The solvency goal is for the total metal value held in reserve to exceed the total EW in circulation. The Bank Dashboard tracks the backing ratio daily so the community can observe reserve health at any time. The reserves were fully funded during the previous wipe cycle; the current wipe is rebuilding them as quickly as possible.

4.6 Velocity and Daily Stats

The system tracks how much EW flows through the economy each day. Store velocity includes units bought and sold, unique traders, and trade count per item. OCM velocity includes items moved, fees collected, and unique participants. All data is archived daily by the price history subsystem and is visible on both the Price History and Bank pages.

5. Economic Principles

5.1 Medium of Exchange

EW is designed primarily as a medium of exchange, not as a savings instrument. The recommendation is to spend approximately what you earn, since holding large idle balances concentrates wealth in a way that runs counter to the system's intent. That said, many players do hold EW balances for convenience — it is easier to spend funds you already have than to liquidate goods on demand — and this is a normal and acceptable use.

5.2 Price Discovery

All store prices are fluid. They are reviewed and adjusted by Vak based on supply and demand relative to the target stock level for each item. The target stock level determines how much of that item the store wants to hold in reserve; when the target stock is reached, the store may stop accepting that item as a form of payment until stocks fall again. There is no fixed price anchor — prices reflect real economic conditions as they change.

OCM prices emerge from player-to-player negotiation and reflect supply and demand independently of the store’s current prices, providing a second layer of price discovery.

The Price History page shows historical price data and other statistics about how prices form and change over time. Players can use this to research fair prices before posting listings or submitting trade requests.

5.3 Accessibility

The store accepts almost all basic items, not only rare metals like gold or silver. This means a new player can begin trading immediately using common goods gathered in their first days on the server. This design choice directly counters the advantage that veteran players with mob farms hold over newcomers in the RG economy.

5.4 Wealth Transparency

The Bank Dashboard publishes the wealth distribution of the player base every day. The concentration of EW among the top 1%, next 9%, next 20%, and bottom 70% of players is tracked and publicly visible. This is an intentional design choice: economic power should be observable, not hidden.

5.5 Why EW Has Inflation and Deflation

EW has both inflation and deflation because all prices are fluid and determined by the market — that is, by supply and demand for each individual item. How much players buy or sell any given item drives the price of that item up (high demand or low supply) or down (high supply or low demand).

Price shocks can occur but are self-correcting: if an item becomes expensive, it incentivizes players to gather and produce more of it, increasing supply and eventually bringing the price back down. Conversely, selling too much of one item decreases its price, discouraging oversupply and naturally preventing any single item type from flooding the market.

The buy/sell spread between what the store pays and what it charges is intentionally wide enough that the OCM offers a significant advantage — players can earn considerably more selling on the OCM than selling directly to the store. This encourages active OCM participation and rewards players who find buyers directly.

Compared to RG trading (where players often have no reliable reference for fair prices), the EW system provides publicly accessible price history and trade data, allowing players to research fair prices and to be fairly compensated for their gathering and crafting work. EW is more stable than an infinitely printable currency like RG because its supply is bounded by real economic activity — but it is not perfectly stable, and its value relative to any given item changes with market conditions.

The diversity of items the store accepts means EW’s effective value is spread across the entire item economy, not dependent on any single commodity. This makes EW more robust to individual item price shocks than a single-commodity-backed currency would be.

6. Transaction System

The following sections describe each transaction type supported by Vak's Store, what triggers it, and its effect on the total EW supply.

6.1 Store Buy (Player Sells Items to Store)

A player submits a sell order via the website. The administrator reviews and approves the request, crediting EW to the player's account. The items are physically deposited into the player's deposit box. Effect on EW supply: increase (issuance event). Note that when the store receives items via a sell order, its item reserves increase by more in value than the EW that was issued — because the store’s sell price (what the store charges customers) is higher than its buy price (what it paid the seller). The buy/sell spread means the total backing value of items in stock always grows faster than the EW supply.

6.2 Store Sell (Player Buys Items from Store)

A player submits a buy order via the website. The administrator approves the request and delivers the item to the player's deposit box. The EW amount is deducted from the player's account. Effect on EW supply: decrease (destruction event).

6.3 P2P Transfer

A player sends EW directly to another player via the Account page. No items change hands through the system; it is a purely ledger-based balance transfer. Effect on EW supply: neutral (no creation or destruction).

6.4 OCM Trade

A merchant posts a listing; a customer sends a trade request. From that point two scenarios are possible depending on who handles customer service.

Scenario 1 — Merchant self-service (0% fee). The merchant accepts the trade directly from their OCM merchant panel (“Incoming pending requests (I am Merchant)”) and personally delivers the items to the customer’s deposit box. Both parties receive transaction receipts via the system. No fee is charged — OCM is free to use as an advertising and trading platform when the merchant handles their own delivery. Effect on EW supply: neutral (no fee, no destruction).

Scenario 2 — Admin-handled customer service (10% fee). The admin completes the trade and moves items between deposit boxes on behalf of the merchant. A 10% fee is deducted from the merchant’s EW account as the cost of that service, and that EW is destroyed. Effect on EW supply: decrease by 10% of the canonical EW value (destruction event).

Item-based payment. If the customer paid in items rather than EW (a peg-based payment), the merchant receives 100% of the item quantity agreed in the peg. No item deduction occurs for the fee — the fee applies only to the EW side of the transaction, and only in the admin-service scenario.

6.5 Insurance Deposit

A player requests to convert EW into a metals-backed insurance policy. The administrator approves; the EW is deducted and logged against the reserve. The player receives physical metals in their deposit box. Effect on EW supply: decrease (EW moves from circulating balance into reserve).

6.6 Insurance Withdrawal

A player requests to redeem insurance units back to EW. The administrator approves; EW is credited back to the player's balance. Effect on EW supply: increase (EW returns to circulation from reserve).

There is also a metal withdrawal option. Instead of redeeming insurance units back to EW, a player can choose to withdraw the physical metals directly. In this case, the admin delivers the metals to the player’s deposit box and the insurance policy’s EW is nullified — the EW that had been allocated to that policy is removed from the reserve entirely rather than returned to circulation.

This creates a natural price stabilizer for metals: if metal prices rise significantly, players are incentivized to withdraw their metal reserves and sell them at the higher price, increasing the supply of metals in the market and eventually bringing prices back down. As the store’s metal stock runs low, rising prices incentivize more gathering until reserves are refilled and prices stabilize. Effect on EW supply: decrease (EW is nullified, not returned to circulation).

7. Data Model (Conceptual)

The backend schema is kept private. This section describes the conceptual data model only — what information the system tracks, not the specific implementation details of how it is stored.

Players

Each player record stores a unique ID, their in-game player name, deposit box address (mailbox), current EW balance, leaderboard consent preference (full name, anonymous alias, or opt-out), and account status (active or deleted).

Transaction History

Every balance change generates a transaction history record containing a unique transaction ID, the transaction type (store buy, store sell, transfer, OCM trade, insurance deposit, and others), the EW delta (positive for credits, negative for debits), the balance after the transaction, and a timestamp. All records are permanent and immutable; nothing is ever deleted from the history.

Store Requests

Store request records capture the requesting player, the list of items with quantities and prices, the net EW amount, and a status field. Requests move through a lifecycle: PENDING → EXECUTED or DENIED.

OCM Listings

Each OCM listing records the merchant, the item being offered, quantity available, pricing mode (STORE or HALF), and current status. Status lifecycle: PENDING_REVIEW → ACTIVE → COMPLETED, PAUSED, or DELETED.

OCM Trades

When a customer sends a trade request, an immutable snapshot of all trade details is created at that moment and stored permanently. This snapshot includes both parties, the item, quantity, pricing, payment method, and fee rate. The immutable snapshot ensures that any dispute can always be resolved from the record, even if listings are later modified. Trade status lifecycle: PENDING → EXECUTED or DENIED.

Insurance Policies

Insurance policy records store the policy ID, owning player, number of units held, metal allocation percentages, and current activity state. Activity states: Empty → Active (funded) → Pending (during admin review) → Active or Empty.

8. Software Architecture (Summary)

The full architecture page will contain complete diagrams and module maps. This section provides a high-level overview. The backend source code is private.

8.1 Frontend

The frontend consists of static HTML pages and segmented JavaScript modules. It is hosted on vakstore.com and served via Cloudflare's CDN for global availability. The frontend source code is publicly available at:

📎 github.com/vilhoKettunen/Finnish-small-fox-trading-company

The backend source code is kept private for security reasons, but its behavior is fully documented in this whitepaper.

8.2 Authentication

Authentication is handled by Google Sign-In (GSI). Vak's Store stores no passwords. Google issues a secure id_token which the backend verifies on every request via Google's tokeninfo API. Player identity is tied to their Google account. This approach delegates credential management entirely to Google, significantly reducing the system's attack surface.

8.3 Edge Layer

A Cloudflare Worker acts as a proxy between the frontend and the backend. It provides routing, a stable public URL, and an optional caching layer. The frontend communicates exclusively with the Worker's URL; the backend Apps Script URL is not exposed directly to clients.

8.4 Backend

The backend is implemented as a Google Apps Script web app, written in server-side JavaScript. It is split into sixteen-plus modules handling authentication, users, balance management, store requests, OCM listings and trades, statistics, bank snapshots, insurance, work pay rates, and more. There are two separate Apps Script projects: the main backend and a price history subsystem that archives daily trade velocity data. The backend source code is not published on GitHub.

8.5 Data Storage

Google Sheets is used as a structured database. Separate spreadsheets handle users, transaction history, store requests, OCM listings, OCM trades, stock, insurance policies, bank snapshots, and more. All write operations go through backend validation; the frontend cannot write directly to any sheet.

9. Transparency and Data Integrity

Every balance change creates a permanent, uneditable history record. When an OCM trade is created, all details — both parties, item, quantity, pricing, and fee rate — are locked into an immutable snapshot. The agreed price and terms cannot be changed retroactively, which means any dispute can always be resolved from the original record.

When a player deletes their account, their personal data (specifically their email address) is cleared. However, the EW balance history and all transaction records are retained for economic integrity; removing them would make the history inaccurate and would compromise the audit trail.

The Bank Dashboard is fully public. Anyone — logged in or not — can observe the total EW in circulation, daily issuance and destruction, metal backing ratio, and wealth distribution. This openness is intentional: an economy that can be observed is an economy that can be trusted.

Leaderboards use a consent model. Players choose whether to appear under their full player name, an anonymous alias, or not at all. No one is forced into a public ranking.

10. Security Considerations

Authentication is provided by Google OAuth. No Vak's Store passwords exist; the system has no password database to compromise. The backend verifies every token server-side on every request; the frontend cannot spoof a player's identity.

All write operations — balance adjustments, stock changes, trade approvals — require administrator authorization. Players cannot self-approve their own requests. Rate limiting is applied to prevent abuse: there is a 60-second cooldown between consecutive store requests per player, and a 15-second cooldown between duplicate OCM trade sends to the same listing.

The backend source code is kept private to prevent exploitation of implementation details. Known limitations are acknowledged openly below.

Known limitations: The system is centralized; one person (Vak) approves all transactions, which introduces a single point of trust. Google Sheets write operations are not fully atomic, meaning that simultaneous writes can theoretically conflict (the code mitigates this but does not eliminate it entirely). Finally, physical item delivery relies on player trust: the system records that delivery must occur, but cannot enforce it in-game.

11. Limitations

Centralized approval. All store requests and OCM trades require admin sign-off. There is no smart contract or automated settlement. This keeps the system simple and flexible but means throughput is bounded by the administrator's availability.

Physical delivery. Items must be manually deposited and picked up at in-game deposit boxes. The system cannot automate in-game movement or item transfer; it can only record that delivery is expected and track when it has been confirmed.

Server-dependent. The EW economy exists only while the TOPS server is active and players are participating. A server wipe resets all in-game items. EW balances are handled separately per-wipe by Vak on a case-by-case basis, considering economy continuity and fairness.

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 whatsoever. It should be understood as a social experiment in in-game economics, not as a financial product.

12. Future Development Ideas

The following are development directions being considered for future wipe cycles or ongoing improvements.

Economy Specifications page. Detailed technical documentation of EW mechanics, including full formula derivations, pricing model design, and the OCM peg system. Work on this page begins immediately after the whitepaper is published.

System Architecture page. A full map of pages, JavaScript modules, and backend actions, with data flow diagrams for critical paths such as store request approval and OCM trade execution. Also beginning immediately.

Automated price signals. Using daily velocity data to algorithmically suggest store price adjustments when an item's trading volume indicates that the current price is out of step with actual demand.

Expanded OCM features. Auction-style listings, bundle trades, and multi-item buy requests to make the marketplace more expressive and useful for complex trading scenarios.

Public read-only API. Exposing a subset of economy data through public endpoints so that community-built tools and third-party scripts can integrate with Vak's Store without requiring backend access.

Inflation index. A composite price index tracking EW purchasing power over time across a basket of commonly traded goods, making the stability of EW quantitatively visible to players.