Welcome to the third deep dive on how we are building Cabin. We’ve aggregated everything we know about reward design from discussions with multiple DAOs, and combined that with information about compensation in traditional businesses.
As a DAO contributor, you can use this guide to help understand what options you have. As a DAO community engineer, you can use this document to design general guidance for your community. There’s also benchmarks in the Appendix.
This article is for regular contributors and community engineers / builders. If you are just starting your DAO journey, take a peek over here instead!
Bobby logged into the server. Today the contributors had an important discussion pending: bounties and contributor rewards. As part of the conversation, Bobby had to help reach consensus on benchmark bounty rewards and a proposal for ongoing payments for regular contributors (incl. part-time and full-time). However, Bobby wasn't sure how to go about this - What were other communities doing? What incentives should they use to support their overall mission? Should the community allocate tokens or USDC?
There’s a Bobby in every DAO, striving to help make contributor rewards transparent, decentralized, fair, and sustainable. After all, incentives run the world and can make or break an organization.
That being said, these are very early days. A variety of new rewards will likely emerge over the next few years - just like NFT status symbols were popularized last summer. This reward recipe book should be considered intermediary guidance while we discover new rewards inspired by game design, and incorporating novel ownership mechanisms.
💡 Quick Note: We will exclude token appreciation, community-wide disbursements (e.g. airdrops) and reputation in this article. We will likely take a look at these topics in other articles related to community engagement design.
It can be tempting as a community genesis member or guild veteran to try and define a clear set of instructions. Creating static company-wide policies is how most of us have done it in traditional organizations. It’s like a warm weighted blanket - a feeling of comfort in certainty.
However, we’re in a different ecosystem with ambiguity, volatility, constant change, and an opportunity for artistic experimentation. As a result of this dynamic space, it’s probably best to think about community guidance as contextual (artistic!) recipes while encouraging individual members and guilds to find the right solutions for their context.
Rewards can mean a variety of different things.
At Cabin, when we use the term Reward, we mean "pay for eligible work". When we mention “pay”, we mean rewards in the form of liquid ownership. In other words, rewards should:
The latter is critical, as without it we run the risk of developing negative aspects of the gig economy.
At at a top level, we believe a good reward recipe book covers the following steps:
There are a lot of options in terms of who could get rewarded, what to reward, and how to distribute rewards. Spending some time thinking about decision-making guardrails can help narrow down the design space. In HR-speak, these are usually called “Design Principles” and “Design Practices”.
Here’s an example from Warcamp (DAOHaus):
Design Principles should definitely vary across communities and over time. Over time, they reflect changes in membership, and most importantly, the evolution of the mission and focus. Some examples include:
Optimizing for one principle can mean decreasing focus on others. However, this doesn’t have to be the case given all the new technology we have at our disposal.
In addition to choosing basic principles, it’s useful to define Design Practices. This is the translation of principles into expected operational actions. Here are a few examples that help with the design process:
Prior to determining what reward to give and how to distribute it, it's often good to ask: Who should we reward? At Cabin we will call this Eligibility.
💡 Quick Note: In a traditional business setting, a full-time employee performs full-time work. Full-time work is Eligible for compensation, which could be an hourly wage, monthly salary and a certain variable payment (e.g. bonus).
Reward eligibility is based on (1) the work itself and (2) the individual (via role or contribution level). Here's a simple way to determine whether or not a piece of work should be rewarded in the first place.
Our initial Cabin guidance is below. We recommend each DAO review and create a custom map based on their mission, treasury plan, and community needs.
As the worksheet suggests, Cabin is currently rewarding creation, but not ideation. We want to incentivize completion. In the future, if we run out of ideas, we might revisit and reassign rewards to incentivize proposals.
In some cases, community members may not have structured work assignments but should be rewarded based on continued participation:
It can be a useful exercise to create mnemonic devices to communicate these more complex frameworks. Mnemonic devices include memes, sayings, or other word-play like an acrostic. At Cabin we don’t have one yet, but it will likely pop-up soon enough.
💡 Quick Note: These are examples of eligibility and are not mutually exclusive or collectively exhaustive. Many new creative eligibility criteria can be considered, especially related to inter-related characteristics. For example, we are certain that special eligibility will include future reputation protocols, transaction history, mutual referrals, and staking status.
Once you’ve decided on which work types and member groups are rewarded, the next step is to create a map of reward types and terms. Here’s what Cabin might use over the next few seasons (still TBD):
Any community member should be able to review the reward mechanisms and request the ones that best fit their risk profile, short-term and long-term preferences, and the work they are completing.
A DAO can create Reward Personas to show community members examples of how their work will be rewarded.
Reward Persona Example: * Contributor: New Member, Writer, Bounty-Hunter * Work: Completing an deep-dive research write-up for DAO * Reward Eligibility: Yes (eligible based on project) * Reward Type: Pay 50-50 CABIN-USDC (Asset) per project (Allocation) from Treasury (Source). * Reward Terms: Paid immediately (Timing), scaled based on complexity (Multiplier), once upon completion (Disbursement).
It’s typically easier to determine eligibility and reward type / terms before determining the size of the reward.
In the previous example, the writer agreed:
The final decision (and usually hardest!) is to agree on the amount.
Reward amounts are currently calculated either by individual decision, algorithm, or a combination of both.
We won’t be covering algorithmic allocations in this article - as there are other experts, and we’re probably best to leave that to them (e.g. like Coordinape).
For individually calculated rewards, consider market pay rates (if any available), total effort worked, and adjustment values based on volatility and upside. Here’s an example of reward formula design:
Reward Amount = (Market Price USDC * digital asset conversion rate * Multiplier * Volatility Risk Adjustment) / Upside Opportunity
At Cabin we pay more than standard market rates where possible because we’re in a high risk environment. If your token payouts have high volatility, the pay should be much higher than a FAANG basic salary.
💡 For more information about designing custom formulas and indexes, you can read about how these are used in Materials Engineering and Design here.
In more advanced cases, payouts are tied to work outcomes, likerevenue sharing agreements on a specific product development process, for example. Most often, KPI targets through commission or defined as a curve, trigger a reward. Here are some examples:
A selected team of community leads, mediators, or stewards or a larger community vote can help a final rewards proposal reach consensus.
Either way, the DAO has to put safeguards to protect the treasury. For example, a community can cap treasury disbursement based on available funds, or allocate some of the treasury to use for rewards during the upcoming season.
In designing new reward systems, we should keep expected biases in mind. DAOs should work together, create a new metadata framework, and build a public database of payments. Over time, anyone can look at this to help inform their pay requests, identify new types of bias, confirm offers, and serve as a reference for other DAOs.
Over the past few months there have been three types of digital bias emerging:
These biases sow discord (pun intended!) within a community and create unhealthy power dynamics.
For example, if a new member with a premium PFP joins a community and gets a higher payment for similar work and similar value, other contributors will claim back-payments, develop resentment towards the individual, and potentially actively block the work.
This said, we need to differentiate between rewards bias and reward tinkering based on new needs. By creating a public database and an extensive (but automated!) meta-data framework, we uncover these trends and take steps to prevent bias. In the meantime, each community will have to invest in local bias awareness.
Rewards are a foundational aspect to any community and will be a topic to revisit, debate, and experiment with openly. We look forward to seeing how DAOs evolve and what new products emerge. After all, clear and competitive reward expectations will be one of the pieces that will accelerate the mass migration of workers from web2 to web3.
Open Source Crypto Salaries (Use with Care, no data validation)
Example Bounty Boards: