Token-Gated Community Management in Status 2.0

Exploring our decentralised solution for Status Community management.

Previously, we discussed tokenised Community ownership in Status 2.0, which enables Status Community Owners to securely transfer ownership responsibilities to a new Owner as easily as moving any other blockchain token. This blog post highlights another extremely powerful feature — token-gated permissions for Status Communities and Community channels.

Status 2.0 introduces a sophisticated and entirely decentralised Community management system. This token-based permissions system functions without reliance on any centralised infrastructure, guaranteeing that Status Community owners have complete sovereignty over their Community and which members can perform specific tasks within it.

In this article, you’ll discover how token-gated permissions work, how they leverage Community tokens minted within Status, and how they can bring new utility to existing tokens based on Ethereum and supported L2s.

Status Communities and Community Channels

Before diving into token-gated permissions and how they relate to Status Communities and Community channels (herein referred to as simply Communities and channels), we should first explain what we mean by Communities and channels.

In many ways, Communities are like Discord servers. They’re digital spaces where online groups forming around different interests can gather, share ideas, and spend time together. A Community might be quite intimate and small, revolving around a friendship group or set of work colleagues, or it might be very large if it’s a group for fans of a popular musician, sports team, or pastime.

While this framing should help newcomers understand Communities, it doesn’t account for the many differences between Communities and Discord servers. Perhaps the most striking are:

Community Owners and those users to whom they delegate management responsibilities have complete control over their Community — no other entity, including Status, can shut them down or censor them.
Status 2.0 is a blockchain-based platform, meaning Communities benefit from many native tokenisation functions, including the token-gated permissions this blog discusses.

Channels are subdivisions within a Community devoted to specific topics relevant to the Community. To extend the previous examples, a Community of friends might have a channel called ‘Weekend plans’ in which they discuss ideas for activities to do at the weekend, and a Community of colleagues might have a channel called ‘Marketing’ to discuss marketing initiatives. Meanwhile, an angling Community might have channels dedicated to different types of fishing, for example, a ‘Sea fishing’ channel and a ‘Competition fishing’ channel.

Community Roles

Managing a large Community can be a lot of work. Therefore, the Community Owner can delegate responsibilities to whichever members they choose by assigning roles.

Roles determine which actions members can perform within the Community. In Status 2.0, there are four Community roles:

Member
Admin
TokenMaster
Community Owner

Member

Upon joining a Community, a Status user becomes a Community member. By default, a member has no special permissions. However, depending on how the Community is set up, the tokens they hodl in their wallet might enable them to view or post in channels other members cannot — more on this later.

Community members can:

View channels for which they meet the token-gating requirements.
Send messages, images, GIFs, and stickers in channels for which they meet the token-gating requirements.
React and reply to messages in channels for which they meet the token-gating requirements.
Mention other Community members.
Pin messages in channels (if the Community allows members to pin messages).

Admin

Admins help lighten the management responsibilities of Community Owners and can perform an extended set of functions in the Community. To become an Admin, members must hodl specific tokens or combinations of tokens defined by the Community Owner or TokenMasters.

Admins can perform the same functions as members. However, they can also:

Join a Community without hodling the required tokens. The token with Admin permissions associated will grant access to the Community.
View and post in all channels.
Access the Community administration screens and functions, including the Community’s Control Node stats.
Edit Community settings.
Create, edit, delete, and reorder channels or categories.
Create, edit, and delete the Community’s membership and channel token-gating requirements.
Receive and respond to membership requests from Status users wanting to become Community members.
Kick members temporarily and ban members permanently from the Community.
Pin messages to channels.
Delete any messages sent in the Community.

TokenMaster

When a Community Owner mints their Owner Token, they also mint an unlimited number of TokenMaster tokens, which they can airdrop to those Community members they want to delegate Community management responsibilities.

A TokenMaster has the same permissions as an Admin without needing to satisfy the Community’s Admin token-gating requirement. They can also perform the following additional functions:

Mint, airdrop, and destroy Community tokens, except Owner and TokenMaster tokens.
Add, delete, and edit requirements to become an Admin.

The TokenMaster role is very powerful within a Community as it can determine which members have administrative responsibilities. Therefore, to ensure the Community Owner retains complete control of the Community, the TokenMaster token is remotely destructible. Should a TokenMaster fail to perform its duties in line with the Owner’s expectations, the Owner can call the remote destruct function, destroying the TokenMaster token and stripping its hodlers of their privileges.

Similarly, the TokenMaster token is soulbound, meaning its hodler cannot transfer it to a new address. This ensures that only the Community Owner can appoint new TokenMasters.

