Models for Economic Collection in Fully Onchain Games and Autonomous Worlds
An analysis of economic collection models and their susceptibilities in an onchain environment.
Disclaimer: The information, interpretations, and terminologies presented in this article, particularly those relating to economic models in game design, are intended for illustrative and academic purposes only. They are not to be mistaken for legal definitions or standards. Readers are advised not to use the shorthands or concepts discussed in this article as a basis for legal arguments or decisions. Before making any legal decisions or referencing any terms in a legal context, one should consult appropriate legal counsel or refer to specific legal definitions.
There’s a sea of options for economic mechanisms in fully onchain games (FOCG/FOG) & autonomous worlds (AW), yet not many direct analyses that cover the majority of them together in one piece. To help remedy that, I distilled some analysis for myself and others that are exploring these mechanisms for FOCGs/AWs.
I’ve observed that the collection and distribution of funds are two separate activities that can have separately defined models. For this article, we will only be discussing economic collection, not distribution1. Fees are an easy example of collection, and one case of distribution is part of the funds being given to developers.
Since each implementation of a collection model is likely to be different, we’re going to quickly analyze how susceptible the general models are to different attacks in the onchain environment.
Note: Given that the recipient of the funds is not necessarily defined, I will be referring to the gathering of funds as collection, not revenue. Depending upon demand and personal bandwidth, economic distribution models might get included in a future article.
Introduction
This article is built to be a reference guide that attempts to walk a fine line between remaining objective and deducing the most generally useful collection models by eliminating potential pitfalls of others. In order to respect reader’s time and attention, the primary section of the article will consist of a brief summary of schools of thought and then list the most useful models (*opinionated, to some extent). Additional analysis and context can be found in the appendices.
Schools of Thought
There are two different dimensions under which FOCG/AW economic models are often discussed, but sometimes can get confused for one another due to their similarities. These are Financialized vs Not Financialized and Tokenless vs Token-Forward. This section is mostly to be used to paint some context prior to the main collection model analysis and should not be considered comprehensive.
Financialized vs Financially Minimized
The concept of financializing a game’s economic model is hardly unique to the crypto industry — EVE Online being the most clear example of a financialized traditional game. While some others may dissent, I view game financialization as a spectrum rather than a binary trait. An entire separate article could be written on analyzing and addressing these nuances.
For the sake of brevity, I’ll define financialization as the extent to which value from one universe can be transferred into another. Naturally, if it is encouraged by devs, it will be more financialized. If it isn't encouraged by devs, there still is some level of financialization possible — but it likely won't be of the same magnitude as a dev-encouraged environment. This usually manifests as secondary markets not condoned by the devs. Consider MMOs like Runescape or World of Warcraft where 3rd party websites sell gold to players, more on that later.
Advocates who oppose financialization can have a wide array of arguments, including ethical concerns, economic complexity, gameplay impact, and limited accessibility. Advocates open to financialization often point to unique/experimental gameplay mechanics, collection of funds, high player engagement, and the subversion of otherwise inevitable secondary markets.
Tokenless vs Token-Forward
A Token-Forward protocol/game is most often defined as one that possesses at least one token that represents game adoption or engagement in some way and is an outlet for rewards or external speculation. In common discourse, a Tokenless game may still have tokens inside the game itself, but developers intend for those tokens to have minimal accessibility and utility outside the game’s universe.
As we are well aware, the permissionless onchain environment leaves the door open for external logic that can modify how we interact with an established protocol. Thus, the distinctions between Tokenless and Token-Forward schools of thought can also become a bit blurred with time.
If a Tokenless game has a long (or infinite) session time and gathers significant adoption, some of its resources may become commoditized outside of the original intent of game designers. For a traditional example, Runescape does not condone the buying/selling of their ingame gold with real money, yet there are plenty of 3rd party markets in existence. Therefore, the final distinction between Token-Forward and Tokenless in common discourse is often the game designer’s original intent. In the case of the Tokenless game with a commoditized resource, we will refer to this game as a Tokenless, Financialized game.
Arguments between Token-Forward and Tokenless games often inherit arguments similar to the Financialized vs Financially Minimized section. A supplementary argument in favor of Token-Forward games is that the token in question is often a short-term marketing tool as well. The argument against this is that the token in question is a reflexive marketing tool that magnifies both adoption and abandonment.
Some of the novel merits of a Token-Forward game lie in the economic distribution part of a game’s overall economic analysis. As mentioned at the beginning of this article, we are only going to cover economic collection for now. Discussing this further probably justifies another article in a series. For the remainder of this article, Token-Forward vs Tokenless will be limited to highlighting collection model susceptibilities to Tokenized Forks.
Collection Model Susceptibilities
Given the highly adversarial and creative onchain environment, it’s well worth noting how each economic collection model is susceptible to certain forms of known attacks. The following chart is my analysis of how susceptible each model is to certain attacks, but note the legend does not deem any susceptibility to be absolute. All of these models are highly malleable. Given that each game implementation is unique, there is always an opportunity for exceptions.
Let’s make a short brief what each of the susceptibilities are:
Undercut Forks: Some individual or group finds the economic collection model to be overstepping its bounds, or they believe they can siphon off engagement for their own financial gain. Thus, they fork the game and create a new, similar one and compete away some (or most) of your economic collection by implementing a lower cost to the user.
Ex: You charge 10% fees for each poker game, and a competitor forks your code to just charge 5% fees.
Client Forks: Some individual or group wants to visually change the appearance of the game or how they interact with the game in some way. Thus, they either fork the existing client (or create their own client) to interact with the engine of the game while implementing only their preferred visual aesthetics.
Ex: Player doesn’t like the textures in a game and ads in the client, so they fork a new one that conforms to their desires (or builds one from scratch) and distributes it
Wrapper Circumvention: Some individual or group wants to avoid the consequences or limitations of transferring an asset, so they deposit it in a wrapper contract that abstracts the transfer logic so long as it stays wrapped.
Ex: Fee-on-transfer token $FEE charges 1% on each transfer. A wrapper contract called $wFEE is built, so now people can speculate on the token multiple times but only pay transfer fees when wrapping/unwrapping.
External Enforcement Dependency: You built your collection model to be reliant on how another team/group/protocol maintains itself, thus you are subject to its changes with little to no influence or recourse.
Ex: Opensea vs Blur debate of royalties. The marketplace could change their rules on royalties with you unable to do anything about it.
External Competing Markets: Similar to an Undercut Fork, but specifically centered around creating a separate undercutting market around the same assets or information.
Ex: You built a game whose state also has a built-in prediction market for the audience to participate in, and you take 10% of the fees. Someone builds a 3rd party prediction market based off the same game state but only charges 5% fees. (Could even use a bridge to go through a different chain.)
Account Abstraction: This susceptibility occurs when a game assumes 1 address >= 1 unique person. If someone is able, they may build/implement an abstracted account protocol that allows for permissionless & trustless logic to be executed within the confines of a single address.
Still confused? Imagine trustless Netflix account sharing, and you can build logic like who is allowed to watch what genres or what time they’re allowed to watch.
Sybil Attack: This susceptibility occurs when a game assumes 1 address <= 1 unique person. If there is some advantage to having multiple accounts in one person’s control, they will likely exploit that advantage.
Still confused? Imagine a scenario where you allowed each unique address 24 hours of free play before having to pay. Someone may just generate new addresses every 23 hours and transfer accumulated assets from old accounts to new accounts.
Tokenized Forks: Similar to Undercut Forks, but also creates token incentives to attract attention to them and siphon off engagement from you.
Ex: Sushiswap vs Uniswap vampire attack
More on Undercut Forks and Tokenized Forks
Generally speaking, Undercut Forks and Tokenized Forks are some of the nastiest and most pervasive susceptibilities in the industry. It’s a very rare occasion that you have a direct defense against them. Rather, your best indirect defenses are through continually delivering value to your users, developing a vibrant community, and keeping your economic collection small and continuous.
Even if perfectly implemented, your game being Token-Forward does not prevent other Tokenized Forks from occasionally appearing. However, being Token-Forward tends to add to a stronger indirect defense at the expense of needing to drive some sort of purpose to the token in question.
If the forks genuinely change something from your original game, consider the benefits and drawbacks of implementing it in your own game, if possible (and positively reward those who affected change). If you believe it’s a net-negative change, then your only real recourse is continuing to deliver a great gameplay experience and waiting out the opposition.
Generally Optimal Models
Here’s where we get to the fun part and select some of the models that, based upon my opinion, have the best chances of being generally useful under common design situations. Note that this does not mean that the other models should be completely dismissed! There’s a decent shot that some of the others could still work under niche cases or with certain tech advancements. If you want to read through my analysis of each model listed in the earlier matrix, I encourage you to check out the Appendix after reading the rest of the main article.
Deposit-to-Play
Overview: Players deposit principal assets to play, protocol takes and aggregate assets to deposit them in a yield-generating avenue. Protocol collects interest and the player can withdraw principal assets at their own will.
Example: Deposit the required amount of stETH to play. The protocol will collect the daily yield, and you can withdraw your deposit any time after 24 hours.
Advantages: Continual collection that scales with usage or players.
Disadvantages: Long-tail risk to principal (and proper transparent disclosures), scale required to collect notable volumes, yield changes based on external market conditions. Some form of technical management required to monitor security risks or external changes.
Susceptible: Undercut Forks (for those who don’t have the capital or want to avoid risk), Tokenized Forks, External Enforcement Dependency on yield source
Conclusion: viable for some fully onchain game applications
Intuition: Best suited for long-term games & autonomous worlds. Have to choose conservative yield sources like staked ETH. Note that $1M of annual yield at 4% requires an average of $25M principal. May need to enforce some short-term locking (ex: cannot withdraw within 24h of depositing except in emergency withdrawal cases)
Addendum: This mechanic might be able to be nested into other collection models. For example, you might have a 7-day wagered competition where all participants keep their principal and the yield is split between the winners and the collection model.
Global Resource Generation Fee
Overview: Whenever a player generates a certain resource necessary for gameplay, a small fee is required to be paid.
Example: Iron is necessary to build plated armor, in a game where armor degrades over its use. In order to mine Iron Ore, a player must spend 1 hr mining and additionally pay X fee per ore to collect it.
Advantages: Can curate which types of resources require payment fees to generate. Can roughly scale with player engagement.
Disadvantages: May cause players to play for optimization rather than fun, as at least one asset is anchored to external value. Requires a well-managed game economy and/or generation curve to not overinflate or disinflate the game.
Susceptible: Undercut Forks, Tokenized Forks
Conclusion: viable for some fully onchain game applications
Intuition: Best suited for long-term games & autonomous worlds. Substitutes econ collection susceptibilities for game economic design complexities. It must hit a sweet spot between being useful to gameplay, not overly inhibitive to access/pay, and properly constrained to prevent rampant inflation/disinflation.
Cosmetics
Advantages: minimizes direct user expense to make it more accessible for all
Disadvantages: unreliable collection stream, visual fatigue or limited vectors of expression may taper demand
Susceptible: Client Forks (for self-satisfying cosmetics, not social clout cosmetics), Account Abstraction, Tokenized Forks
Conclusion: somewhat viable for fully onchain applications, likely not standalone though
Intuition: Useful for a highly social, prideful game. If cosmetics are only built with intent for the user to enjoy it themselves rather than peacocking, then client forks may emerge and subvert your intentions.
Play-to-Die (Neo-Arcade)
Overview: An onchain hyperstructure take on the classic arcade game structure, where the game is deployed and lives on with the chain “forever”. Whenever a player dies (or maybe takes damage), payment is drawn out from the player’s control.
Example: Super Mario Bros but each lost life deducts a small amount of assets from your balance.
Advantages: Can be small, incremental payments to lessen the incentives for an emergent undercut fork. Engagement centric. Loads several plays-worth of assets so the gameplay loop is more seamless from death vs Classic Arcade.
Disadvantages: Incentivizes devs to build short or harsh sessions to collect more credits. When a player loses, they likely are already upset or at least broken out of the gameloop. Players that feel like they were cheated may rage at the game for taking its money.
Susceptible: Undercut Forks, Tokenized Forks
Conclusion: What makes playing in this game more of an additive and valuable experience vs some undercut fork? If justifiable, can be viable for a certain subset of fully onchain applications
Intuition: While this could work for a variety of game types, it feels like the category best suited for this is short, challenging, achievement games that still are somehow social. Make a player feel like the Flappy Bird craze did, and only pay a cent per death.
Pay-to-Play Dynamic Fees
Overview: Usually this will be a natural option in cases of handling the consumption of limited network/computation resources. Chain Demand is one example, but theoretically you could still constrain the amount of activity at any time for other reasons, like specific game designs.
Example: Any chain. Note that some L2s may also have a floor rate.
Advantages: Highly customizable, fee structure designed by you but likely is dependent upon activity and/or demand. Continual collection. No need to pay large rent to other chains, roll your own appchain instead.
Disadvantages: Dynamic fees will degrade UX if they are at a high enough expense to the average user, as they’re specifically designed to price out certain volumes of activity. If chain-based, inherit all of the disadvantages of running your own rollup/chain. Don’t forget player friction of potential need to bridge assets.
Susceptible: Undercut Forks (if justifiably chain-based, much higher technical and operational barrier may mitigate some of this), Tokenized Forks
Conclusion: Viability highly variable based upon game structure and choices made on potential custom chain design
Intuition: Feels like the more complex & higher transaction volume the game is designed, the more viable (or necessary) this becomes by creating and using a dedicated chain. Game designs that require soft limiting global activity should also consider this.
Ending Notes
I hope that this article has helped you distill and compare some of the economic collection models you’ve been curious about! Ultimately none of these are perfect or a one-size-fits-all, so you’re still going to have to put in some legwork on deciding which model best matches your overall game design. If you want to talk further, feel free to contact me via Twitter or any other medium you see me floating around in.
Optimistically there will be a followup either on distribution models or other forms of analysis!
Special thanks to Rafael Morado, Matt Dion, and pet3rpan for their discussions and feedback.
Appendix
Here I’ve laid out my analysis for each model shown in the original susceptibility chart. It’s exhausting for the reader to go through each one independently, so I recommend selectively reading the models you’re interested in.
Appendix A: Tokenless Models
Premium
Example: Nintendo games
Advantages: collected volume scales per honest user
Disadvantages: consider ongoing operational expenses in initial price, with unknown demand
Susceptible: Undercut Forks, Account Abstraction, Tokenized Forks
Conclusion: not viable for majority of fully onchain applications
Gameplay Expansion (Premium DLC)
Advantages: collected volume scales per honest user, can do F2P for core game
Disadvantages: consider ongoing operational expenses in price
Susceptible: Undercut Forks, Account Abstraction, Tokenized Forks
Conclusion: not viable for majority of fully onchain applications
Subscription
Advantages: recurring, predictable, scalable collection
Disadvantages: continual need to provide value to users
Susceptible: Undercut Forks, Account Abstraction, Tokenized Forks
Conclusion: not viable for majority of fully onchain applications
Ad-Supported
Explanation: Out-of-universe content disrupts ingame play
Examples: banner ads, video ads, etc
Advantages: minimizes direct user expense to make it more accessible
Disadvantages: unreliable collection stream, requires massive scale, scam filtering, brand association
Susceptible: Client Forks, Sybil Attacks (depending upon implementation/metrics), Tokenized Forks
Conclusion: not viable for majority of fully onchain applications
Sponsored Content/Product Placement
Explanation: Out-of-universe content paid to be placed within your existing game universe
Example: Mountain Dew sponsoring all beverages in a Sims-like game
Advantages: Unless the sponsor is already in the crypto niche, this is a “win-more” strategy. However, there may occasionally be decent bursts of money from the right partners.
Disadvantages: potential for negative brand affiliations, requires large amount of attention, negotiating sponsorship terms, unreliable collection stream, inadequate as standalone
Susceptible: Client Forks, Sybil Attacks (depending upon implementation/metrics), Tokenized Forks (if the sponsor is technically savvy they could attempt to just launch their own version without asking)
Conclusion: viable for a few fully onchain applications
Licensing
Explanation: Your ingame-universe IP or logic is paid to be affiliated with some out-of-universe thing
Example: Monopoly, Game of Thrones edition (but where Game of Thrones pays to have a licensed Monopoly version, not vice versa)
Advantages: Unless the sponsor is already in the crypto niche, this is a “win-more” strategy. However, there may occasionally be decent bursts of money from the right partners.
Disadvantages: minimal IP control, requires large amount of attention, negotiating licensing terms, unreliable collection stream, laughably inadequate as standalone
Susceptible: Client Forks, Tokenized Forks (if the sponsor is technically savvy they could attempt to just launch their own version without asking)
Conclusion: not viable for majority of fully onchain applications
Cosmetics
Advantages: minimizes direct user expense to make it more accessible for all
Disadvantages: unreliable collection stream, visual fatigue or limited vectors of expression may taper demand
Susceptible: Client Forks (for self-satisfying cosmetics, not social clout cosmetics), Account Abstraction, Tokenized Forks
Conclusion: somewhat viable for fully onchain applications, likely not standalone though
Intuition: Useful for a highly social, prideful game. If cosmetics are only built with intent for the user to enjoy it themselves rather than peacocking, then client forks may emerge and subvert your intentions.
Pay-to-Play Credits (Classic Arcade)
Advantages: Can be small, incremental payments to lessen the desire to do an undercut fork. Engagement centric.
Disadvantages: Incentivizes devs to build short sessions to collect more credits. When a player loses, they likely are already upset or at least broken out of the gameloop. Players that feel like they were cheated may rage at the game for taking its money. Adding another gate of making them feel the pain of actively spending to buy more credits and continue makes it easier for them to walk away and never play again, even if they were really close to a meaningful ingame payoff.
Susceptible: Undercut Forks, Tokenized Forks
Conclusion: What makes playing in this game more of an additive and valuable experience vs some undercut fork? If justifiable, can be viable for a certain subset of fully onchain applications
Play-to-Die (Neo-Arcade)
Overview: An onchain hyperstructure take on the classic arcade game structure, where the game is deployed and lives on with the chain “forever”. Whenever a player dies (or maybe takes damage), payment is drawn out from the player’s control.
Example: Super Mario Bros but each lost life deducts a small amount of assets from your balance.
Advantages: Can be small, incremental payments to lessen the incentives for an emergent undercut fork. Engagement centric. Loads several plays-worth of assets so the gameplay loop is more seamless from death vs Classic Arcade.
Disadvantages: Incentivizes devs to build short or harsh sessions to collect more credits. When a player loses, they likely are already upset or at least broken out of the gameloop. Players that feel like they were cheated may rage at the game for taking its money.
Susceptible: Undercut Forks, Tokenized Forks
Conclusion: What makes playing in this game more of an additive and valuable experience vs some undercut fork? If justifiable, can be viable for a certain subset of fully onchain applications
Intuition: While this could work for a variety of game types, it feels like the category best suited for this is short, challenging, achievement games that still are somehow social. Make a player feel like the Flappy Bird craze did, and only pay a cent per death.
Pay-to-Play Dynamic Fees
Overview: Usually this will be a natural option in cases of handling the consumption of limited network/computation resources. Chain Demand is one example, but theoretically you could still constrain the amount of activity at any time for other reasons, like specific game designs.
Example: Any chain. Note that some L2s may also have a floor rate.
Advantages: Highly customizable, fee structure designed by you but likely is dependent upon activity and/or demand. Continual collection. No need to pay large rent to other chains, roll your own appchain instead.
Disadvantages: Dynamic fees will degrade UX if they are at a high enough expense to the average user, as they’re specifically designed to price out certain volumes of activity. If chain-based, inherit all of the disadvantages of running your own rollup/chain. Don’t forget player friction of potential need to bridge assets.
Susceptible: Undercut Forks (if justifiably chain-based, much higher technical and operational barrier may mitigate some of this), Tokenized Forks
Conclusion: Viability highly variable based upon game structure and choices made on potential custom chain design
Intuition: Feels like the more complex & higher transaction volume the game is designed, the more viable (or necessary) this becomes by creating and using a dedicated chain. Game designs that require soft limiting global activity should also consider this.
External Market Royalties/Fees
Example: Opensea royalties
Advantages: Continual collection that grows with volume
Disadvantages: Incentivizes volume over value provided
Susceptible: Marketplace-dependent enforceability, Wrappers for circumvention, Tokenized Forks
Conclusion: not viable for majority of fully onchain applications
Competition/Wager Rake
Example: Poker, where the house takes a portion of each pot
Advantages: Continual collection that grows with usage
Disadvantages: only guaranteed collection from players where the game requires the wager to enter, game needs to be popular enough to inspire high stakes competition, need to keep rake low enough to not motivate circumvention
Susceptible: Undercut Forks, External Competing (Wagered) Markets, Tokenized Forks
Conclusion: viable for some fully onchain game applications
Intuition: probably not the easiest to rely upon. While the game isn’t popular, not much wagering will happen. Once the game becomes popular and wagering proliferates, many will create third party wagering systems — especially if the data is easily accessible to build a trustless third party system.
Deposit-to-Play (Principal-Yield Split)
Overview: Players deposit principal assets to play, protocol takes and aggregate assets to deposit them in a yield-generating avenue. Protocol collects interest and the player can withdraw principal assets at their own will.
Example: Deposit the required amount of stETH to play. The protocol will collect the daily yield, and you can withdraw your deposit any time after 24 hours.
Advantages: Continual collection that scales with usage or players.
Disadvantages: Long-tail risk to principal (and proper transparent disclosures), scale required to collect notable volumes, yield changes based on external market conditions. Some form of technical management required to monitor security risks or external changes.
Susceptible: Undercut Forks (for those who don’t have the capital or want to avoid risk), Tokenized Forks, External Enforcement Dependency on yield source
Conclusion: viable for some fully onchain game applications
Intuition: Best suited for long-term games & autonomous worlds. Have to choose conservative yield sources like staked ETH. Note that $1M of annual yield at 4% requires an average of $25M principal. May need to enforce some short-term locking (ex: cannot withdraw within 24h of depositing except in emergency withdrawal cases)
Addendum: This mechanic might be able to be nested into other collection models. For example, you might have a 7-day wagered competition where all participants keep their principal and the yield is split between the winners and the collection model.
Appendix B: Tokenless Game Financialization
Gameplay Notional Boost
Explanation: What people often refer to as P2W, in the form of some resources always costing the user a fixed amount of money.
Example: Pay $10 to get 100 mana
Advantages: Technically free to play, gives late new players opportunity to advance
Disadvantages: Incentivizes devs to build a game that is only rewarding if user pay to advance/boost themselves, P2W complaints, potentially unstable econ
Susceptible: Undercut Forks (that tweak/fix broken P2W mechanics), Sybil Attacks, Tokenized Forks
Conclusion: viable for a few fully onchain game applications
Intuition: Probably not all that great for most games, even if low susceptibility. P2W mechanics can carry a heavy stigma unless executed perfectly
Gameplay Scaled Boost
Overview: What people often refer to as P2W, in the form of some resources always costing the user money that scales relative to some metric or curve.
Example: Pay $10 to fill your mana bar by 25%
Advantages: Technically free to play, keeps existing players engaged
Disadvantages: Incentivizes devs to build a game that is only rewarding if user pay to advance/boost themselves, P2W complaints, potential econ or stat inflation
Susceptible: Undercut Forks (that tweak/fix broken P2W mechanics), Account Abstraction, Tokenized Forks
Conclusion: viable for a few fully onchain game applications
Intuition: Probably not all that great for most games, even if low susceptibility. P2W mechanics can carry a heavy stigma unless executed perfectly
Global Resource Generation Fee
Overview: Whenever a player generates a certain resource necessary for gameplay, a small fee is required to be paid.
Example: Iron is necessary to build plated armor, in a game where armor degrades over its use. In order to mine Iron Ore, a player must spend 1 hr mining and additionally pay X fee per ore to collect it.
Advantages: Can curate which types of resources require payment fees to generate. Can roughly scale with player engagement.
Disadvantages: May cause players to play for optimization rather than fun, as at least one asset is anchored to external value. Requires a well-managed game economy and/or generation curve to not overinflate or disinflate the game.
Susceptible: Undercut Forks, Tokenized Forks
Conclusion: viable for some fully onchain game applications
Intuition: Best suited for long-term games & autonomous worlds. Substitutes econ collection susceptibilities for game economic design complexities. It must hit a sweet spot between being useful to gameplay, not overly inhibitive to access, and properly constrained to prevent rampant inflation/disinflation.
Internal Market Royalties/Fees
Overview: Any exchange internal to the game that somehow collects fees. Token transfer fees are also bundled into this group.
Example: Uniswap fee switch, or fee-on-transfer tokens
Advantages: Continual collection that grows with volume
Disadvantages: Incentivizes volume over value provided, high fees either dampen activity or encourage circumvention/forks, likely means that each game asset has a correlated real-world price (if you were avoiding it) and causes players to optimize over having fun
Susceptible: Account Abstraction, Wrapper Circumvention, External Competing Markets, Undercut Forks, Tokenized Forks
Conclusion: viable for some fully onchain game applications
Intuition: The game really has to deliver value to users outside of monetary/speculative means, otherwise it will likely bleed out from all of the quick forks that accelerate a hype cycle. There’s also a lot of susceptibilities about market circumvention that needs to be considered and addressed.
Appendix C: Native Token, Game Financialization
Native Tokens can get inserted in a lot of the aforementioned models, and it’d be excessive to rewrite each with a moderate addendum. Some discussion is mentioned in the earlier Tokenless vs Token-Forward and More on Undercut Forks and Tokenized Forks sections. Discussions beyond this are reluctantly pushed outside the scope of this bloated article. There is one model that doesn’t squarely fit into collection or distribution. It probably best fits in a future article expanding on Tokenless vs Token-Forward but it’s still worth mentioning here, so I’ll briefly address it:
Native Token Creation/Inflation
Explanation: Some monetizable token native to the game is created or inflated in order to be used in some distributive method later.
Advantages: Distributable value increases as native token price increases
Disadvantages: A lot, see past DeFi tokens and experiments. Creation/inflation schedules, potential governance, speculative cycles affecting activity, token value often low when you need it most, inflation erodes value of existing holders unless allocated skillfully, incentives for greediness in design
Susceptible: Tokenized Forks (copycats that mimic your success and leech activity)
Conclusion: viable for some fully onchain game applications
Intuition: The smaller in scope and governance the token can be, the better. This certainly isn’t a standalone model. However, it is a supplementary tool used by a lot of protocols.
Two examples of distribution that won’t be covered here are Governance Grants and Contract Secured Revenue (Canto’s model).