Subscribe to Cabin
>100 subscribers
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:
Liquid: Be useful for rent and food
Ownership: Distribute governance power of the community
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:
Reward Principles: What’s the north star?
Reward Eligibility: Who should we reward?
Reward Structure: What should we reward, under what terms?
Reward Amount: How much should we reward?
Reward Consensus: How do we agree on the reward?
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:
Consistency, Flexibility, Collaboration, Alignment, Transparency, Simplicity, Ownership, Sustainability, Fairness, Decentralization, Predictability, Efficiency, Automation.
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:
We will design rewards with inclusive collaboration as a core value: This means testing rewards for accessibility, diversity, teamwork, and mutual generosity.
We will review rewards regularly: For new DAOs this might be weekly or monthly. For more mature DAOs a Seasonal review probably is more appropriate.
We will keep it simple: Making reward recommendations easily understandable by contributors helps them focus on what the DAO needs. Complex rewards lead to “hacks” (e.g. like tip farming)
Example: Create guidance via “Reward Personas'' and “Work Categories”. These can be used as a reference and tweaked based on specific context.
We will calibrate rewards to a target monthly and yearly take-home: Make sure it meets expectations (i.e. higher than minimum wage, covers your cost of living).
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.
1,450
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:
(Eligibility) that they should be paid
(Type) what the reward should include
(Terms) how they should be given the reward
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
Variable Definitions:
Market Price: Wages for comparable web2 job (e.g. using glassdoor, or other benchmark like web2 salary midpoint)
Conversion Rate: USD to Token price conversion, could be defined as spot price on day of payment or 30-day average.
Multiplier: Increased payout based on internal demand, work complexity, effort level (could be between a 1-3x adjustment)
Volatility Risk: Increased payout based on liquidity availability, DAO maturity, market sentiment, recent digital asset volatility (e.g. usually a 1-3x adjustment)
Upside Opportunity: Decreased payout based on expected growth. Note this should be carefully considered since forecasting increased valuations is likely inaccurate.
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:
Set Targets: If average time on the website increases from 30 sec to 45 sec, then provide payment of X tokens.
Commission: At Cabin we sell weekly passports for IRL gatherings of guilds and DAOs. If a member successfully sells one of the passports, they receive 10% of the value.
Payout Curves: Inspired by the pay ranges of traditional sales teams, a DAO could pay out X tokens at 100% of goal but a 200% payout at 150% of goal. You can read more about these types of models here.
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.
Selected Team Consensus: A few selected people are given permission to approve rewards. For example, a specified community member, identified as the Guild Lead, tells the team that the proposed reward is either in line with the plan or not.
Community Consensus: Community members vote via Tally or Snapshot to approve the reward proposal. This is typically used when agreeing on (1) recurring payments to part-time or full-time contributors, or (2) retroactively awarding contributions (e.g. via Coordinape).
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:
Network (Geography, Gender, etc.)
Inheritance (OG, Founder preference)
Assets (PFP, Digital Inventory)
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)
https://docs.google.com/spreadsheets/d/1ZDTFlMMEPAQCyq5P2yvckrr1kqK2UH5oePGPtaHXJkI/edit?usp=sharing
salary.com: https://www.salary.com
LinkedIn: https://www.linkedin.com/salary/
Example Bounty Boards:
Subjective Contribution Allocations: https://coordinape.com/
Objective Activity Analysis: https://sourcecred.io/
Invoicing: https://gilded.finance/
Recurring Payments: https://parcel.money/
Stream Money: https://pay.sablier.finance/
Tipping and Gates: collab.land
Payment Management: request.finance
Payment Automation: https://www.utopialabs.com/
Programmable Cashflows: http://superfluid.finance
Token Creation, Vesting, Airdrops: https://www.coinvise.co/
a set of [permanent members] a [lobby] of contributors a [recruiter] assembling teams for each initiative
SeedClub: https://forum.seedclub.io/d/3-scp02-compensation-framework-for-contributors/5
DAOHaus: https://forum.daohaus.club/t/discussion-contributor-compensation-revamp-proposal/1958
Forefront: https://forum.forefront.news/d/35-ftpt-contributors-onboarding-proposal/5
1Hive: https://forum.1hive.org/t/1hive-gardens-retroactive-funding/4469
Cabin: https://snapshot.org/#/cabindao.eth/proposal/QmRw1z13s2ULL9vmK5iDt1kdygvcGkKF3s7Yke8SaKbj5s
Governauts Reward: https://forum.gnosis.io/t/governauts-rewards-systems-research-initiative/1790
Contributor Benefits (401k, insurance): http://www.opolis.co/
Payment distribution: https://disperse.app/
No comments yet