Hello and welcome to Dark Tunnels, a newsletter dedicated to exploring the emerging ecosystem of fully onchain games. Dark Tunnels is published by Always Scheming, a research consultancy focused on the future of interactive entertainment.

The following essay is Issue #6 of Dark Tunnels. It is also Part 3 of a four-part series discussing the application of business models to fully onchain games. Enjoy!

Though cryptocurrencies are relatively new in the grand scheme of business and entrepreneurship, we have already seen early builders innovating with blockchain-based business models for several years.

Given the hyper-financialized nature of web3 generally — and the financial use cases for cryptocurrencies and DeFi, specifically — it makes sense that most web3 business models today revolve around trading, holding, staking, and/or managing various tokens, both fungible and non-fungible.

“The truth is that web3 has yet to standardize its era-defining business model. The most successful applications today have relied on web2’s transaction-based models – DEXs, marketplaces, etc.”

Mason Nystrom, Variant Fund

The most common example of this in gaming and gaming-adjacent ventures has been the sale of NFTs. Typically, the developer creates a series of NFTs representing something in the game itself, such as an item, character, cosmetic, or plot of virtual land. Occasionally, developers might also release an NFT pass that entitles the holder to some future utility (e.g. token drops, playtests, access to gated communities, etc.). Others have taken the additional step of selling fungible governance or utility tokens, which can serve a variety of use cases or be cashed out of the game’s economy altogether.

Whatever the case, the business model underlying these approaches is fairly straightforward:

1. Sell some tokens

2. Bank the revenues

3. Capture a share of secondary market trading royalties or transaction fees (maybe)

4. Repeat as needed

While I am obviously generalizing, most blockchain gaming businesses would be more or less covered by these broad strokes.

Of course, that framing raises the inevitable and controversial topic of tokens in gaming. When it comes to fully onchain games, there are many operators that believe tokens must invariably be utilized as part of any business model. This is not a universal belief, however, and reasonable opinions have been expressed on both sides of the argument. [1]

Note that there is an important but nuanced distinction to be made between tokens as part of a gaming company’s business model and tokens as a part of a game itself. Though these concepts can and do often overlap, we will (for the time being) set aside any concerns over financialization of gameplay, breaking of the “magic circle,” and so forth to focus on tokens as part of a business model discussion. There are many game designers and economists who have already written extensively about the challenges posed by tokenized economies in blockchain games and we will not delve into that topic in today’s edition.

Before we can drill deeper into crypto-native business models, we must first unpack an important concept: the difference between a protocol and a product.

A protocol is simply a set of rules that governs interactions and allows for data to be shared between computers — for example, the Hypertext Transfer Protocol (HTTP) dictates how computers interact with web resources (e.g. HTML files) by transmitting “hypertext” messages between clients and servers. Bitcoin is also a protocol, as are the Domain Name System (DNS), File Transfer Protocol (FTP), and many other technobabble acronyms that you likely interact with on a daily basis, both within and outside of the world of web3.

Given that protocols are based in rules and standards, they are rarely “owned” by a singular entity. Most are open source projects developed collaboratively by multiple distributed entities. Products, on the other hand, exist to fulfill a specific need or solve a problem for users. They are designed to be consumed and are monetized accordingly. A product may be built on top of or in conjunction with protocols, but a product cannot itself be a protocol, nor vice versa.

With that said, products can and often do overlap heavily with protocols. For example, smartphones interface with protocols like Bluetooth and WiFi. GMail leverages Simple Mail Transfer Protocol (SMTP) and Internet Message Access Protocol (IMAP) to send and receive emails. Yet these products are not themselves protocols.

Companies productize underlying protocols by creating bespoke interfaces, custom extensions, or additional support services, as we discussed in Part 2. An example of this would be the MySQL Enterprise Edition, which adds services and support not present in the core open source MySQL database.

Protocols and products are frequently conflated in discussions of onchain gaming. The underlying blockchain for a given game (be it L1 or L2) is a protocol, but onchain games themselves are typically products (in the form of a bundle of smart contracts, plus a client, built on top of the blockchain protocol). While I do believe that it is possible for an onchain game (or, more likely, an autonomous world) to become a protocol itself, I have yet to see anything operational today that would fit that description.

The whole idea behind all the financialization in web3 is, in theory, incentive alignment. Users should be rewarded for their participation in and contributions to the growth of an underlying protocol. This is why, for example, blockchain validators are rewarded in native tokens or a share of transaction fees, or why liquidity providers receive UNI governance tokens for contributing funds to Uniswap.

