We’ve seen various combinations of NFT (ERC721) auctions, ERC20 airdrops, open sales of both, tiered access to the open sales, etc. - all under the guise of making you a “member of the community”. Some have worked well, while others have been flaming piles of garbage.
I believe each monetization method has its place, but we need to be more intentional about:
who in the community they’re targeting
how they’re composed together
In this piece, I want to propose some frameworks and implementation tools/examples for monetizing membership across clusters in a community.
I recommend reading my previous piece on the membership stack (defined as
access → permissions → status) for some background. That piece is focused on what can be built on top of tokens, this one is focused on how the tokens get into the community.
Note that I use the words sale/monetization/distribution interchangeably throughout this piece.
There are tons of ways to visualize a token community’s social circles, usually shown in the way Brian has illustrated below as an “anatomy”:
I think this is a good framework for approaching any community, but we can take it further. Let’s start with the building blocks of a web2 corporate structure:
Stock: “known as equity, is a security that represents the ownership of a fraction of the issuing corporation”
Governance: defined here as public-facing decisions, so mainly assigning board seats and other related shareholders proposals.
Service: the core business output(s) of the company
I’ll admit that this is a very US-centric/capitalist view that may not translate well to everyone reading this, but it should still make sense at a high level. We can see how various stakeholders are defined across stock, corporate governance, and the business itself.
There’s a ton of inefficiency and misalignment across all groups here due to resource, time, information, and permission constraints (if you want a short primer this book is a really good summary).
Now let’s redefine these circles for a web3 community:
Tokens: the building blocks of ownership; these can be community-specific or something more general. Usually a combination of ERC20 and ERC721 standards. Does not have to represent equity.
Governance: a contract or set of contracts that collect and manage incoming token revenue/contributions. Usually some combination of a multi-sig and a governor contract (propose, queue, vote, execute).
Service: tokens alone don’t create a service - normally the service is built separately and integrated (hopefully enhanced) by tokens + governance. Some examples:
Water & Music services include database access + special reports. Tokens are used and distributed in various ways, including airdrops and open sales.
NounsDAO (and affiliates) services are capital allocation (in the form of Prop House). Tokens are auctioned off periodically and used for governance.
Putting it together we get:
these groups aren’t always mutually exclusive
It might seem like it’s just wordsmithing and all these words represent the same web2 groups as earlier - and to an extent you’re right. However, Web2 corporates run on sluggish tech (lol banks), are mostly human-operated (excel and ppt input goes brrr), and have little capital raising flexibility (due to legal structures). Web3 communities move as fast as transactions get confirmed, can be augmented by smart contracts, and have flexible tokens (not tied to equity, and have programmable distribution + supply mechanics).
This all adds up to make the behaviors enabled of each web3 community segment really different from their web2 counterparts!
Because of the malleability of the web3 infrastructure stack, it isn’t immediately clear what tokens should represent what and how they should be distributed to the community. In the last few years, we’ve seen a slew of attempts that independently use different monetization methods - from airdrops to auctions, some immediate and others time or round-based.
“Membership” has been the main utility lauded by tons of projects, alongside some opaque roadmap. Besides being a smart marketing tactic, using a membership-based perspective does provide clarity on how to distribute/leverage tokens across a community.
Let’s first map the membership stack on top of the community circles:
Tokens <> Access: You typically need to own core community tokens to access anything within a community. Other segments will still interact with these core tokens, but in a secondary/vertical manner instead.
Governance <> Permissions: There have been all sorts of explorations around on-chain governance that play with levels of permissioning, and use a combination of ownership and delegation.
Service <> Status: Status applies most closely to anyone who is using or building the service itself. Tiers and levels are what we want to capture here.
Now we layer different monetization methods across each segment:
Personally in love with all these tools and teams ❤️
Let’s start with the three groups that are more “benefactors” than “builders” of the community. These groups should have as simple a system as possible since they are unlikely to have continuous context.
Supporters/Investors <> Edition Sales: This largely homogenous group has capital they want to allocate purely for investment or public good purposes.
Fixed editions help to reach some one-time funding goal and quickly sell a set supply of NFTs (Mirror) without taking away too much time and attention from the community or the funders. If no funding goal is set, then you can do a time-limited supply as Pooly NFTs did.
Power Users/DAO Partners <> Fractional NFTs: These are users who want to shape the service in some way that benefits them/their products. There’s a limited number of partners you can realistically take on (marginal benefit decreases at some point), but you still want to tier them so set supply/price edition sales don’t make sense.
So for example, let’s take the NounsDAO prop house which operates weekly and has some level of topic segmentation. Assume there are a few large DAOs who want to integrate with Nouns in some way - instead of what we’ve typically seen with large treasury swaps or open market buying of tokens, these large DAOs could join a single party bid on a “seasonal partnership NFT”. As a start, holding these tokens could act as a simple multiplier when proposals go to vote.
This works better than something like a Dutch auction because prices are decided competitively versus some monotonically decreasing - and all parties are guaranteed to get some allocation. You can set some threshold of # of tokens you need to qualify for a prop house proposal and anyone who doesn’t make it can carry on (swap) their tokens in the next party bid. If you add in
These next four groups are all “builders”, focused on building and governing the service and community. These groups should have more context generally, so we can make their systems more complex.
Treasury Managers + Grant Proposers <> Permissioned NFT Auctions: These are token holders who want an immediate and larger say in the community, so usually governance is the best next step for them.
I’ve started becoming a bigger believer in gradually scaling governance (NounsDAO) versus airdrop + delegate kickoff governance (literally every other protocol). Doing an airdrop + delegate kickoff is like taking a ton of caffeine all at once - your community will be super energized but constantly clashing against each other for attention and funds for a long time to find equilibrium.
Instead, if you “release” governance power over time you can allow the most interested and motivated parties to continuously buy in. Uninterested parties will just slowly unwind their tokens in secondary markets, which will become a smoother process as NFT AMMs (sudoswap) and aggregators (Genie) improve. We’ll take a deeper data dive into this in the next section.
Even bribes/loans which are popular for ERC20 governance tokens are becoming possible to replicate with NFTs through innovations like the new renting module from Fractional.art.
DAO Operators <> Delegated Permissioned NFTs: DAO operators are insanely important and they need better ways to manage all the chaos. Unlike the auctioned NFTs above where each one gives you the same weight/powers, these NFTs should have much more specific permissions which are granted.
I think there are two approaches that make sense here:
Setting up governance pods (Orca) that can be adjusted.
And last but not least, our tokenomic favorites:
everyone <> airdrops and staking: I believe these methods do apply to all community segments - but need to be experimented with and tiered accordingly.
Airdrops will likely become more round-based (like Optimism) and targeted towards either specific community segments (Water & Music $STREAM) or community structures (community reputation score $WRITE). Coinvise is a great tool for executing this.
Staking should be applied to something like reputation staking around key decisions, especially longer time-horizon ones (Koop).
Whew - that was dense! If you have any suggestions or arguments on stuff I’ve missed, please reach out because I’d love to discuss them.
There’s still one big elephant in the room - who is going to manage and implement all these methods? There are already some ongoing interesting experiments we can study to build monitoring metrics for “monetization overhead”.
We now have a cleaner way of segmenting our communities and some preferred monetization methods to go along with each one. It’s worth mentioning that there are some all-in-one-token approaches that look promising for starter communities. Scaling membership and community in sync is a topic I’m very interested in, and will be keeping a close eye on for the next year or so.
And with scaling membership comes the increasing complexity of managing implementations. A good start would be creating monitoring metrics for “monetization overhead”. This is separate from “contract/token composability overhead”, which is a contract architecture issue that will just take many iterations to get right. Contract modules have already been implemented in evolving fashion to make it easier to add management capabilities to tokens, such as gnosis zodiac, default core OS, tributeDAO, and fractional V2 modules. Various interfaces are being created to make it easier and easier to compose and deploy contracts too.
Monetization overhead is focused on the social elements, such as noise, frequency, and energy within the context of token interactions. An example of bad overhead is a large about of ETH requested in governance proposals multiple times a month (high noise + frequency), where voter turnout is minimal (low energy). There’s likely some combination of metrics unique to each monetization method that would make it much easier to monitor over time. Layering these metrics upon something like Forefront Terminal could further enhance operator understanding of the community health.
These metrics would also eventually help tune on-chain parameters such as quorum and minimum proposal thresholds. Instead of static thresholds, I’d imagine we’d scale thresholds based on noise levels:
You could make things independent and linear: For every additional 1% of treasury requested in just this proposal, 1 more permissioned NFT is required by the proposer.
Or you could make it dependent and non-linear: For every additional 1% of treasury requested in total across the proposal queue, we could use n^2 - (n-1)^2 additional NFTs required where n = total % treasury requested in the queue . So if 5% of the treasury is already being requested and you’re requesting 1% in your proposal, then 11 more NFTs are required (36 - 25).
There are plenty of interesting experiments such as NounsDAO already happening for us to study, and I have more fun news coming next month regarding how I’d like to engage the data community as a whole to study this deeper.
But for now, that’s a wrap! Please challenge me and let me know where you think differently (or where I’ve missed something).
I really do appreciate each and every one of you who read this far. If you’d like to support more of this kind of writing then don’t forget to collect this entry, subscribe, and share! 😊
For power users of your service, you could imagine that what they’re bidding on is an extra “tier” of technical support for a season (3 months). Some simple composability would be using your fractional “tier” multiplied by your streaming rate as a method of “locking in a contract”. Typically longer-term contracts for a service come with a lump sum payment + monthly scaling extra costs and have an array of discounts. This web3 version combines a large bid w/ payments streams, and then could calculate scaling discounts as a factor of the two.
Normie Users <> Token Streams: These users just want to use the core part of your service, so you want the experience for both them buying in and you managing payments to be as seamless as possible (so no auctions or bidding lol).
Assuming you’re some X-as-a-service provider, I believe that streaming tokens (SuperfluidHQ) are the strongest access solution because you can control the rate required (tokens paid per second/block). Streams are also highly composable with each other because of their asynchronous nature (combining streams for group access or varied requirements) and can be enhanced by mapping to dynamic identity solutions across the space (collab.land). This is much better for managing large groups of people than lump-sum payments or static POAPs. It’s worth mentioning that checking the current rate, adjusting the rate, or adjusting the rate requirement are each only one action - super easy to manage and communicate!
Obviously, this one varies a lot depending on the service, and wouldn’t apply as well to fee-based models.
DAO constitutions and manifestos have become increasingly important as a guiding framework for DAOs with growing complexity across tokens, governance, and services. This is a perfect use case for an on-chain tied language document (OpenLaw example). Adding editing permissions (through NFTs) to both on-chain parameters and accompanying off-chain language will make rules and operations much more flexible and easily understood (as opposed to forcing people to dig through old proposals and forums to track changes in both the parameters and the rationale).
Niche Contributors <> SBT and Credit: For contributors who pop in and out of various communities and contribute where they can, building a credit system is a benefit for both the contributors and the community at large.
We could expect it to be built with a simple scorecard system that’s level-based (Backed), using soulbound tokens. Once you have a basic score system, you could then utilize peer-to-peer undercollateralized lending. Union protocol is a great example of this, where contributors could gain delegated access to portions of the DAO’s treasury.
The undercollateralized loan is “secured” by the symbiotic working relationship between the contributor and the DAO - assuming the contributor’s work is useful and the service continues to do well.
Core Contributors <> Passport: These are your main “employees”. This group should get identity “passports” that are stronger (more complex) than the basic credit systems niche contributors get.
The key difference between the passport and basic SBTs is their direct integration with all layers of the DAOs operating system. The deck in the previous link explains it much better than I can; I highly recommend taking a look!
We’ve seen various combinations of NFT (ERC721) auctions, ERC20 airdrops, open sales of both, tiered access to the open sales, etc. - all under the guise of making you a “member of the community”. Some have worked well, while others have been flaming piles of garbage.
I believe each monetization method has its place, but we need to be more intentional about:
who in the community they’re targeting
how they’re composed together
In this piece, I want to propose some frameworks and implementation tools/examples for monetizing membership across clusters in a community.
I recommend reading my previous piece on the membership stack (defined as
access → permissions → status) for some background. That piece is focused on what can be built on top of tokens, this one is focused on how the tokens get into the community.
Note that I use the words sale/monetization/distribution interchangeably throughout this piece.
There are tons of ways to visualize a token community’s social circles, usually shown in the way Brian has illustrated below as an “anatomy”:
I think this is a good framework for approaching any community, but we can take it further. Let’s start with the building blocks of a web2 corporate structure:
Stock: “known as equity, is a security that represents the ownership of a fraction of the issuing corporation”
Governance: defined here as public-facing decisions, so mainly assigning board seats and other related shareholders proposals.
Service: the core business output(s) of the company
I’ll admit that this is a very US-centric/capitalist view that may not translate well to everyone reading this, but it should still make sense at a high level. We can see how various stakeholders are defined across stock, corporate governance, and the business itself.
There’s a ton of inefficiency and misalignment across all groups here due to resource, time, information, and permission constraints (if you want a short primer this book is a really good summary).
Now let’s redefine these circles for a web3 community:
Tokens: the building blocks of ownership; these can be community-specific or something more general. Usually a combination of ERC20 and ERC721 standards. Does not have to represent equity.
Governance: a contract or set of contracts that collect and manage incoming token revenue/contributions. Usually some combination of a multi-sig and a governor contract (propose, queue, vote, execute).
Service: tokens alone don’t create a service - normally the service is built separately and integrated (hopefully enhanced) by tokens + governance. Some examples:
Water & Music services include database access + special reports. Tokens are used and distributed in various ways, including airdrops and open sales.
NounsDAO (and affiliates) services are capital allocation (in the form of Prop House). Tokens are auctioned off periodically and used for governance.
Putting it together we get:
these groups aren’t always mutually exclusive
It might seem like it’s just wordsmithing and all these words represent the same web2 groups as earlier - and to an extent you’re right. However, Web2 corporates run on sluggish tech (lol banks), are mostly human-operated (excel and ppt input goes brrr), and have little capital raising flexibility (due to legal structures). Web3 communities move as fast as transactions get confirmed, can be augmented by smart contracts, and have flexible tokens (not tied to equity, and have programmable distribution + supply mechanics).
This all adds up to make the behaviors enabled of each web3 community segment really different from their web2 counterparts!
Because of the malleability of the web3 infrastructure stack, it isn’t immediately clear what tokens should represent what and how they should be distributed to the community. In the last few years, we’ve seen a slew of attempts that independently use different monetization methods - from airdrops to auctions, some immediate and others time or round-based.
“Membership” has been the main utility lauded by tons of projects, alongside some opaque roadmap. Besides being a smart marketing tactic, using a membership-based perspective does provide clarity on how to distribute/leverage tokens across a community.
Let’s first map the membership stack on top of the community circles:
Tokens <> Access: You typically need to own core community tokens to access anything within a community. Other segments will still interact with these core tokens, but in a secondary/vertical manner instead.
Governance <> Permissions: There have been all sorts of explorations around on-chain governance that play with levels of permissioning, and use a combination of ownership and delegation.
Service <> Status: Status applies most closely to anyone who is using or building the service itself. Tiers and levels are what we want to capture here.
Now we layer different monetization methods across each segment:
Personally in love with all these tools and teams ❤️
Let’s start with the three groups that are more “benefactors” than “builders” of the community. These groups should have as simple a system as possible since they are unlikely to have continuous context.
Supporters/Investors <> Edition Sales: This largely homogenous group has capital they want to allocate purely for investment or public good purposes.
Fixed editions help to reach some one-time funding goal and quickly sell a set supply of NFTs (Mirror) without taking away too much time and attention from the community or the funders. If no funding goal is set, then you can do a time-limited supply as Pooly NFTs did.
Power Users/DAO Partners <> Fractional NFTs: These are users who want to shape the service in some way that benefits them/their products. There’s a limited number of partners you can realistically take on (marginal benefit decreases at some point), but you still want to tier them so set supply/price edition sales don’t make sense.
So for example, let’s take the NounsDAO prop house which operates weekly and has some level of topic segmentation. Assume there are a few large DAOs who want to integrate with Nouns in some way - instead of what we’ve typically seen with large treasury swaps or open market buying of tokens, these large DAOs could join a single party bid on a “seasonal partnership NFT”. As a start, holding these tokens could act as a simple multiplier when proposals go to vote.
This works better than something like a Dutch auction because prices are decided competitively versus some monotonically decreasing - and all parties are guaranteed to get some allocation. You can set some threshold of # of tokens you need to qualify for a prop house proposal and anyone who doesn’t make it can carry on (swap) their tokens in the next party bid. If you add in baskets with Fractional.art, you could get some really fun combinations across houses.
For power users of your service, you could imagine that what they’re bidding on is an extra “tier” of technical support for a season (3 months). Some simple composability would be using your fractional “tier” multiplied by your streaming rate as a method of “locking in a contract”. Typically longer-term contracts for a service come with a lump sum payment + monthly scaling extra costs and have an array of discounts. This web3 version combines a large bid w/ payments streams, and then could calculate scaling discounts as a factor of the two.
Normie Users <> Token Streams: These users just want to use the core part of your service, so you want the experience for both them buying in and you managing payments to be as seamless as possible (so no auctions or bidding lol).
Assuming you’re some X-as-a-service provider, I believe that streaming tokens (SuperfluidHQ) are the strongest access solution because you can control the rate required (tokens paid per second/block). Streams are also highly composable with each other because of their asynchronous nature (combining streams for group access or varied requirements) and can be enhanced by mapping to dynamic identity solutions across the space (collab.land). This is much better for managing large groups of people than lump-sum payments or static POAPs. It’s worth mentioning that checking the current rate, adjusting the rate, or adjusting the rate requirement are each only one action - super easy to manage and communicate!
Obviously, this one varies a lot depending on the service, and wouldn’t apply as well to fee-based models.
These next four groups are all “builders”, focused on building and governing the service and community. These groups should have more context generally, so we can make their systems more complex.
Treasury Managers + Grant Proposers <> Permissioned NFT Auctions: These are token holders who want an immediate and larger say in the community, so usually governance is the best next step for them.
I’ve started becoming a bigger believer in gradually scaling governance (NounsDAO) versus airdrop + delegate kickoff governance (literally every other protocol). Doing an airdrop + delegate kickoff is like taking a ton of caffeine all at once - your community will be super energized but constantly clashing against each other for attention and funds for a long time to find equilibrium.
Instead, if you “release” governance power over time you can allow the most interested and motivated parties to continuously buy in. Uninterested parties will just slowly unwind their tokens in secondary markets, which will become a smoother process as NFT AMMs (sudoswap) and aggregators (Genie) improve. We’ll take a deeper data dive into this in the next section.
Even bribes/loans which are popular for ERC20 governance tokens are becoming possible to replicate with NFTs through innovations like the new renting module from Fractional.art.
DAO Operators <> Delegated Permissioned NFTs: DAO operators are insanely important and they need better ways to manage all the chaos. Unlike the auctioned NFTs above where each one gives you the same weight/powers, these NFTs should have much more specific permissions which are granted.
I think there are two approaches that make sense here:
Setting up governance pods (Orca) that can be adjusted. Delegating NFTs from the DAO treasury instead of just gifting them ensures representatives don’t become too comfortable or complacent.
DAO constitutions and manifestos have become increasingly important as a guiding framework for DAOs with growing complexity across tokens, governance, and services. This is a perfect use case for an on-chain tied language document (OpenLaw example). Adding editing permissions (through NFTs) to both on-chain parameters and accompanying off-chain language will make rules and operations much more flexible and easily understood (as opposed to forcing people to dig through old proposals and forums to track changes in both the parameters and the rationale).
Niche Contributors <> SBT and Credit: For contributors who pop in and out of various communities and contribute where they can, building a credit system is a benefit for both the contributors and the community at large.
We could expect it to be built with a simple scorecard system that’s level-based (Backed), using soulbound tokens. Once you have a basic score system, you could then utilize peer-to-peer undercollateralized lending. Union protocol is a great example of this, where contributors could gain delegated access to portions of the DAO’s treasury.
The undercollateralized loan is “secured” by the symbiotic working relationship between the contributor and the DAO - assuming the contributor’s work is useful and the service continues to do well.
Core Contributors <> Passport: These are your main “employees”. This group should get identity “passports” that are stronger (more complex) than the basic credit systems niche contributors get.
The key difference between the passport and basic SBTs is their direct integration with all layers of the DAOs operating system. The deck in the previous link explains it much better than I can; I highly recommend taking a look!
And last but not least, our tokenomic favorites:
everyone <> airdrops and staking: I believe these methods do apply to all community segments - but need to be experimented with and tiered accordingly.
Airdrops will likely become more round-based (like Optimism) and targeted towards either specific community segments (Water & Music $STREAM) or community structures (community reputation score $WRITE). Coinvise is a great tool for executing this.
Staking should be applied to something like reputation staking around key decisions, especially longer time-horizon ones (Koop).
Whew - that was dense! If you have any suggestions or arguments on stuff I’ve missed, please reach out because I’d love to discuss them.
There’s still one big elephant in the room - who is going to manage and implement all these methods? There are already some ongoing interesting experiments we can study to build monitoring metrics for “monetization overhead”.
We now have a cleaner way of segmenting our communities and some preferred monetization methods to go along with each one. It’s worth mentioning that there are some all-in-one-token approaches that look promising for starter communities. Scaling membership and community in sync is a topic I’m very interested in, and will be keeping a close eye on for the next year or so.
And with scaling membership comes the increasing complexity of managing implementations. A good start would be creating monitoring metrics for “monetization overhead”. This is separate from “contract/token composability overhead”, which is a contract architecture issue that will just take many iterations to get right. Contract modules have already been implemented in evolving fashion to make it easier to add management capabilities to tokens, such as gnosis zodiac, default core OS, tributeDAO, and fractional V2 modules. Various interfaces are being created to make it easier and easier to compose and deploy contracts too.
Monetization overhead is focused on the social elements, such as noise, frequency, and energy within the context of token interactions. An example of bad overhead is a large about of ETH requested in governance proposals multiple times a month (high noise + frequency), where voter turnout is minimal (low energy). There’s likely some combination of metrics unique to each monetization method that would make it much easier to monitor over time. Layering these metrics upon something like Forefront Terminal could further enhance operator understanding of the community health.
These metrics would also eventually help tune on-chain parameters such as quorum and minimum proposal thresholds. Instead of static thresholds, I’d imagine we’d scale thresholds based on noise levels:
You could make things independent and linear: For every additional 1% of treasury requested in just this proposal, 1 more permissioned NFT is required by the proposer.
Or you could make it dependent and non-linear: For every additional 1% of treasury requested in total across the proposal queue, we could use n^2 - (n-1)^2 additional NFTs required where n = total % treasury requested in the queue . So if 5% of the treasury is already being requested and you’re requesting 1% in your proposal, then 11 more NFTs are required (36 - 25).
There are plenty of interesting experiments such as NounsDAO already happening for us to study, and I have more fun news coming next month regarding how I’d like to engage the data community as a whole to study this deeper.
But for now, that’s a wrap! Please challenge me and let me know where you think differently (or where I’ve missed something).
I really do appreciate each and every one of you who read this far. If you’d like to support more of this kind of writing then don’t forget to collect this entry, subscribe, and share! 😊
Share Dialog
Share Dialog
Subscribe to vim
Subscribe to vim
<100 subscribers
<100 subscribers
No activity yet