###### tags: `RIPs` `Smart Contracts` `Open Source`

# Cohort Staking with Soul Bound Tokens

### Project Submitted By

st4rgard3n the 2ed

## Summary

DAOs commit resources towards onboarding, while cohort participants often have little to no skin in the game. This can lead to wasteful outcomes, in terms of DAO resources and onboarding success rates.

Raid Guild is introducing an open source staking and soul bound token cohort dApp, for asynchronous onboarding and built to be interoperable for Moloch DAOs.

DAOs can deploy their own cohort clones, which require users to stake certain assets. The participants receive a soul bound token, after staking, and this token is used to provide gated access to the cohort and resources.

The staked assets are then forfeited if the user doesn't complete the onboarding process. The individual cohort contracts are not upgradeable, but the cohort clone factory contract enables additional implementations to be added.

Currently the cohorts are specifically designed for Moloch DAOs and DAOHaus, but we can easily add new implementations for staking NFTs, or different membership criteria.

## Why should we build this?

This tool has the potential to retain engagement and support cohort facilitation, while supporting cohort organizers.

As the dApp is tested on Raid Guild apprentice cohorts, it can be iterated, improved upon and productized and/or open sourced.

## Raid Party Skills Needed

- Design
- Smart Contract Dev
- Front End Dev
- Subgraph Dev

## Cost (in USD)

## Next Steps

### Front-End
- SLC front-end enables staking to join a cohort and claiming stake as a successful DAO member.
- (Optional) Allows deploying new cohorts for other MolochDAOs
- Countdown clock until the connected wallet's deadline

### Subgraphs
- Tracks cohort deployments
- Tracks data about all cohorts; including our handy logged "Cry For Help" events which create a system for on-chain feedback collection.
- Tracks participant deadlines, so that past due initiates can be sacrificed

## Anything else you'd like to add?

### Contracts already completed:

#### TLDR: CohortFactory deploys new Rite Of Moloch contracts. Rite of Moloch contracts contain the logic for a cohort.

## CohortFactory
- Generates minimal proxy clones for authorized implementations
- The clones are initialized by setting the cohort's parameters such as:
- The membership criteria contract address (For the first implementation this is a MolochDAO address). Other membership criteria could be owning an NFT or a certain number of ERC20 tokens
- The staking asset contract. (For the first implementation this is an ERC20 token). This is used to transfer the stake tokens to and from the initiates.
- The treasury address. This is the address which receives forfeited stake from past due initiations.
- The threshold of membership criteria. (In our first implementation this is the number of MolochDAO shares which constitute membership.)
- The amount of the staking asset required to join the cohort.
- The name and symbol for the NFTs.
- The base uri; which is a link to where the token's Metadata will be stored.
- The implementation selector; for use with future versions of Rite of Moloch

## RiteOfMoloch
- Holds participant's staked assets
- Keeps track of when people join the cohort
- Keeps track of all initiates
- Joining cohort requires staking token
- someone else can also sponsor the new cohort member
- after staking, the initiate receives a soul bound cohort token
- If they become a member within a certain time, then they can claim their staked tokens back
- Initiates who do not become a member by their deadline, are sacrificed. Their staked assets are sent to the treasury address

### SBT
- NFT where the transfer function has been overwritten so it reverts
- Address is locked to the recipient of the NFT when it is minted
- Joining cohort gets you this NFT
- NFT acts as an on-chain achievement for joining the cohort
- NFT is also an access pass enabling the cohort to be token gated and access to be automated

## Future Use Cases

*Currently, not integrated with champion staking.*

Options for the future
- champion can stake for initiate and then stake again for membership
- possible for champion to get staked raid back
- add more functionality
- accomicate different circumstances

____

*Do not include the following in the RIP proposal.*

## Assorted Notes:

The contract itself can summon other contracts (factory contract)

Contract is 100% ready for front-end and subgraph development to begin. It can be changed and modified as the front-end and subgraph demands.

Front end (Plor) is about 3 months away

subgraph (Scott) is about 3 months away

Cost??? Paid in RaidGuild Shares at $5 / share?

## TW's feedback
Here's some feedback:
- The Problem section is really more of an Overview or TL;DR section, which is good for high-level context. The Problem statement should be as succinct as possible, followed by a comparably short and clear Solution. The Why section could be folded into Overview.
- All the content from Contracts through Potential Changes should be framed as the scope of work. This section could separate the work (short and clear) with the justification (justification and value add). Ideally this would be accompanied by milestones, roadmap, gantt chart, or similar.
- Most importantly (as with all grant/funding proposals) is a concrete list of deliverables, team, and budget/total ask. This should include a contract address to send the funds and could also include terms for comp distribution.

___