The core purpose of Catalyze is to provide Web 3.0 communities with a toolset that enables them to thrive. The Web 3.0 environment is by nature remote, decentralized, and the regular methods of establishing and managing trust in a group setting through in person interactions do not apply. This means that trust establishment, and trust enforcement is established through data interactions and rating and accounting systems that are built on top of these datasets.
This is not particularly new. In a Web 2.0 environment data plays an extensive role in establishing, for example, suitability of advertising content delivery. However, here the trust dynamic is between the platform and their clients, and not between the platform and the user. Our goal is peer to peer trust construction within a community, and identification and remuneration trust that can be built between the platform systems, smart contracts and the internal communities that use the platform.
The tokenomics is intended to inform and support this through several incentive and disincentive mechanisms that affect governance, exchange of value, identity management, and reputation management.
Governance Tokens
The overall tokenomics has to facilitate governance at the platform level, and at the community level. The CAT governance token is the primary incentive tool for managed global governance and micro-governance within the ecosystem.
- CAT governance tokens serve as the on-ramp for premium platform functions, including managed services and moderation, as well as advanced tools and community analytics.
- CAT governance tokens are staked/locked at community level in order to back monetised (tokenized) communities that have their own treasury and use the app to manage payments to members.
- CAT governance tokens are escrowed at the community level in order to support the compliance with platform and community policy requirements.
- CAT governance tokens in micro amounts to facilitate polls, votes and proposal creation within communities. Imposing minor transaction costs means that spurious proposals are less likely.
- CAT governance tokens are used in spam prevention and spoofing, again through the imposition of transaction costs on high volume, and high priority messaging.
Utility Tokens
The secondary token in the ecosystem is used as an accounting mechanism and is completely internal to the ecosystem, so not traded on any external exchanges. This token called uCAT measures the utility value of interactions and exchanges between users. By analogy with the highly popular mobile game “Clash Royale ” — if CAT is “gems” then uCAT is the equivalent of “gold”. The former is used for high value rare items and is difficult to find without paying, while the latter is used for upgrades and ranking and can be earned quite readily within the game world by progression.
- uCAT is used to create a simple signaling paradigm that makes it easy for the community member to gauge the relative value of a task and the in-house “kudos” that it will earn.
- uCAT can be easily transferred amongst members and finally be converted (at some internal community rate) into CAT. For more urgent, high value tasks community managers would use CAT directly, but for distributed tasks that are about reputation building incentives – we believe that this two-tiered approach is better.
- uCAT has a secondary function in that it can be allocated as “tips” or “burned” through a reputation management system. So, for example, if Alice likes Anna’s post – then Alice can burn some amount of uCAT as a way of up voting it. This starts off as in-house token recycling, but also acts as a signaling source for the things that members value within communities.
Trust Mechanisms
Reputation Signaling
The most difficult problem to resolve within decentralized and remote communities is the who to trust question. Members, for example, in NFT communities have no direct access to one another apart from through a screen or through community common spaces. But people do cooperate through the internet, and have done so for years.
Reputation signaling plays a large part of trust building. On a social media platform, like LinkedIN, pushed content and user profiles act as trust signaling, and these signals affect search and recommendation patterns. In a Discord environment, where the equivalent of a LinkedIN post is a message or conversation in the community chat, these user signals are lost. From the community manager side — competency signals and contribution signals are also deeply important. So, our goal is to find ways to catalog and record these elements of subjective feedback within the application.
- Identity management using wallet addresses allows us to use wallet contents as a means of storing behavioral signals. For example, if a Proof of Attendance Badge that is issued when a user joins an AMA session is a direct way of gauging participation from community members.
- NFTs allow for us to build up participation history, allocate roles to users and allocate permissions to users too. A key idea is systematized and “gamified” trust pathways that help to signal to community managers, and members reliable and consistent participants. This functionality is done through bots (at times) in Discord, but we have the option of using immutable tokens that amount to status certifications. Sure, this can also be spoofed, but it can’t be done casually. These types of certification style records can be made non-transferrable, but with some concessions to the community manager’s discretion.
Preventing the Spread of Misinformation
A second aspect relating to trust is that in order to have trusted systems, the system also has to self regulate the spread of misinformation. A simple example of this is a fake link to say, an NFT mint, that propagates through a community. Users can be easily duped into thinking this is an official link with websites easily spoofed. On the other hand, a credential system that requires official messages to be signed by an authority that has the credentials to do so is an easy way to prevent this. Of course, if the credential holder is compromised, misinformation can still spread, but this is the best that can be done at a system level.
Smart Contracts
In order to implement this architecture a number of different smart contracts are required. We list these briefly.
- Multi-signature treasuries that allow for groups to manage their funds with M of N signatories required in order for funds to be moved.
- Exchange services that allow for utility tokens (and other tokens) to be converted in-application into governance tokens.
- Escrow contracts that allow for funds to be time locked.
- Transaction and billing mechanisms that charge users for in-app activities in CAT tokens; for example, bulk messaging with spam prevention.
- Tipping mechanisms so that community members can tip with tokens.
- Token deployment mechanisms in case communities want to have their own tokens and manage them in some way
- User on-ramps for crypto to fiat and fiat to crypto bridges.
- Cross chain functionality and interoperability features.
- Community management and trust mechanisms.
- Governance mechanisms.
This is non-exhaustive, and the main aim is to wrap a financial architecture built with Web 3.0 into a communication tool and community management service. Over time the goal would be to allow communities to manage themselves in a decentralized space with similar (if not better) functionality than they would achieve with the TradFi/Legal system models that are used for standard real-world governance.
