# "Kazoku" A Family of Hats Protocol enabled MolochDAO Shamans
###### tags: `SilverDoor`

## Overview

There's lots of really cool ways that Hats protocol adminstration schemas can interact with Moloch DAO v3 in order to increase coordination.

They range on the spectrum from; highly coersive to non-coersive.

They can concentrate power; while maintaining arbitrary programmatic decentralization.

---
## Concepts

There's two core concepts that power these shamans. The first is the commitment; which commits the DAO to providing a certain reward in exchange for the completion of some form of value attached to a proposal.

The commitment contains all of the necessary data required to:

- Inform all DAO members what value they receive
- Clearly define the reward received by the recipient
- Allow flexible reward systems for shares, loot or another ERC20 token
- Enforce that commitments are not processed faster than the DAO can execute a vote
- Prevent replay attacks
- An eligiblity hat id; this determines if there's an eligibility requirement for the recipient

The commitment struct contains the following data:

- The number of shares to mint for rewards
- The number of loot to mint for rewards
- The amount of ERC20 extra reward tokens
- The completion deadline of the project
- The timestamp where the commitment was lodged on-chain
- An Arweave content digest hash which allows the proposal to be discovered indefinitely (or IPFS hash etc)
- The token recipient's address
- The extra ERC20 reward token contract address

The proposal is marked by it's content digest hash from Arweave.

// the Arweave content digest can be used to retrieve the proposal forever
// Mirror Arweave retrieval ( https://dev.mirror.xyz/GjssNdA6XK7VYynkvwDem3KYwPACSU9nDWpR5rei3hw )
/// @title Commitment
/// @notice This struct serves as the primary data storage for each sponsorship commitment.
/// Each field within this struct represents a specific parameter of the commitment.
struct Commitment {

    /// @notice The ID of the hat that the recipient must be wearing.
    /// @dev If set to 0, there is no requirement for a hat.
    uint256 eligibleHat;

    /// @notice The number of shares to be minted for the recipient.
    /// @dev This is part of the reward that the recipient would get upon successful completion.
    uint256 shares;

    /// @notice The number of loot tokens to be minted for the recipient.
    /// @dev This is also part of the reward that the recipient would get upon successful completion.
    uint256 loot;

    /// @notice Additional token rewards other than shares and loot.
    /// @dev If set to 0, there are no additional rewards.
    uint256 extraRewardAmount;

    /// @notice A UNIX Timestamp element that represents the time factor of the commitment.
    /// @dev The effect of the time factory can change from different Kazoku shamans.
    uint256 timeFactor;

    /// @notice The UNIX timestamp when the sponsorship was created.
    /// @dev This is set automatically when the sponsor function is called.
    uint256 sponsoredTime;

    /// @notice The UNIX timestamp when the commitment can no longer be claimed.
    /// @dev This is manual but must adhere to social and legal requirements
    uint256 expirationTime;

    /// @notice URL linking the commitment on chain to the commitment off chain.
    /// @dev This is used as an identifier to retrieve the proposal details.
    string contextURL;

    /// @notice The metadata of the commitment.
    /// @dev This is used to store additional information about the commitment.
    string metadata;

    /// @notice The address of the recipient of the sponsorship.
    /// @dev The person/entity that will receive the shares, loot, and possibly extra rewards.
    address recipient;

    /// @notice The ERC20 token address for additional rewards.
    /// @dev If set to address(0), there are no additional token rewards.
    address extraRewardToken;

}

The Sponsorship Status enumerable just allows us to track exactly what state the commitment is in at any time; and reinforce the integrity of the commitment.

/// @title SponsorshipStatus
/// @notice This enum represents the various states that a sponsorship can be in within the contract.
/// @dev The SponsorshipStatus enum helps track the lifecycle of a sponsorship and is integral for business logic within the contract.
enum SponsorshipStatus {

    /// @notice The default state of the sponsorship before it is created.
    Empty,

    /// @notice The initial state of the sponsorship when it is created.
    /// @dev In this state, the sponsorship has not yet been reviewed or approved.
    Pending,

    /// @notice The state indicating that the sponsorship has been approved.
    /// @dev In this state, the sponsorship is considered valid but has not yet been claimed by the recipient.
    Approved,

    /// @notice The state indicating that the rewards for the sponsorship have been claimed by the recipient.
    /// @dev In this state, the sponsorship lifecycle is considered complete.
    Claimed
}

---
### The Seneschal

The Seneschal shaman enables a high degree of agency for DAO operators to grant shares, loot and ERC20 rewards to value creating participants. It enables piecemeal task to task incentives for DAO participants. It's entirely non-coersive; and useful for high-trust organizations.

It also combats the "lore keeping" problem of DAOs, because it creates incredibly persistent and available data utilizing Arweave. This allows DAOs to keep a permanent record of all of the different value creation proposals over time. Seneschal also has a simple out-of-the-box ChatGPT integration to demonstrate how this persistent contextual data can empower DAOs to utilize large language model artificial intelligence.

The Seneschal enables as few as three people to coordinate and create value for the DAO with extreme agency and speed:

- It starts with a person, the proposer, who has an idea for how to create value for the DAO. They craft the idea into a proposal with clear milestones, scope and deliverables and publish it to Arweave; most likely using [Mirror](mirror.xyz).
- Then a person wearing the "sponsor" hat evaluates the proposal. If they deem the proposal is an effective way to create value for the DAO - the Hat wearer can then sponsor the proposal; turning it into a commitment between the DAO and the proposer.
- After the proposal has been completed by the proposer; the proposer can create a completion report and submit the report to "poke" the proposal. This is to indicate that the completion report is ready for review.
- Now it's time for the "witness" hat wearer to review the original proposal, and the completion report. If they are able to verify that the proposal was correctly executed - they can then approve the commitment.

- After a commitment has been sponsored and witnessed it can be claimed any time before the expiration date by the original proposer recipient.

The contract works in the following way:

- Uses the `Commitment.timeFactor` as a deadline.

- Uses a delay to ensure that commitments can't be sponsored and processed before the DAO has time to react. This is achieved through a state variable `claimDelay` which is always added to the attached DAO's `votingPeriod()` and `gracePeriod()` for dynamically ensuring commitments can never be processed before the DAO has time to act.
- This allows wearers of the "sponsor" hat to enter a particular proposal and reward on-chain. The proposal is a thing that must be completed by the recipient before the deadline.
- The "witness" hat has the ability to verify a commitment. The "witness" marks proposals as completed; and after this the claiming of the reward is enabled.
- The "witness" and "sponsors" should never be the same person and are high trust hat roles.
- Once the commitment has been "witnessed" it can be claimed any time before the expiration date. The reason we don't immediately issue rewards is because of the risk of "phantom income". That is; when issuing shares or loot tokens - it's incredibly important that exercising the option to claim these tokens is left to the discretion of the recipient.
- Allows clearing of commitments that have expired past the deadline.
- Allows poking the witnesses after the `claimDelay` but before the deadline. This is to indicate that a commitment has been fulfilled and the user's completion report is ready for review.
- The metadata field allows frontends to dynamically act on sponsorships without the need of maintaining a backend database; everything can be handled from a subgraph.
- The context URL is used to reference the committed project's scope and deliverables. In our case we utilize this space for a Mirror link which also contains the Arweave content digest so that the proposal will eternally be retrievable.
- The extreme degree of data permanence of using Arweave allows us to utilize large language models far into the future - in order to help solve the "lore keeping" problem in DAOs.
- It also utilizes a pure signature based scheme for sponsoring, processing and claiming to be compatible with relayers. This could enable custodial and gas-less onboarding for improved UX.
- It also utilizes EIP1271 contract based signatures so that things like token bound accounts, or other smart contracts can be easily composed.

---
### The Guildmaster

The guildmaster is a variation of the seneschal which does not fix the the proposal and recipient together. This allows an individual to create bounties; limited proposals and scopes which are offered up to anyone who meets the criteria.

Mechanics:

- The "proposer" hat allows a DAO member to create on-chain bounties.
- The bounties could be set up in a number of different ways:
- They could be first come complete first serve (Whoever completes the bounty first gets the reward).
- They could function like an auction; and be reserved.
- They could receive token deposits which act as skin-in-the-game and sybil resistance.
- Deposits could be forfeit if tasks are not completed.
- The on-chain bounty data could include:
- The amount of reward tokens. If left 0 this could enable triggering of auction.
- The deposit token contract address.
- The amount of deposit tokens required.
- Whether the tokens are loot or shares.
- An Arweave transaction hash which links to the proposal.
- The time stamp deadline of bounty completion.
- The time stamp deadline of the auction.
- Participants who meet requirements could "accept" the bounty by placing their deposit in the contract.
- Participants could bid on the bounty both in terms of the reward and deposit amounts.

---
### The Taskmaster

The taskmaster shaman enables DAO agents to coerce individual participants. Taskmasters are individuals who can forcefully assign tasks to individual members.

Here's how it could work:

- The "slicer" hat would have the ability to burn an individual user's shares or loot; and attach an assignment.
- "Slicers" would need to have some form of limitations imposed on them; otherwise they could essentially brick a DAO by destroying everyone's shares.
- When the user's share or loot is burned; there's a commitment hash stored on chain which encodes:
- The token recipient's address
- The amount of tokens
- Whether the tokens are loot or shares
- An Arweave transaction hash which links to the proposal.
- The time stamp deadline of completion.
- The "mender" hat would have the ability to reverse this burn; based on verification of the completed task.

---
### The Evergreen Robot

The evergreen robot enables automation of simple tasks that require regular completions. It's an autonomous reverse VRGDA for evergreen tasks and content. It requires participants to wear a specific hat; and optionally can require a token deposit.

Here's how it could work:

- The smart contract has a continuously active price it is willing to pay for a certain task to be completed.
- The reward rate or price gradually increases as determined by the variable rate gradual dutch auction mechanic parameters.
- A state variable encodes the Arweave hash which links to the proposal and instructions for completing the task.
- Users wearing an "eligible" hat would be able to commit at any time to completing the task at the current reward rate.
- Anytime a user accepts the task; the reward rate drops.
- The commitment hash would encode the following information:
- The time stamp deadline of completion.
- The deposit token address.
- The deposit token amount
- The reward amount
- Whether the reward is shares or loot
- Wearers of the "robot whisperer" hats would be able to accept the commitment hashes as completed and set a completion hash.
- The completion hash could:
- Contain the Arweave transaction hash of the completed work.

---
### The Merman

The merman shaman is a multisignator contract which allows a large dispersion of loot and shares to DAO participants. A complex merkle tree is encoded; and it's root is posted on chain to enable claiming of loot and shares.

Think Christmas Bonuses.

Shoutout to ***YoungKidWarrior*** for the original concept of using a merkletree to allocate DAO shares by a shaman.

Mechanics:

- "Merman" hat wearers will be a Safe multisig w/ Hats Signer Gate guard.
- The counter will indicate a specific distribution.
- Users can claim the exact number of shares for the given distribution.
- Will likely actually be multi signatory using a Hats Signer Gate and Safe multisig.
- Can also convert inactive members to non-voting members; similar to Hats Onboarding Shaman by burning shares and minting loot.

---
### Druid


The Druid shaman allows "salary" of DAO shares, loot or ERC20 tokens over a time period.