Please describe your proposed solution.
Based on public information, these are some of the names in the Cardano ecosystem that urgently require a community of contributors and for which the results of this proposal would be beneficial:
NMKR: in the process of making its NMKR Studio open source.
TxPipe: they have just assigned a Rust dev as part-time open-source maintainer of the Pallas library and have just started the development of the massive Dollos project (the development of a Rust Node). They would certainly benefit from have their own community of contributors.
Cardano: Mithril is a promising tool that has little involvement from contributors outside of IOHK. A large community of contributors would accelerate the roadmap.
Since its inception during Catalyst's early funds, Gimbalabs has been accumulating key knowledge to understand the building blocks of a treasury system that incentivizes the formation of a critical mass of contributors to support the growth of a project.
Our experience in the areas of education, incubation, infrastructure, consulting and creation of community spaces has provided us with sufficient background to approach the subject from a practical point of view. The following precedents ensure that we will not start the development of the model from scratch:
Gimbal Bounty Treasury and Escrow
Andamio: platform that provides a modular toolkit for learning management, contributor onboarding, emergent credentials, and treasury governance.
The "Contribution Treasury System" model research will be a hands-on experience from which structured insights will be gathered on how to establish a treasury system that incentivizes collaboration and contribution. The results of such research can be used by Catalyst funded startups to build their own treasury system that allows them to cultivate their own critical mass of contributors in development and maintenance domains.
A treasury system that is mature in encouraging collaboration and contribution will allow startups to focus on generating business volume, which will consequently put them closer to self-sustainability.
Details of the research to be conducted:
-
Research Environment: Gimbalabs Plutus Project-Based Learning, one of the most prestigious Cardano stack learning programs in the ecosystem.
-
Research population: Gimbalabs Plutus Project-Based Learning learners.
-
Description of the architecture developed by Gimbalabs to be deployed: the following charts provide a basic idea of the design of the Contributor Treasury System:
However, a more robust architecture will be studied, as follows:
The Contribution Treasury System to be deployed is built upon a set of “parameterized” smart contracts. These Plutus smart contracts are used to manage treasury funds, track commitments from contributors, and to govern decision-making systems. Plutus contracts can be built with re-usable rules that remain constant with different parameters. The Treasury contracts define what an Organizational Administrator, Decision Maker or Contributor can do, but crucially, not who they must be. Unique Role-Based Access Tokens are minted uniquely for each role in the Contribution Treasury System.
<u>Roles</u>
People participating in the Treasury use on-chain, Role-Based Access Tokens to participate in the system. There are 4 role-based tokens:
- Organization Admin
- Decision Maker
- Contributor
- Learner
<u>Organization Admin</u>
The Admin can add or remove tokens from the Treasury, and approves the list of valid Projects so that Contributors can make commitments.
Decision-Maker
A Decision-Maker can approve that a “Commitment” is complete. In the Gimbalabs Plutus PBL, a Commitment can represent student completion of a Module, Project, or Student Learning Target. For organizations, a Commitment can also represent a project or task with token rewards. In our case study, Decision-Makers might be teachers and course instructors, or they might be project managers and development leaders. In great organizations, leaders often play a teaching role. The flexibility of the Decision-Maker role allows flexible, emergent leadership to develop across an organization.
Contributor
A Contributor can make Commitments to Projects listed in the Treasury. Projects can be for learning, as in a Project-Based Learning Course, or Projects can represent vital contributions to an organization. Commitments are tracked via the Contributor token, and over time can be used to build a track-record that be shared across organizations.
Learner
There is overlap between Contributor and Learner tokens, and they work the same way. Often they are one and the same. When they want to, Organizations can create several different levels of contribution tokens. For example, they can allow anyone to mint an “Onboarding” token as they start to learn about the organization and its work, while setting some rules for how a Learner might earn a full-fledged Contributor token with access to more opportunities. In the rest of this description, we will not distinguish between learners and contributors; we’ll simply use the word “Contributors” to represent both.
<u>“Multi-Sig” Roles</u>
Admin and Decision Maker roles can have multi-sig functionality. While it is possible to require just one signature to approve a Treasury Action or to unlock a Contributor’s commitment, it is also possible to require multiple signatures to make these decisions. The Treasury Governance Contracts are used to customize and configure decision-making rules for an organization.
On the other hand, Contributor tokens are unique to each Contributor, and there is always a one-to-one mapping of a single wallet address to a Contributor Token.
<u>Connections to Identity</u>
Each Role Token is an indentifier for participants in the Treasury. It can be connected to systems for Self-Sovereign Identity (SSID) and Decentralized Identity.
<u>Contracts</u>
A set of Plutus Smart Contracts is used in the system:
- Treasury
- Escrows
- Contributor Reference
- Minting
- Governance
Treasury Contract
The Treasury Contract locks Ada, and optionally any Cardano native asset, to be used as rewards for Contributors who make Commitments and complete Projects. In this way, the Treasury probably meets your expectations. However, this is not its most important function.
The Treasury also locks a list of Projects approved by an Organization. Once a Project is approved and listed in the Treasury, Contributors can commit to completing. Contributors can only commit to projects listed in the Treasury.
Escrow Contracts
When a Contributor makes a Commitment to a Project, the rewards for the Project are locked in an Escrow Contract. When this happens, the Contributor’s access token is also locked. This means that in the Treasury, a Contributor can make only one Commitment at a time.
There can be one or many different Escrow Contracts in the system. There is one Escrow Contract for each unique Decision-Maker in the Treasury. For example, teachers responsible for onboarding new contributors might be Decision-Makers for a PBL Course Project, while project managers might be responsible for approving contributions to an ongoing project. Across an organization, there might be many kinds of Decision Makers, each with the ability to approve the Distribution of project commitments for which they are responsible.
Contributor Reference Contract
The Contributor Reference Contract holds a “Reference Token” for each Contributor Token. An on-chain record of contributions is stored with the Reference Token in the Contributor Reference Contract. Every time a Decision-Maker approves the completion of a commitment, the rewards are distributed to the Contributor. The Contributor Token is also unlocked and returned to the Contributor. When this happens, the data associated with the Contributor is updated.
Minting Contracts
The rules for minting Admin, Decision-Maker, and Contributor tokens can be customized via the Teasury Minting Contracts. Organizations can choose from a set of options for minting new tokens for each Role.
Governance Contracts
The Treasury Governance Contracts support the multi-sig capabilities of Admin and Decision Makers. Not only can Admins and Decision Makers be represented by multiple public keys, the rules for how decisions are made can be customized for each organization. This is the role of Governance Contracts.
<u>Key "Contribution Treasury System" Interactions</u>
Each interaction is defined by a Contract and a Role-Based Access Tokens
- Funding the Treasury (Treasury x Admin)
- Governing a Treasury - Project List (Treasury x Admin)
- Commitment (Treasury x Contributor/Learner)
- Distribution (Escrow x Decision Maker)
Funding the Treasury
- Contract: Treasury
- Role: Admin
The Admin can add and remove Ada and other Cardano native assets to the treasury.
Treasury Governance: Defining the Approved Project List
- Contract: Treasury and Escrow
- Role: Admin
Organization Admins govern a Treasury by approving lists of Projects to which Contributors can Commit. For every Project, the Admins define:
- Which Contributors can Commit to a Project
- Which Decision-Makers will approve Project Completion
For each Decision-Maker, there is a different Escrow Contract. When a new Decision-Maker is specified, a new Escrow Contract is created.
Commitment
- Contracts: Treasury and Escrow
- Role: Contributor
An approved Contributor can Commit to a Project listed in the Treasury. When they do, a UTxO is locked in an Escrow Contract instance corresponding to an approved Decision-Maker. The locked UTxO contains:
- Ada rewards
- Native asset rewards
- The Contributor’s Token
Because the Contributor token is locked, each Contributor can commit to only one project at a time.
When a Commitment is made, the rewards for the Project are locked, and can only be unlocked when they are sent to the Contributor who made the Commitment (or returned to the Treasury after a deadline passes). Note how this system is different from “bounty” architectures. In most Bounty systems, projects and tasks are publicly listed, and anyone can race to be the first to complete the work and earn a reward. This can lead to uncertainty for Contributors. What if someone spends hours working on a Project, only to find that someone else finished it first and earned the reward. With the Gimbalabs’ Contribution Treasury System, Contributors can be certain that as long as they complete a commitment before a listed deadline, they will earn the expected rewards.
Distribution
- Contracts: Escrow and Contributor Reference
- Role: Decision-Maker
When a Project is complete, a Decision-Maker can approve the Distribution of rewards. When rewards are distributed, the Contributor token is also returned, and the Contributor is able to commit to the next project, continuing the process. Also at the time of distribution, the Contributor’s Reference Datum is updated at the Contributor Reference Contract.
- Research methodology: Gimbalabs Plutus PBL students build their skills by following the funnel described in the following graph:
Onboarding -> BBK -> Contribution -> Governance. When the students reach the Contribution stage (pink box) is when they are ready to take on projects, to make contributions to the system they are part of. Basically, this scheme, refined over three versions of Gimbalabs PBL (the current version of Gimbalabs PBL is the third), ensures that routinely, serious contributors are onboarded to any system.
Our research will focus on the Contribution stage, implementing the architecture described previously, and gathering data on the activity that takes place in that stage.
- Areas of Contribution: three main areas of contribution will be the subject of research:
a) Code: front-end, back-end, code snippet, maintenance, etc.
b) Documentation: Producing improved documentation for existing systems or projects, and robust documentation for systems or projects under development.
c) Content creation: new learning modules, new PBL courses, maintenance of existing learning modules modules.
- Procedure to follow:
1) Deployment of the Contribution Treasury System.
2) Funding the Treasury: the level of transparency injected into the Treasury technology developed by Gimbalabs allows for easy auditability by the Community and interested parties.
3) System administration: management of the architecture described above.
4) Monthly report of system activity.
5) At the end of the research we will present a comprehensive documentation describing the researched model and the procedure to apply it by Cardano startups and other stakeholders.
> Note: the results of this proposal will show companies and organizations outside of Cardano how to cultivate their own critical mass of collaborators that contribute to the development and maintenance of their own systems, <u>using Cardano technology</u>, which, as in the case of the startups in our ecosystem, will allow them to focus on Business.