One of the most exciting advantages of web3 game development is that it unlocks the door for new mechanics regarding player ownership, utility, and engagement via tokens. However, simply offering tokens to players is not enough - in order to build a successful and sustainable in-game economy, builders need to approach economy design with intent and responsibility.
In this article will cover in-game and utility-focused tokenomics as these play a pivotal role in your economy design. We will explore concepts such as governance, ownership, token count, allocation, monetary policy, and token velocity.
While the topics covered here are far from exhaustive, this article serves to provide a high-level overview of key concepts, how design choices can impact economic outcomes, the experience of your users, and drive better informed decision-making.
Governance, Ownership and Sharing in Project Success
Tokens are usually aimed at rewarding token holders for activities that are aligned to and benefit the project. They also enable token holders to benefit from the upside in the project. As such, tokens serve as a key lever in the marketing of a project and the management of the project's stakeholder community.
Examples of ERC20 use cases:
- Grant governance over the project - Holders can vote on project decisions
- Reward pro project activities - Tokens are rewarded to users that partake in activities like signing up
Considerations for your own ERC20:
- What are you trying to incentivize with this token?
- What are the legal and compliance implications?
- How are you capturing value, i.e. how will the token holders benefit from the project upside?
Token count refers to how many distinct ERC20 tokens are in the ecosystem
- No token - No ERC20s, instead NFTs are used for economic activity
- Single token - One ERC20 for governance and in game activity
- Dual token - One ERC20 for governance and a separate one for in game activities
- 3 or more tokens - One ERC20 for governance and multiple ERC20s for in game activities
Here are some considerations for choosing your own token model:
Generally each model has its own pros and cons, and more tokens lead to higher complexity and resource drain on your team.
Token allocation is an opportunity to align incentives between the team, early adopters and players. As a baseline, tokens should always define the following:
- Max supply - Fixed (BTC) or uncapped (ETH)
- Distribution - Are all tokens printed and distributed, or progressively minted
- Allocation - Split of tokens between different parties, for example:
Community treasury : retained for future distribution through governance
Core Team: founders, current and future employees
Ecosystem incentives: earmarked for growth programs
Airdrops : delivered retroactively to users for value-adding actions
Public sale: general public
- Vesting periods - Period between tokens being allocated/purchased and when they are available to spend and trade
Note: The above generally refers to governance focused tokens. We will explore in-game tokens and off-chain tokens separately.
Projects with tokenomics are run similarly to small nations - they each have their own economies and need to manage monetary policy, monitor outcomes, and implement controls. This section focuses on in-game tokens. However, learnings can be applied to governance tokens too.
Here are some general examples of how monetary policy impacts games:
Deflationary - A token supply that declines over time. This can result in increased demand for a limited supply of tokens in a successful game economy, but may slow down game activities if it attracts a high proportion of token holders who are not directly interacting with the game as a primary activity
Inflationary - A token supply that increases over time. This can result in increased supply of tokens with potential for this to exceed demand, but has the general benefit of increasing the chance that sufficient tokens are available to facilitate game activities. More reading on in game inflation here.
Generally, if more value is being extracted from the game (players selling items) than being input (new players joining or existing players spending money), the sustainability of the in-game economy is adversely impacted
Another way to look at the above is that your game cannot consist purely of one type of participant, and must appeal to actual players!
Monitoring and controlling
Similar to real-world economies, projects should establish health metrics and controls. Some examples of health metrics include: token stability/appreciation, supply, rewards, and activities. From an in-game perspective, projects can also monitor which game loops players use to generate tokens. For example, is a certain action generating too much of one resource?
Here are a few examples of controls:
- Avoid tokenizing all in-game assets
- Introducing tax on in game transactions to reduce supply
- Create token sinks where players can spend their tokens
Token velocity is defined as the total transaction value divided by the average network value. It represents how frequently users trade a token compared to holding it.
'Governance-style' tokens: a high velocity represents a token that does not have a strong reason to be held rather than used. An example would be a token that is required to execute a specific function (e.g. required to pay a fee), and delivers no value outside of this. High-velocity tokens may be exposed to volatility and absent speculation, and may struggle to maintain long-term sustainability
- It is important that these tokens capture and deliver benefit to holders to slow velocity
- Staking can be a useful tool to slow velocity, but must accompany true value or benefit as noted above.
In-game 'utility' tokens: an important distinction is that for in-game tokens, transactions that are inside the game economy (e.g. in-game or peer-to-peer) are notionally different from velocity outside the economy;
- Creating enough depth and width (i.e. complexity) within the game economy that opportunities for trading and spending emerge helps retain value inside the game economy
- Creating friction to acquiring tokens or reducing economic openness can deter value-extractive players without impacting gameplay. Examples include making resources off-chain assets, emitting tokens to players who win (rather than just participate), adding earn limits (energy or durability) or emitting off-chain assets which can be upgraded to NFTs with in-game resources. See 'Economic Openness' section
- Note that as mentioned above, while requiring an NFT to play increases friction, it also increases barrier to entry and reduces net new inflow of players by eliminating the curious but non-committal
The ability to design in-game economies are just one of the many advantages web3 games offer over traditional gaming models. Building a robust and sustainable in-game economy can open the doors for new ways to foster player ownership, utility, and engagement, which in turn are powerful levers for building a liquidity and revenue engine for your game. With this in mind, it is critical for game developers who wish to implement a token model to do so with intent and understanding in order to make an informed decision.
Building a web3 game can be incredibly difficult. At Immutable, we believe that this should not be the case. By providing the proper guidance, tools, infrastructure and support, Immutable allows developers to build a fantastic web3 game on easy mode.
Want to learn more about building with Immutable? Sign up to our Developer Hub today to get started.
If you are a game studio representative, we'd love to get in touch.