Tokenised Community Ownership in Status 2.0
Unpacking the engineering effort behind our secure, decentralised solution to Community ownership
As you know, our principles guide everything we build at Status. Among them is a commitment to ensuring absolute user sovereignty. In designing our super app’s features, we put you, the users, in control of everything, including Community ownership. In this post, we discuss our solution to ensure Status Communities remain sovereign, secure spaces, even during the transfer of ownership. Let’s talk tokenised Community ownership!
Status Communities are sovereign zones in which individuals united by shared passions are free to organise and express themselves without fear of censorship or surveillance. You can think of them like Discord servers without the risk of a central entity revoking access or spying on users as it sees fit (and with many neat extra features we’ll explore in future blogs!)
While Communities are sovereign zones, they are not necessarily free-for-all spaces where anything goes. Some Communities might want to implement strict joining or membership policies that align with their shared values. Whether or not Status as an entity agrees with these values is irrelevant. As engineers developing politically neutral software, judging or excluding any group is not our place.
To understand how our tokenised Community ownership architecture works (and why its implementation was not as straightforward as it might sound), we first need to understand what a Community is at the protocol level. Essentially, a Status Community is a key pair. The Community Owner holds the private key and uses it to sign messages to update details about the Community. Community members have the public key and use it to verify the authenticity of these Community messages. Members then construct the Community locally on their device from the Community message contents.
This architecture removes the need for central servers to store data relating to each Status Community and which members have the authority to update Community details. The solution is great because only the individual who holds the Community's private key can change the Community’s rules, and no central entity can revoke access to or terminate a Community.
However, this model is deeply flawed from a security perspective when it comes to transferring Community ownership. A Community Owner should be free to leave a community or pass control to another member on their terms, and this should not jeopardise the Community’s security. Yet, under this simple key pair model, transferring ownership requires displaying the Community private key in plain text in the UI, the Owner recording it via the in-built copy-paste function, and then passing it to the new Owner.
This is far from ideal. Firstly, the previous Owner might keep a copy of the private key, thus retaining the ability to perform actions reserved for Community Owners. Secondly, securely transferring the key becomes an issue if the previous Owner is not close enough to pass the key physically to the new Owner. Even transmitting the key over an encrypted channel exposes the Community to security risks, which runs contrary to Status’ founding principles.
Our engineers put on their thinking caps and got to work on a solution. Like everything we do at Status, whatever they came up with had to be highly secure and not involve the use of any central servers. We decided that coupling ownership permissions with a unique token was the way forward.
Tokenised Community ownership is advantageous because transferring a token between accounts is secure, immutable, permissionless, and essentially unstoppable. By coupling ownership permissions to a token, a Community Owner would be free to securely transfer or sell ownership whenever they like and entirely on their terms.
However, we did not want to compromise our commitment to accessibility in doing so. The nice thing about our original key pair solution is that generating keys costs nothing and requires no crypto assets whatsoever. By contrast, forcing users to mint a token when establishing their Community would be a barrier to entry as it requires a transaction fee. Firstly, every prospective Community Owner would need to own some crypto already, and secondly, they would have to spend some of it on gas to mint the token.
Our solution is to retain the existing key pair architecture when establishing a new Community. Then, to transfer ownership securely, the Community private key holder first mints a Community Owner Token. Once minted, Community members consider all Community updates signed by the token holder valid. Then, if the Owner chooses to, they can transfer or sell the token on their terms. When new Owners receive the key, they submit an on-chain transaction to finalise the ownership transfer, enabling Community members to confirm who the new Owner is.
This simple-sounding feature took a lot more development work than you might think and involved collaboration between several of our engineering teams. Let’s unpack how it all works.
An Owner Token is a unique NFT (ERC-721) with some extensions. Importantly, Community members will only consider the first Owner Token minted as the true Owner Token, and whoever holds it can sign messages to update and change elements of the Community. Of course, this explanation is oversimplified, so let’s dig a little deeper.
The feature’s architecture centres around the Community Token Deployer contract. When a Community Owner wants to mint their Community’s Owner Token, they create a signed request to the deployer contract, which deploys the Owner Token. This request must be signed by the key generated during the Community’s creation to prevent non-Owners from deploying Owner Tokens.
The contract then checks if the Community has already deployed an Owner Token and the validity of the signature provided. Additionally, during the token deployment process, the contract adds an entry to the Community Token Registry contract, which keeps a global registry of Community addresses and their Owner Token addresses. This enables Community members to obtain the Owner Token address for a given Community and identify the Community’s genuine Owner. Supposing all checks pass, the Token Deployer contract creates an instance of the Owner Token, which is assigned initially to the minter’s wallet account.
The above process is minimally viable for transferring Community ownership. However, this basic architecture would mean that all Community update signing would be performed by the private key of the token holder’s wallet account. In the future, Community Owners might want to host their Community Control Nodes on third-party services. This introduces a small but unacceptable security risk if all Community updates are signed using a wallet account’s private key. Again, we weren’t prepared to take a shortcut and engineered a solution that would maximally protect user funds while extending the freedom to host a Community on the Owner’s terms.
In Status, we can derive multiple accounts, including one chat account and several wallet accounts that can all be recovered from a single master key pair. Wallet accounts are for signing transactions, and the chat account is for signing messages. Of course, when minting or receiving an Owner Token via transfer, we receive the token in the wallet account. Therefore, we needed an additional step to assign the chat public key to the Owner Token to enable Owners to sign Community update messages without using their wallet credentials.
The solution lies in extending the Owner Token so that Owners can set a new chat public key from which signatures generated are considered valid. Therefore, we added the 'set signer' and 'get signer' functions to a standard ERC-721 token. These subtle changes added the functionality required without breaking the compatibility of Owner Tokens with other systems that function with the ERC-721 standard — you can still transfer or buy and sell Owner Tokens on popular NFT marketplaces, for example. Having used the 'set signer' extension to set a new chat public key, the 'get signer' extension enables Community members to confirm the validity of updates signed using the Owner’s assigned chat account.
The concept of an arbitrary signer discussed above neatly addressed the potential security vulnerability concerning third-party Control Node hosting. However, as per the original implementation, we derived a Community ID from the Community master public key. This worked well when only messages signed by the Community master private key were considered valid. This assumption is no longer true with the Owner Token model because the valid signer can change an arbitrary number of times. Therefore, we needed to decouple the original Community key pair from the Community ID when minting the Owner Token.
This was a mammoth task because, as you can imagine, the software frequently references the Community ID. It also created a few more issues that needed solutions — some of which we were expecting and some that came as a surprise. We’ve detailed a couple of them below.
Messages from unknown Owners:
After an Owner transfers the Owner Token, members might receive a Community message before they have confirmed the account of the new valid signer. Therefore, we built a message queuing system to process messages from it in a loop, enabling members to verify if they originated from the rightful Owner while ensuring that important and potentially valid messages are not discarded. At regular intervals, the user automatically checks the contract for updates to the contract’s Owner field. When there is a change in the Owner, they verify and process queued messages signed by the newest Owner and reject those signed by a different key.
Retrieving Community members:
To enable Status’s UI to display membership lists, all members' chat keys are included in the Community description message broadcast over the Waku network. The Community message is encrypted in the case of closed, token-gated Communities and unencrypted for open, non-token gated Communities.
To preserve maximum user privacy, the membership list only contains chat keys in terms of member data. However, Community features like token airdropping, tokenised karma (and other future features) require the Community Control Node to have access to at least one account address per user. Community members can select which wallet address they want to share with a Community’s Control Node, which could be a newly derived account per each individual Community the user joins for maximum privacy. While this approach ensures greater privacy, self-sovereignty, and censorship resistance, an issue arises when it comes to transferring ownership.
Once a Community Owner transfers management responsibilities to a new Owner, we cannot rely on them to send their private metadata about members, such as wallet addresses. For both malicious and non-malicious reasons, they might send inaccurate or incomplete addresses, or perhaps not send any addresses at all.
To address this, the application 'soft-kicks' all members when the transfer of ownership is finalised, and existing members must submit their account details to the new Owner’s Control Node. This occurs automatically, so existing members don’t need to apply again manually. The result is that the new Owner’s Control Node can compile a membership list without needing to trust the former Community Owner or any centralised infrastructure.
At Status, we firmly believe in individual freedoms and consistently build our software to uphold them. In building the Communities feature, we wanted to engineer virtual spaces that no entity can feasibly censor, stop, or demonetise.
We needed to design an entirely serverless architecture to achieve this admittedly lofty goal. Naturally, this involved building many features completely from scratch, one of which was the tokenisation of Community ownership. By enabling Community Owners to transfer or sell their responsibilities on-chain, we extend maximum sovereignty to them with the same assurances as the underlying blockchain network on which the Owner Token transacts.
Although it sounds simple in practice, tokenised Community ownership was one of many features that required creative engineering, contributing to the overall time it has taken to get the application in the hands of users. But we’re finally close and thrilled for you to start using the revamped Status 2.0 Desktop and Mobile apps!
This initial implementation of tokenised Community ownership is only the beginning — a bare minimum version to ensure that Owners can transfer their responsibilities to new Owners without relying on centralised infrastructure. In the future, we intend to expand the functionality in various ways. For example, we are looking into upgrading the feature to support multisig Community ownership, which would enable management by multiple parties and help prevent singular Owners from losing control of a Community in the event their keys are lost or compromised.
As always, if you have ideas to improve this feature, please head over to our feature upvote page and make a suggestion. Part of building the best super-app we can is responding to what the wider Status community would like to see, so just let us know, and if enough people agree with your suggestion (and it’s feasible!), we’ll prioritise its development.
If you’d like to know more about tokenised Community ownership in Status 2.0, two of the contributors behind it recently gave a presentation outlining the feature. Watch it on YouTube.