From Christopher Kaczmarczyk-Smith

Introduction

In the next Star Atlas Quarterly Report, we’re going to report on GDP for the first time. It’s a metric we’ve been thinking about for a while but never felt the game was developed enough to report. Now, however, we have a vibrant labor market where players are extracting resources, transporting them, scanning for special items in deep space, and crafting final goods to go towards upgrading Starbases which rewards them with in-game currency ATLAS. Don’t get me wrong, it’s no EVE online killer but we have seen some of the highest marketplace trade volume in all of web3 (between 2 and 5 million depending on the month).

The question arises — how do you calculate GDP in a virtual economy? We all know the classic GDP = C+I+G+Nex from ECON 101. In my opinion, with the advent of virtual worlds, especially those for which we have information on each and every single transaction that ever occurs, we have an opportunity to redefine GDP. Or at least, re-calculate GDP. We’ll be measuring all the same stuff, but in a slightly different way. Our objective is to answer the following question under the condition:

How much value was generated in this virtual world over a specific period of time? Don’t double count, and count in the most efficient way possible.

In this brief article, I’ll summarize the method we use at Star Atlas for accounting GDP. We call it the Cost Accounting method and it is efficient —

Cost Accounting GDP

I call the method cost accounting because it quite simply measures all of the costs associated with directly creating something in a virtual world. In gaming, we call this a “sink”. In virtual economies, measuring the value of final goods sold is actually difficult because virtual businesses (i.e., players) aren’t required to file 10Ks. Suppose a sword is created and sold on the marketplace. Once the sword trades hands a few times, it’s very difficult to say which trade was the “primary” trade or the trade that resulted from it’s creation and contributes towards GDP. One could measure the value of the very first trade of an item, that’s true. But in a world where most items are non-unique (SFTs in web3 games or items in traditional games), this becomes tedious.

Thus, the Virtual GDP function we use is:

𝑉𝐺𝐷𝑃=𝑆𝑖𝑛𝑘𝑠+𝐹𝑒𝑒𝑠+𝑃𝑟𝑖𝑚𝑎𝑟𝑦𝑆𝑎𝑙𝑒𝑠

Where sinks are the market price times quantity of inputs to create a good, Fees are those fees paid by anyone to the game developer (or virtual world owner, this can be a DAO), and Primary Goods is the price players pay for anything sold directly by the game developer or DAO. Some economies will lack one or more of these items, but every game/virtual world will have at least one of these three.

Prices are discovered through the free market and determine heavily how large Sinks will be. Fees can range from enforced fees in-game to marketplace transaction fees paid to the dev or DAO. Finally, the equation also accounts for simple single player economies through PrimarySales. For example, a F2P game’s GDP is revenue the studio made from IAP and Ads. These are amounts paid directly to the dev in exchange for the experience.

Explanation

The cost accounting method simply takes the market value of all inputs used to create the sword and uses those as a proxy for it’s value. Since game worlds are very efficient (nearly perfectly competitive), this is actually a pretty good proxy for sale price. Furthermore, in a virtual world we don’t need a bunch of complex proxies (C, I, G, NEX) to calculate how much was generated. We can directly measure the value that was generated by the economy. We do this through costs. The costs method assumes that players don’t spend more on producing something than they get out of it, or at least not on average.

The beautiful thing about virtual economies is we know exactly what is produced and GDP is quite literally Gross Domestic Product. The traditional GDP equation is taking a bunch of proxies to try and get at the gross domestic product. Government spending is a proxy for taxes taken from income. In the context of games, we can add in any fees spent by the players into the GDP equation quite easily. Investment is a proxy for the amount of value re-invested into one’s production that’s pulled from earnings. And NEX is simply all the stuff that didn’t show up in the Nielsen Database because it wasn’t purchased domestically (it was exported).

Important Edge Case: Don’t double count

One additional point I want to make before closing is that you shouldn’t measure ALL sinks blindly. Don’t double count goods that have already been accounted for in the cost accounting framework. For example, we don’t want to account for the fuel burned to drive a space ship to an asteroid to mine resources if we already accounted for that fuel when it was produced earlier in the supply chain. However, if the fuel is picked up for free in the game world in it’s complete form, we can account for that burn in VGDP.

Continuing our example, suppose a player can pick up fuel off the side of the road and use it in their car to go mine resources. They burn this fuel to travel throughout the game but it was never produced in a costly way. They just had to fly about to pick it up. We DO want to account for this burn/sink because we haven’t accounted for it anywhere else. So while the framework is pretty simple and foolproof, you need to check for edge cases like this when calculating VGDP. A good economist will do this without even blinking.

Closing

After calculating GDP a dozen and a half ways and thinking about the problem for about 2 years, I personally find the methodology explained in this short article to be the cleanest and simplest design moving forward for virtual economies. I certainly don’t want to suggest that this is the end-all-be-all of GDP is virtual economies. But it’s clean, simple, and very generalizable to many cases. The definition is agnostic to genre, industry, and economy design. I also find that it builds nicely on Castronova’s seminal definition.1 Admittedly, I’ve been sitting on this article for some time, but Zhang’s recent article prompted me to push this out while the topic is hot.2

1

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=294828

2

Article found here: https://mirror.xyz/kieferzang.eth/TCRyisoFVtxvkCi1rzLHLmItT4blUdAiYQ2ezU-Ccys

The article aims at revisiting Castronova’s paper and putting it in the modern context of web3. While I agree with Kiefer’s sentiment and prediction, I believe it’s a bit softball and could probably be accelerated to “next 5 years”.