7 Essential Considerations before Launching a Gaming Token
Introduction
I can assure you that almost every web3 game or game studio has had lengthy discussions about tokens. It’s something that players and investors expect to see consideration on, meaning you can bet it is at the top of many founders’ minds.
There are many articles out there about how tokens might work and different ways to design them. None of them properly explain the challenges of having a token.
Today I thought I would take a different approach, and share my perspectives on things I would think about before launching a token, but don’t often get talked about. These are based on running a token launch end-to-end, observing 2 other token launches, as well as conversations with different web3 gaming teams who plan to have a token.
Let’s dive right in.
1. Strategy: Wait but why?
It might seem obvious that the first thing to consider is whether to have a token at all.
However, this isn’t always the case. It often feels like there is an assumption of “yes we will have a token”, perhaps instilled by investors or players, or perhaps observations of other gaming tokens and their enormous valuations at their peak.
I believe the primary reason people don’t question having a token more is that it’s unclear what the downsides are. Or maybe people think there isn’t a downside.
Just write a whitepaper, mint some digital coins, raise a few mill and all of a sudden have a treasury worth tens of millions… right?
No, I don’t think so.
The primary reason to really think about WHY you should have a token is that it’s costly. It costs time, attention, and money. The rest of the article will make hopefully this clear.
Let’s get more specific…
2. Tokens vs Equity
Many token conversations go something like this:
“Fundraising is tough, it’s a bear market…
We need money, let’s sell a token…
We’ll give it a bunch of utility, so it’s valuable and attractive to investors…”
And this is where an undiscussed trade-off arises - the fact that token valuation is often in competition with equity valuation (i.e. the company).
The best way to explain is with a simple example.
Let’s say you want to create a token that is super attractive (defined as price goes up if your underlying game/studio does well). You need two things to be true:
Players buy a lot of tokens
Players don’t receive a lot of free tokens
The second one is “easy”. Just don’t give out too many free rewards (this includes staking) and don’t give back to players the tokens they spend on you.
The first one is much harder because players will only buy tokens if they get something of value in return. Same as standard game monetisation.
Developers have to make a choice. If you have something of value that players want to spend money to buy from you, do you sell it for revenue, or allow users to spend tokens for it, which benefits token holders rather than the equity company?
This is the trade-off between cash revenue that a game can generate versus the demand for a token (which drives its price).
Teams often try to solve this in two ways. First by striking a balance so that some % of demand goes to the token, but a sufficient % also goes to the company to sustain the business. Teams also try to ensure the incentives between token and equity holders are aligned by ensuring people have both, which is why fundraising in 2022+ often occurs via both equity + token warrants.
3. Day Zero Budgeting
Launching a token generally involves planning out the financial model of the token on day zero.
How will the token work? How many will there be? What’s the unlock schedule? What’s the utility?
Even if there are massive “subject to change” flags everywhere, the fact is that people will make financial decisions on the token depending on what is said about it. There is also often a level of implied trust that teams will not deviate from their initial token model, and the risk of massive backlash if they do.
This creates a really big challenge for any game launching a token.
To illustrate, anyone who works in a company will know that roadmap plans and budget forecasts are always wrong. In a start-up or game economy, it’s even more wrong.
Imagine having to do 4+ years of roadmap planning and forecasting for a start-up, and committing to it very publicly, before it’s even launched.
This is exactly what every project does when they show the token allocations and vesting schedules in their whitepaper.
There are a few ways around this. The first is to break the industry norm and to release a token without information about it’s roadmap, utility or full allocations. The other is to design with flexibility in mind. For example, having large allocation buckets rather than small ones, and making directional promises rather than specific roadmaps.
Flexibility is something that I did not appreciate much before, because I thought you could just be “smart” about predictions, but these days I value flexibility highly.
4. Cost of Token Operations
Teams typically know they will need to invest time and money on the token design and initial launch.
Most teams don’t spend realise how much effort is required to operate a token.
It’s like the difference between printing out entry tickets at a theme park and then integrating the tickets themselves. The former is easy, whereas the latter requires hiring staff, figuring out accounting, installing payment systems, and maybe even building the rides themselves.
Tokens don’t run themselves and teams should really consider whether they are ready to operate a live token.
Some examples of problems that I’ve seen:
Developing internal procedures and security solutions to use the token without fear of fraud, negligence or hacks (which can all kill the token).
Figuring out how mainstream players can buy tokens using credit card or without owning a wallet.
Figuring out how to get a game with a token can get approved by the Appstore.
Optimising token budgets and allocations in the same way you optimise Facebook ads, to get the most out of them.
Tracking and analysing key metrics around the token, and acting when there is a ‘red’ flag on price, sustainability or liquidity.
Developing products that only exist because there is a token, such as staking dashboards or governance systems.
Having another audience to promote and market to (token buyers) that you wouldn’t have to worry about otherwise.
Doing continual accounting and tax reporting for the token.
There is a LOT of work that goes into operating a token. Enough to fill multiple full-time hires if you wanted. It’s important to be aware of this before launching a token.
Particularly before promising too much…
5. Promise vs Delivery
The perpetual challenge that all web3 projects face is how to balance hype and promises with delivery. The stakes get even higher with a token, where speculation often runs wild when it’s launched.
It’s very tempting for games to overpromise and hype the token launch, because it provides great short-term results at the expense of long-term execution. It might feel ‘necessary’ to get attention or fundraise. And it might even be worth it to make some trade-offs here.
However, it’s also risky. Failure to deliver on promises leads to backlash, and also creates a “promise backlog” that will constantly plague the team and never gets forgotten.
Players often want teams to underpromise and overdeliver. They want certainty around what will happen in the future (the promise) and want to be surprised and delighted when it does happen (the overdelivery).
However, this is hard even with the best intentions. In my experience, two main things cause under-delivery. The first is underestimating the effort required. Sounds simple, but in reality estimating anything to do with a new technology is hard. The second reason is that priorities themselves change all the time. Sometimes for reasons outside of your control.
My advice would be to avoid promises altogether if you can. Or go as light and conservative as possible if you must have some.
6. Legal Structure and Risk
Note: I’m not a lawyer, have only worked with them - DYOR.
Everyone is aware that tokens are a regulatory risk. But how do you actually deal with this in practice?
The first challenge comes in the design phase. Many concepts such as burning, passive income, or even what you say about the token contribute to the risk of whether it is viewed as a security.
This would be easy if the constraints and design space was defined, but it’s not, meaning teams need to work with lawyers to figure out the “riskiness” of different designs, and then need to decide on whether this fits their risk appetite.
It can be a bit of a balancing act to try to achieve the intended incentive and design outcomes while making adjustments to reduce risk.
The next challenge is structuring the legal entities. One typical structure is to setup a foundation and token issuer in an offshore jurisdiction such as Cayman Islands or BVI, and to make this company fully independently owned and separate to the developing entity. The developing entity (aka the game studio) will then offer software, development and other services to the Token Issuer under a development agreement, for a fee that is typically paid in tokens and cash.
Note this means that there is substantial legal cost. Teams need to set up an entity, prepare documents for any token sales (SAFT, T&Cs), co-design a token to be within the company’s legal risk appetite, and then draft a legal opinion that the token is not a security (required by most tier 1 exchanges). Teams need to decide if this cost is worth it.
Finally, teams need to be very careful about what they communicate regarding the token. Something as simple as implying the team “runs” the token (when it is technically meant to be owned by an independent offshore entity) can be an issue and also come up as evidence in regulatory investigations.
Any team with a token should create clear marketing and communication guidelines around the token, or even seek advice from their legal counsel, to ensure marketing language doesn’t increase their legal risk.
Legals is important but the costs (and effort) add up.
7. Playing the Finance Side
Finally, one of the most foreign parts of a token is managing the financial side of them. Even with a traditional finance background, it can be tricky understanding what to do when it comes to the plethora of crypto acronyms: MM, CEX, DEX, TGE, etc.
There are a few important considerations that, if not done right, can come back to bite the project later.
Vesting and unlocks: Vesting and unlock schedules might just seem like something you copy and paste from other games, but they actually have a major impact on future price activity. Having a large % of tokens unlock at the same time leads to the price decreasing, whether it’s because holders sell or there is a perception that holders will sell. Perception is key here, and one thing that projects can design for is to ensure major unlocks don’t represent a significant % of the circulating token supply at any point in time.
The other challenge here is incentive alignment between groups. Giving holders different vesting schedules effectively means that one group has an advantage over the other, while making the vesting too short can make the token too attractive to short term flippers.
Market Makers: There is a lot of behind the scenes activity that happens to ensure a token can be easily traded, which improves its price stability and potentially even price (due to having a liquidity premium).
Teams will often work with market makers (MM) to achieve this. However, market makers are unregulated, meaning that having aligned incentives is absolutely critical. There are two common structures for market making: the first is where the company lends tokens (and maybe cash) to the market maker and provide an option to the MM to buy it for a given price. In this setup, the MM might be incentivised to manipulate the price to maximise the return they can get on their option, so it’s really important to understand the incentives. The second structure is less common and is a traditional flat fee structure, where liquidity is provided regardless of price. Teams can also work with MMs to secretly sell their own tokens to fund the project (while avoiding public scrutiny) or to manage the price (for example buying before a major positive news announcement and sell afterwards).
Centralised (CEX) and decentralised exchanges (DEX): Exchanges are also really important to provide liquidity and accessibility to the token. DEXs such as Uniswap, 1inch or Sushi are useful in allowing anyone to buy the trade token without going through a third party or KYC. Teams will need to seed the DEX with a mixture of ETH + the token, and in doing so set an initial price of the token. Projects can also provide liquidity incentives, to incentivise other people to seed the liquidity pool in exchange for rewards. CEXs such as Coinbase or Binance are also important as they allow others to buy the token, and are typically also an indicator that a token is legitimate (because exchanges are subject to regulation). Note that getting listed on a Tier 1 exchange might require a legal opinion that the token is not a security, so doing the proper legal set-up here will be important.
Managing price: Once a token is live, its price becomes important. Even though it can be highly volatile, I’ve found that its most useful to look at price with alpha removed (e.g. track it against ETH or BTC rather than USD) to see how the price is trending. The reason it’s so important is that tokens are often used as an incentive that effectively serves as the marketing budget of a game. Having a lower price means having less marketing budget. Price is also important to many players. Even if they say it isn’t, the truth is that hardcore supporters of a web3 project will be the ones most likely to also have tokens. The price of the token can affect their sentiment towards the project, which in turn affects how they talk about the game to newcomers and thus impacts bottom of funnel conversion.
Conclusion
I believe there is massive potential in having a token as part of a game, as they are a powerful tool to align incentives and bootstrap growth of the ecosystem. However, there are also major downsides and considerations that teams must know before they decide to launch one. Designing a token is hard, but operating and managing a token is arguably even harder. I hope this article sheds light on some of these, and would love to hear any other perspectives or things that I might have missed.
About me: Lifelong gamer and crypto class of 2017. Founder, advisor and investor in web3 gaming. Formerly VP @ Immutable leading Guild of Guardians and economy design for Immutable Game Studios. Find me on Twitter.
He's back.