Of course, “participation” and “contributions” can be defined in myriad ways. This makes incentive design particularly important. For example, should a provider of capital be rewarded in the same way that a provider of code, art assets, or QA services might be? And what form should those rewards take?

At the risk of derailing this discussion with a tangent on decentralized governance – a topic for a future edition, to be sure – for now, I will only say that protocols can be challenging to monetize in the sense that they are intended to be minimally extractive. This means that the profit upside typically present in a closed source scenario (e.g. a gaming startup) is not necessarily as favorable to early contributors. [2] On the other hand, the openness of protocols encourages and rewards contributions from anyone, which benefits the protocol as a whole and, vicariously, the original builders.

While I will not claim to be an expert in this field, in my research I have come across two approaches to monetization that seem promising when applied to an onchain gaming venture. The first of these involves commoditization of the initial product as a means of encouraging growth of the underlying user-owned protocol.

By creating an initial product and giving it away for free, game teams can quickly attract users, gather playtest data, document player insights, and, crucially, bootstrap network effects (a topic we discussed at length in The Inevitability of the Format). This drives value to the protocol upon which the product is built, encourages additional builders to contribute products of their own, and grows the ecosystem as a whole.

While this first product may be a game experience, it doesn’t necessarily have to be. Another approach might be to create Roblox-style UGC tooling, or an extendable front-end. Liquity Protocol, for example, rewards developers for building front-ends to their stablecoin protocol. This has interesting parallels to onchain gaming, which is inherently clientless. [3]

A second approach is to adopt a “proto-app” or “protoform” model. A portmanteau of “protocol” and “platform,” protoforms are designed to leverage the best aspects of the dominant approaches from both web2 and web3.

To quote the originator of the idea, Zora’s Jacob Horne (he of hyperstructure fame), protoforms are “the platforms built on crypto protocols, which are meaningfully different to platforms not built on crypto protocols.”

To be clear, this model is largely theoretical, but I find it promising for a few reasons.

For one, it reminds me a lot of the “Play 2 Die” model proposed by loaf, which provides a sort of platform for developers to build on top of, knowing in advance how many tokens have been escrowed (and thereby allowing for revenue forecasting). Anyone can extend the protocol by “Building 2 Kill” (i.e. developing a fun interactive experience that extracts tokens on loss), collectively contributing to a growing collection of onchain experiences that, in turn, attracts new players and thereby grows the ecosystem.

Another reason I find this protoform approach appealing is that it redirects builder attention towards the needs of the customers (players), rather than the appreciation of the protocol token. Instead of building applications that seek to make “number go up” — more AMMs and DEXs and other crypto-native tools that have little appeal to a broader gaming audience — developers will instead be incentivized to target broader use cases. In the aforementioned “Play 2 Die” scenario, this might take the form of building games for specific genres, session lengths, or play styles.

Importantly, contributors to a protoform might also be disincentivized from trying to build everything themselves, as it is comparatively easier to develop a subset of useful features and then allow others to build additional layers of functionality. To continue with our “Play 2 Die” example, it would be much more effective for multiple developers to split up the work to create leaderboards, enable game discovery, friends lists, and so on, than it would be for one team to take all of that on.

To create a proto-app is to create a gateway to all the other services in your field.

David Phelps, “The Proto-App Thesis”

1. Personally, I believe that both token and non-token approaches are viable and plan to offer more detailed thoughts in next week’s edition, where I will attempt to tie together many of the threads presented in this miniseries.

2. Protocol designers can of course set their own take rates to whatever they like, but anything deemed to be excessively extractive runs the risk of being forked and competed out of existence by rival protocols.

3. Full credit to Jesse Walden and Jonathan Glick at Variant Fund for putting forth this product commoditization approach. You can read their piece on the topic, which goes much deeper on the finer points of implementation, here.

As you’ve likely deduced from the speculative nature of this edition, there is still much left to be decided when it comes to building onchain games businesses in web3. The approaches outlined above are far from foolproof, and folks like CometShock have already written at length about the vulnerabilities inherent in some of these models.

Next week, I’ll attempt to tie together the many ideas we’ve discussed in these last three newsletters and provide some useful frameworks for thinking through onchain gaming business models.

Thanks as always for reading. If you’re enjoying the newsletter, please consider sharing it with a friend or colleague. I would tremendously appreciate it.

Special thanks to loaf and Secretive for their input on this edition.