Community Owner

When a Status user sets up a Community, they automatically become the Community Owner. They can then mint their Community’s Owner Token, which enables them to securely transfer Community Ownership and mint, import, and airdrop Community tokens. When minting the Owner Token, they also automatically mint the Community’s TokenMaster tokens in the same transaction.

Community Owners have the most expansive set of permissions. They can do everything the TokenMaster can, but can also:

Airdrop and destroy TokenMaster tokens.

Open Communities and Channels

Upon creation, Status Communities are ‘open’ by default. Any Status user can view an open Community’s content and apply to become a member. By default, all requests to join are automatically accepted (providing the Status user has the requisite tokens or the Community is ‘open’). Optionally, a Community can be configured so that all requests to join have to be manually reviewed and approved by a Community Owner, TokenMaster, or Admin.

Similarly, when a Community Owner, TokenMaster, or Admin creates a channel, it will be ‘open’ by default. Any Status user will be able to view the contents of an open channel, and all Community members will be able to post in the channel.

Closed Communities and Channels

A Community Owner, TokenMaster, or Admin can make their Community ‘closed’ by token-gating access to it. Only those hodling the specific tokens or combination of tokens required can view a closed Community’s contents and apply to become a member. Those not hodling the required tokens will see the ‘Request to join’ button greyed out.

When token-gating access to a Community, its moderators can also choose whether to show the token requirements for entry or keep them hidden. Community admin permissions are always hidden unless the user hodls the required tokens. If they do hodl the tokens in an account they choose to share with the Community, they will see the option to ‘Join as Admin’ or ‘Join as TokenMaster’.

It’s important to note that joining a closed Community only requires members to hodl the necessary tokens — there is no token transfer involved whatsoever. Members just need to sign a message to authenticate their account when joining. However, tokens remain in the members' wallets at all times, and users retain complete control over them.

That said, members will lose access to the Community if they transfer or sell the required tokens after joining. Checks are performed once per hour, and those no longer meeting the requirements are ejected from the Community.

Channels within an open or closed Community can also be token-gated. There are two tiers of channel permissions — ‘view only’ and ‘view and post’ — and the token requirements for each can differ.

Setting different token-gating permissions for specific channels can be a powerful way to help manage a Community. For example, a Community Owner, TokenMaster, or Admin might create an ‘Updates’ channel in which only those with Admin permissions or higher can post, but all members can view. Similarly, it might be beneficial for a Community of work colleagues to have channels for leadership discussions that lower managers can view but not post in and that remain hidden from most members.

Eligible Tokens for Token-Gated Permissions

Community Owners, TokenMasters, and Admins can associate token-gated permissions with tokens minted within the Community and existing tokens based on supported blockchain networks.

The token types the feature supports are:

Assets.
Collectibles.
ENS names and subdomains.

Support for existing tokens, collectibles, and ENS names and subdomains is beneficial for those importing an existing web3 community into Status. For example, many NFT communities currently use Discord as a space for team members, hodlers, and fans to discuss the project. To reward support, they often grant NFT hodlers access to channels using various third-party plugins.

In Status, Community Owners can set up layers of token-gated permissions without relying on third-party software — it all happens natively within the application. Not only is it much simpler to set up from the community management’s point of view, but members don’t need to connect their wallets to services outside of the Community, which reduces the likelihood of them falling victim to phishing links that have resulted in many wallets being emptied in the past.

Meanwhile, Community tokens minted within the application are particularly powerful because, like TokenMaster tokens, they can be soulbound, meaning users cannot transfer or sell access to specific channels or Communities. Similarly, Community tokens can be remotely destructible — the Community Owner or its TokenMasters can change an individual member’s permissions without reworking the existing permissions in force or minting any new tokens.

Assets

ERC-20 tokens, or ‘Assets’ as they are referred to in Status, are fungible tokens deployed on Ethereum and compatible Layer-2 networks. Examples of fungible tokens are ETH and SNT. ERC-20 tokens associated with token-gating in Status can be either tokens minted within Status or existing tokens minted outside Status.

For example, a sunglasses company called Shadez might have a Status Community that includes both workers and fans of the brand. To reward loyal fans, it could mint SHADEZ tokens and airdrop them to customers when they buy a pair of sunglasses, giving them access to view and post in channels that regular members cannot see.

When creating a permission that requires a member to hodl an ERC-20 token, the Community Owner, TokenMaster, or Admin can specify the number of tokens the member must hodl to perform the token-gated action. For example, viewing and posting in a specific channel might require members to have at least 10 SHADEZ tokens in their wallets. These do not all need to be held in the same account, and users can select which addresses they share with the Community Control Node to meet the token-gating requirement.

