Having a token brings a community together loosely with a financial stake, but composable membership holds a community together long term with social capital. That's a lot of buzzwords, so let’s explore this in three parts:

1. How access, permissions, and status are the primary components of membership (and the role of tokens)
2. Membership in Web2 versus Web3 platforms, and why composability matters here
3. Designing a membership system to generate social capital

Access, Permissions, and Status

Our data and actions give us identity and relationships, but having a social graph does not give you community. Put in a Web3 context, a group of people holding or trading the same token does not mean you are a community - at best, it gives you clusters. **An actual community has fairly clear boundaries for growth (in more than a financial sense). You've probably seen some variation on the chart below...

... where you can identify your core contributors, and try to reward or incentivize them accordingly. Pet3rpan has put this concentric community chart nicely in a Web3 context, showcasing the funnel of activities a participant might engage in during their lifecycle in a community:

But just because someone has participated in any of the above events, doesn't mean they feel like they're part of the community. Even giving them tokens for their participation doesn't really move the needle.

Tokens are open primitives that membership should be built upon, and just issuing more POAPs or tokens based on events and then moving on is like distributing the raw materials for a house and expecting the people to build up a town. Without a blueprint, people will just stash the materials and leave (or sell them to someone else). In crypto, we’re supply rich, but guidance poor.

Some communities at least take the first step to have some sort of access dependent on your token activities, usually a Discord server or channel. But access is only the first step to membership. Permissions are too closely tied to access right now, and status is left as too abstract a concept.

So let's improve on the current model. Access is discovery, permissions are responsibility, status is weight. This membership funnel is shaped different from the activity funnel above, as the customizable design area gets larger the deeper you go:

These are basic examples, but they help lay the groundwork for how each layer could be tied to different types (and combinations) of tokens. Let's look at some token design examples for each level:

• Access: For the most part, ERC20's are best for access because requirements are fluid and the tokens are more liquid. Today I might require 50 tokens to join, but in the future, I may drop it to 25 or increase it to 75 based on community needs (going wide versus deep). NFTs are cultural assets, so if you use that as the gate then it'll be tough to say you need two or more to have access now. Even if you implement project derivatives, liquidity becomes fragmented and confusing. This is project-dependent though, and Creator Cabins did a great overview of some of the tradeoffs.
• Permissions: I personally believe permissions should be tightly coupled to a stake. To be given the responsibility for some set of actions, there should be risk involved. Unlike access, permissions should evolve and can be revoked. If I'm making proposals, allowing staking will show my commitment and also give others the opportunity of joining my stake. This line of design can help a community better balance abuse of power and opportunities for discovery (of great new contributors).
• Status: This layer has the largest area because it is tied to attributes and metadata. Status in a community has the highest amount of variance, as it will likely be event-dependent. Taking the treasury "weighted voting power" example, if you give status based on what is being voted on that highlights specific community members while also ensuring that it isn't always the participant with the most tokens has the most sway. NFTs are a great place to play with these attributes, especially through derivative and forge-based projects. To clarify, this is not the same as reputation since reputation needs to be less fluid as to not confuse people. We'll get more into that later.

Different combinations of these layers could be bundled into "roles" for easier management and assignment. I'd love to dive right into a membership system, but first we need to clear out the current mental heuristics around how Web2 "membership" works.

Composable Membership and the Role of Platforms (Web2 vs Web3)

In Web2, membership forms around services. In Web3, services from around membership. Put simply, being a YouTube subscriber does not affect your privileges when engaging in a Twitch chat or a subreddit. This kind of membership interoperability is certainly possible in Web2, and I think Patreon was the closest to getting a hierarchical membership structure in place. We could have seen a world that looks like this:

But obvious arguments would ensue over who owns the master API, and economic flow incentives also act as a blocker since the platform at the top of the hierarchy likely has the highest money-in/money-out flow and take-rate. So in the end we have like 7 or more different memberships to manage! No one actually wants that besides the platforms themselves.

In Web3, no one is fighting to be at the top of the membership hierarchy because the primitives (tokens) aren't owned by any one platform. Smart contracts are our APIs and we can code revenue splits right into them. If that isn't enough, we can devise governance and attribution systems over the treasury to ensure the services and tooling built around membership continuously benefits communities that rely on them. In the end, the above Web2 platforms will naturally fall lower on the hierarchy. They will be forced to fit around the composable membership systems that we all enable and create. In other words, the community is the platform:

There's an argument to be made that in the end, apps will just be a bunch of composable components where each piece is owned by a different platform. But in the interim, it'll be Web3 communities plugging into the currently better interfaces of Web2. When planning a membership system, we'll need to think about membership as bundles of access, permission, and status across these Web2 services. If I'm a multisig member, what roles will I need across all these services and how can that be managed in a single token/membership model? To figure this out, we'd need to experiment. And to experiment, we need social capital.

A Membership System for Generating Social Capital

We've defined the components of membership and situated them within the Web2 and Web3 context. Now, let's have fun designing a system that could actually go into implementation. We'll define social capital as building an allowance for trust, experimentation, and flexibility within a community. This means having a membership system that improves ownership of decisions and prevents a social fork. For now, my guess is there are three main steps to execute membership and generate this new capital:

1. Define Roles: Roles are bundles of the different layers of membership and are tied to specific participant personas. There are likely hundreds of combinations (especially if you layer token types on top), but some immediate roles that come to mind are:

   • Low Access (ERC20) + Low Permissions (ERC20 Stake) = new member
   • High Permissions (ERC20 Stake) + High Status (NFT) = long time contributor
   • High Access (NFT) + High Status (NFT) = subject matter expert
   • High Access (ERC20) + High Permissions (ERC20 Stake) + High Status (NFT) = founding member

   Doing this well opens up a pathway for growth and also clarity for all members. This starts to give us history too, as I can clearly see how a community has matured by its role definitions and distribution (much more so than if I just look at the token price).

2. Specify Incentivizes: Pet3rpan mentioned in the article linked earlier that trust and engagement are key to participation. Financial incentives are a great starting point - if you airdropped me $1000 of your community's tokens, I'd definitely come to take a look and see what I can help with. But if these drops/bounties are filtered by role or membership history, we can be much more flexible with asks and rewards and I'd likely feel more fulfilled. This is the difference between me tackling a data bounty as a nobody versus as a Dune Wizard.

   This could also look like a hackathon where teams are built based on role/membership history, such that newer members are matched with older members. Or imagine if hackathon bounties rewarded community roles instead of just $$$, I think we'd end up seeing an even larger diversity of projects and teams in hackathons than we do today.

   Also, I cannot stress enough the importance of history here. Membership + Identity + Relationships will probably be the best proxy for a reputation score, which opens up the path to more creatively weighted incentives.

3. Assign Roles: This step is more technically difficult than the others, given the challenge of plugging membership systems into existing platforms. I think this is similar to the integration problems that any wallet aggregator already faces, for example, Zapper's protocol requests. Integrating into existing Web2 platforms shouldn't be difficult, but as more Web3 platforms are built the composability will be difficult to manage.

   But as long as we have an identity solution (connecting addresses to user metadata across platforms) and a membership solution (managing roles and tokens intuitively), I think we'll be able to tackle the platform integration problem elegantly. Besides, building the first two will take the ecosystem the next six months anyway.

Hopefully, this system helps show how much we can bring a community together while experimenting by using membership built off of tokens. I know for some people this is all still too fluffy, so I plan on doing data-driven case studies to better inform this kind of membership system in the future (and to try to be more quantitative about social capital). Some communities I'm interested in studying under this lens are Yearn, Blitmaps, and Superfluid - but if you have other case studies that come to mind, please do let me know.

Concluding Thoughts

Composable membership shapes more than just communities, it will shape ecosystems and platforms as well. In crypto, we're all building platforms that give communities the tooling for implementation, visibility, collaboration, and much more. Ecosystems are forming around metadata already, and this will force a reorganization of Web2 platforms to provide a much more open surface to be built upon.

Mirror is one platform trying to improve the tooling for communities to implement a rewarding membership system:

Seed Club is a good example of the model above, where they deploy ERC20 tokens for specific communities and causes, and once members are more defined they move on to specialized token distribution methods such as the token race for engaging the community and adding new cohorts. I think there is a lot more we all can do to standardize the membership implementation process laid out in this article, using Mirror and ecosystem tooling.

But none of what I've written about can sustainably happen unless communities take their thinking around membership more seriously (and that goes for me too). If any of this interests you, please reach out so that we can build out this future together. My twitter DMs are always open! 🙂