Hello and welcome to Dark Tunnels, a newsletter dedicated to exploring the emerging ecosystem of fully onchain games. Dark Tunnels is published by Always Scheming, a research consultancy focused on the future of interactive entertainment.

The following essay is Issue #6 of Dark Tunnels. It is also Part 3 of a four-part series discussing the application of business models to fully onchain games. Enjoy!

Though cryptocurrencies are relatively new in the grand scheme of business and entrepreneurship, we have already seen early builders innovating with blockchain-based business models for several years.

Given the hyper-financialized nature of web3 generally — and the financial use cases for cryptocurrencies and DeFi, specifically — it makes sense that most web3 business models today revolve around trading, holding, staking, and/or managing various tokens, both fungible and non-fungible.

“The truth is that web3 has yet to standardize its era-defining business model. The most successful applications today have relied on web2’s transaction-based models – DEXs, marketplaces, etc.”

Mason Nystrom, Variant Fund

The most common example of this in gaming and gaming-adjacent ventures has been the sale of NFTs. Typically, the developer creates a series of NFTs representing something in the game itself, such as an item, character, cosmetic, or plot of virtual land. Occasionally, developers might also release an NFT pass that entitles the holder to some future utility (e.g. token drops, playtests, access to gated communities, etc.). Others have taken the additional step of selling fungible governance or utility tokens, which can serve a variety of use cases or be cashed out of the game’s economy altogether.

Whatever the case, the business model underlying these approaches is fairly straightforward:

1. Sell some tokens

2. Bank the revenues

3. Capture a share of secondary market trading royalties or transaction fees (maybe)

4. Repeat as needed

While I am obviously generalizing, most blockchain gaming businesses would be more or less covered by these broad strokes.

Of course, that framing raises the inevitable and controversial topic of tokens in gaming. When it comes to fully onchain games, there are many operators that believe tokens must invariably be utilized as part of any business model. This is not a universal belief, however, and reasonable opinions have been expressed on both sides of the argument. [1]

Note that there is an important but nuanced distinction to be made between tokens as part of a gaming company’s business model and tokens as a part of a game itself. Though these concepts can and do often overlap, we will (for the time being) set aside any concerns over financialization of gameplay, breaking of the “magic circle,” and so forth to focus on tokens as part of a business model discussion. There are many game designers and economists who have already written extensively about the challenges posed by tokenized economies in blockchain games and we will not delve into that topic in today’s edition.

Before we can drill deeper into crypto-native business models, we must first unpack an important concept: the difference between a protocol and a product.

A protocol is simply a set of rules that governs interactions and allows for data to be shared between computers — for example, the Hypertext Transfer Protocol (HTTP) dictates how computers interact with web resources (e.g. HTML files) by transmitting “hypertext” messages between clients and servers. Bitcoin is also a protocol, as are the Domain Name System (DNS), File Transfer Protocol (FTP), and many other technobabble acronyms that you likely interact with on a daily basis, both within and outside of the world of web3.

Given that protocols are based in rules and standards, they are rarely “owned” by a singular entity. Most are open source projects developed collaboratively by multiple distributed entities. Products, on the other hand, exist to fulfill a specific need or solve a problem for users. They are designed to be consumed and are monetized accordingly. A product may be built on top of or in conjunction with protocols, but a product cannot itself be a protocol, nor vice versa.

With that said, products can and often do overlap heavily with protocols. For example, smartphones interface with protocols like Bluetooth and WiFi. GMail leverages Simple Mail Transfer Protocol (SMTP) and Internet Message Access Protocol (IMAP) to send and receive emails. Yet these products are not themselves protocols.

Companies productize underlying protocols by creating bespoke interfaces, custom extensions, or additional support services, as we discussed in Part 2. An example of this would be the MySQL Enterprise Edition, which adds services and support not present in the core open source MySQL database.

Protocols and products are frequently conflated in discussions of onchain gaming. The underlying blockchain for a given game (be it L1 or L2) is a protocol, but onchain games themselves are typically products (in the form of a bundle of smart contracts, plus a client, built on top of the blockchain protocol). While I do believe that it is possible for an onchain game (or, more likely, an autonomous world) to become a protocol itself, I have yet to see anything operational today that would fit that description.

The whole idea behind all the financialization in web3 is, in theory, incentive alignment. Users should be rewarded for their participation in and contributions to the growth of an underlying protocol. This is why, for example, blockchain validators are rewarded in native tokens or a share of transaction fees, or why liquidity providers receive UNI governance tokens for contributing funds to Uniswap.

