The potential of on-chain credentials for organization and access management.
The appeal of decentralized communities and blockchain applications lies in their attempt to move us towards an equitable and sustainable world.
To effect change at this magnitude, they obviously have their own, different set of fundaments. This difference inspires a rethinking of several core phenomenon, one of which is the credentialing infrastructure of today.
Credentials are used to mediate action in several contexts. In the previous post of this series, we traced their progression from something that we gave to each other to something that we now receive from authorities. Through that exercise, we saw how centralized credentialing paradigms are unfit for decentralized communities, and we established the need of web3-native credentials. You can read the first part here.
In the rest of this article, we shall hint at what this web3-native credential should look like, and reiterate how this is more suitable to a world of decentralized communities.
The primary use-case of any credential is to give order to a system. This is usually done by aggregating the various parts into groups (through classification or categorization).
Since, DAOs are unofficially considered to be web3 analogues of corporations (however inaccurate that comparison may be) most DAOs organize themselves in a manner derived from the corporate model.
Corporations have functional areas with well-defined boundaries and leadership. They have other best practices too that have been proven to keep things running smoothly. But tools used by these corporations have proven to be unfit for DAOs (or at least, for the ideal DAO).
Retrofitting these corporate, web2 tools in DAO workflows have lead to high operational overheads and increased difficulty in running things. They have made organizing members and managing access control more cumbersome than it needs to be.
In corporations, the company email ID or the identity card is the most common credential used to manage access control. Whether it is resources in data rooms for specific personnel, or specific channels in Discord or Slack -- everything is easily mediated through this master credential.
The distribution process for these credentials lie somewhere between a couple days to a week. This is not a problem when we consider the time taken to onboard a new member. However, when we look at decentralized communities, entry or exit happens in minutes. Further, with the build-in-public culture common in these environments, managing access control can be tricky.
So most communities resort to using a patchwork of NFTs, native tokens and POAPs. This easily gets overwhelming.
Setting up native tokens or NFTs is a task in itself. Deciding on their tokenomics, ensuring a fair launch, having safety mechanisms to prevent dumping, etc. -- these are challenges for veterans too. And POAPs must be limited to trivial use-cases since their transferability makes it tough to use them for anything serious.
All of this leads to bloated operational overheads that leave communities scrambling to just get the basics right. A web3-native master credential would make perfect sense here.
Something that is interoperable with token-gating tools, truly owned by members, and can reflect the dynamic nature of members’ relationship with the community would be the ideal. Such a credential would not only solve for the unique requirements of decentralized communities, but also set the stage for innovations in the future.
No one could tell that putting cute cats on a token would spark a revolution in digital art. Yet, the presence of a medium to explore such ideas added fuel to the fire. The right credentialing medium would, similarly, open the door to a more interesting future.
With people owning their reputation, a whole host of applications could be created. Undercollateralized lending is one such example, where people secure loans partly based on their reputation (by staking their credentials) and partly on monetary collateral.
The possibilities are nearly endless!
Adding structure to a corporation is straightforward. Denoting functional areas with clear demarcations is enough. And most teams anyway operate in silos, with the occasional member spread across several teams (like a product manager). But adding structure to a decentralized community this way isn’t easy.
DAOs have flatter hierarchies, and their members are actively encouraged to get involved wherever they can. Members from the operations team of a corporation showing up in an internal marketing meeting and giving their opinion may seem strange, but this is often the norm in several DAOs. And to an extent this is also useful.
But the downside of this is the negative impact on efficiency. Since working in DAOs requires a high-level of intrinsic motivation, just choosing one or two functional areas to contribute to and then sticking to them is a big enough task that knocks out the motivation from most members. And since the boundaries of a DAO are so porous (with member entry and exit taking minutes) it is tough to add a structure in such a dynamic environment.
So how should a community solve for this?
The current approach is a gauche mixture of designating members to functional areas and hoping they self-moderate their participation for the sake of productivity. A better solution would be to coax members to get maximally involved and then capture their involvement in a relevant manner.
So after encouraging members to take action with tangible results, communities should capture this work in a way that adds transparency to member activity. This transparency highlights active members and promotes organic emergence of leadership.
Since such transparency is abhorred by the freeloaders yet is welcome by the hardworking, this is a perfect recipe to not only organize your community but also separate the ones that drive output from the others.
This is another reason why on-chain credentials make sense. And it is interesting to note that a version of this is already prevalent in most decentralized communities. This manifests in bounty boards and contribution forms.
So using credentials to capture work has the cost of adding a few clicks to current processes, but it brings with it the benefit of better organization and increased transparency.
This proves useful down the line in electing leaders and setting compensation policies. Capturing work this way also opens the door to experimentation in community governance.
For example, imagine an individual who has made several contributions to the marketing guild. They probably have a deeper understanding of how marketing is done in a community. So what if this person had more voting power when it came to marketing proposals? Such context-based governance would acknowledge members’ interdisciplinary activity while ensuring that those with the right expertise are heard.
This is a positive by-product of using credentials to capture work. And we are certain that we will see more positive consequences of this in the future.
Decentralized communities have a long way to go. At rep3, we are rooting for them to take us closer to a more equitable and sustainable world. That is why, we have built a protocol capable of solving the requirements of these communities in a way that also sets the stage for experimentation and innovation.
It is imperative to solve for the requirements of communities today. Web3-native credentials that can capture memberships and member activity is a promising tool for the same. They solve the organisation and access control needs of communities in a way that fits them best, which increases community health by satisfying the operators and core members.
But using on-chain credentials are equally if not more attractive when seen from the perspective of contributors and potential members.
In our next article, which is the third and final piece in this series on on-chain credentials, we will view credentials from another angle, and discuss their capacity as potent tools for recognition and reputation. Follow us on Twitter to stay updated, or book a demo if you’d like to see the protocol in action.
Read part three of this series on on-chain credentials here.