Collectibles

Community Owners, TokenMasters, and Admins can also associate on-chain collectibles (often called NFTs or non-fungible tokens) deployed on Ethereum and compatible Layer-2 networks with token-gated permissions. Again, these tokens can be minted within Status or outside of the application.

Like with ERC-20 tokens, the Community managers can specify the number of collectibles the member must hodl to perform the token-gated action. An NFT community might have special channels in which only Community ‘whales’ can send messages and other channels where all of the NFT collection’s hodlers can chat.

ENS Names and Subdomains

Ethereum Name Service is an Ethereum-based naming system that maps human-readable names to complicated identifiers like Ethereum addresses. ENS names take the form of a string of characters followed by ‘.eth’. For example, alice.eth could be mapped to 0xb795f5fa0ba49734ce639613fefba24274579768 to make it easier for the address’s owner to request token transfers.

In Status, token-gated permissions can be granted to singular ENS names or all subdomains under an ENS domain. To understand how this might be useful to a Status Community Owner, let’s consider Shadez, our fictional sunglasses company example, again.

Shadez also owns the ENS domain shadez.eth, and it gifts each of its employees a subdomain of shadez.eth. Now, we have alice.shadez.eth, bob.shadez.eth, and so on.

Rather than mint and airdrop a new token to all its employees and associate a token-gated permission to the token, the company could make a permission that only those who hodl a subdomain of shadez.eth can view and post in work discussion channels.

Combining Token-Gating Permissions

Community and channel permissions can be even more sophisticated than the above examples using Status’ ‘and’/‘or’ token-gating features. When creating a new permission, a Community Owner, TokenMaster, or Admin can include up to five different tokens of any of the types listed above in the quantities of their choosing.

For example, permission to view a specific channel in the Shadez Community might require members to hodl 5 SNT, 0.1 ETH, 50 SHADEZ, 1 Shadez Community collectible, and a shadez.eth ENS subdomain.

Requirements can also be combined to create ‘or’ permissions. The Shadez Community Owner might reward repeat customers showing commitment to the brand by airdropping them SHADEZ tokens when they submit proof of purchase of one of the company’s products. They could also set up a permission to say that SHADEZ hodlers can view the company’s ‘new products’ channel. Of course, the company’s employees also need to view the channel, and the product department needs to be able to post there, too.

The Shadez Community could establish a few different permissions to achieve this:

Anyone who hodls 5 SHADEZ is allowed to view the ‘New products’ channel.
Anyone with a subdomain of shadez.eth can view the ‘New products’ channel.
Anyone who hodls 1 SDZPRD token is allowed to view and post in the ‘New products’ channel.

In the above example, employees can view the ‘New products’ channel because all company employees received a subdomain of the shadez.eth ENS domain. Additionally, any customer who has earned five or more SHADEZ tokens can view the channel as a reward for brand loyalty. Finally, the company also mints and airdrops specific tokens to members of subteams. In this case, its product development division receives the SDZPRD token, which the company uses to token-gate permissions to particular channels relevant to that team.

Your Community, Your Rules

Status Communities are sovereign virtual spaces moderated by only their owner and the members to whom they delegate administrative responsibilities. No one else, including Status, can interfere with, censor, or terminate a Community.

To guarantee this, Status had to engineer a system to establish ownership without relying on proprietary central infrastructure. We achieved this with our tokenised Community ownership feature, discussed in a previous blog. The tokenised permissions system outlined above extends this by enabling Owners to delegate managerial responsibilities to members on their terms. Furthermore, it establishes powerful Community management features, enabling Community administrators to set up their Community however they choose — from who can become a member and who can post in channels within the Community to who can create new token-gating requirements.

By assigning permissions to perform specific functions to tokens, Status Communities provide the same level of censorship resistance as the blockchain on which the tokens are deployed. To ensure that the Community Owner retains complete control over their Community, we also created the soulbound and remotely destructible TokenMaster class of tokens. Additionally, we added the ability to make any token minted within a Community soulbound and remotely destructible – excluding the Owner token.

Our token-gated Community and channel permissions system is another example of our commitment to our principles and our refusal to compromise them for the sake of convenience. Stay tuned for upcoming blog posts in which we explore similar features that uphold our users' rights to communicate freely and without fear of censorship or surveillance.

If you’d like to know more about token-gating for Communities or any other aspect of the Communities feature in Status 2.0, visit the relevant pages in our help section.