Of course, “participation” and “contributions” can be defined in myriad ways. This makes incentive design particularly important. For example, should a provider of capital be rewarded in the same way that a provider of code, art assets, or QA services might be? And what form should those rewards take?

At the risk of derailing this discussion with a tangent on decentralized governance – a topic for a future edition, to be sure – for now, I will only say that protocols can be challenging to monetize in the sense that they are intended to be minimally extractive. This means that the profit upside typically present in a closed source scenario (e.g. a gaming startup) is not necessarily as favorable to early contributors. [2] On the other hand, the openness of protocols encourages and rewards contributions from anyone, which benefits the protocol as a whole and, vicariously, the original builders.

While I will not claim to be an expert in this field, in my research I have come across two approaches to monetization that seem promising when applied to an onchain gaming venture. The first of these involves commoditization of the initial product as a means of encouraging growth of the underlying user-owned protocol.

By creating an initial product and giving it away for free, game teams can quickly attract users, gather playtest data, document player insights, and, crucially, bootstrap network effects (a topic we discussed at length in The Inevitability of the Format). This drives value to the protocol upon which the product is built, encourages additional builders to contribute products of their own, and grows the ecosystem as a whole.

While this first product may be a game experience, it doesn’t necessarily have to be. Another approach might be to create Roblox-style UGC tooling, or an extendable front-end. Liquity Protocol, for example, rewards developers for building front-ends to their stablecoin protocol. This has interesting parallels to onchain gaming, which is inherently clientless. [3]

A second approach is to adopt a “proto-app” or “protoform” model. A portmanteau of “protocol” and “platform,” protoforms are designed to leverage the best aspects of the dominant approaches from both web2 and web3.

To quote the originator of the idea, Zora’s Jacob Horne (he of hyperstructure fame), protoforms are “the platforms built on crypto protocols, which are meaningfully different to platforms not built on crypto protocols.”

To be clear, this model is largely theoretical, but I find it promising for a few reasons.

For one, it reminds me a lot of the “Play 2 Die” model proposed by loaf, which provides a sort of platform for developers to build on top of, knowing in advance how many tokens have been escrowed (and thereby allowing for revenue forecasting). Anyone can extend the protocol by “Building 2 Kill” (i.e. developing a fun interactive experience that extracts tokens on loss), collectively contributing to a growing collection of onchain experiences that, in turn, attracts new players and thereby grows the ecosystem.

Another reason I find this protoform approach appealing is that it redirects builder attention towards the needs of the customers (players), rather than the appreciation of the protocol token. Instead of building applications that seek to make “number go up” — more AMMs and DEXs and other crypto-native tools that have little appeal to a broader gaming audience — developers will instead be incentivized to target broader use cases. In the aforementioned “Play 2 Die” scenario, this might take the form of building games for specific genres, session lengths, or play styles.

Importantly, contributors to a protoform might also be disincentivized from trying to build everything themselves, as it is comparatively easier to develop a subset of useful features and then allow others to build additional layers of functionality. To continue with our “Play 2 Die” example, it would be much more effective for multiple developers to split up the work to create leaderboards, enable game discovery, friends lists, and so on, than it would be for one team to take all of that on.

To create a proto-app is to create a gateway to all the other services in your field.

David Phelps, “The Proto-App Thesis”

1. Personally, I believe that both token and non-token approaches are viable and plan to offer more detailed thoughts in next week’s edition, where I will attempt to tie together many of the threads presented in this miniseries.

2. Protocol designers can of course set their own take rates to whatever they like, but anything deemed to be excessively extractive runs the risk of being forked and competed out of existence by rival protocols.

3. Full credit to Jesse Walden and Jonathan Glick at Variant Fund for putting forth this product commoditization approach. You can read their piece on the topic, which goes much deeper on the finer points of implementation, here.

As you’ve likely deduced from the speculative nature of this edition, there is still much left to be decided when it comes to building onchain games businesses in web3. The approaches outlined above are far from foolproof, and folks like CometShock have already written at length about the vulnerabilities inherent in some of these models.

Next week, I’ll attempt to tie together the many ideas we’ve discussed in these last three newsletters and provide some useful frameworks for thinking through onchain gaming business models.

Thanks as always for reading. If you’re enjoying the newsletter, please consider sharing it with a friend or colleague. I would tremendously appreciate it.

Special thanks to loaf and Secretive for their input on this edition.