# Payroll Protocol: Decentralized Protocol Payroll Why: To pay contributors efficiently. Idea: A DAO sets a budget for [X role] payroll. Token delegates get a share of say equal to the proportion of tokens they hold. Each delegate provides [white-listed] addresses and corresponding weights. Results are aggregated and pay is distributed accordingly. ## User stories ### Protocol development payroll The gov board or multisig whitelists timmy.eth and tom.eth for the development role. The gov board sets a budget of $10M annually for development. a16z with 50% of the vote says 10% to timmy and 80% to tom, with 10% going to nobody. a16z's pay share distribution is $10M * 50% * 10% = $500K annualized for timmy and $10M * 50% * 80% = $4M annualized for tom. Polychain with the other 50% of the vote says 50% to timmy, with the other 50% going to nobody. Polychain's pay share distribution is $10M * 50% * 50% = $2.5M annualized for timmy and none for tom. Aggregating the results, the final pay amounts for the development role are: - $3M annualized for timmy - $4M annualized for tom - $3M unallocated If a16z or Polychain goes rouge and whitelists themselves for every role and pays themselves for every role, everyone else will know and can act accordingly. Not everyone has to vote on pay - they may abstain and their voting share will be redistributed. Or they may even vote for 0 distributions for any or even all roles if they really feel like nobody deserves payment It's ultimately up to how much COMP a person holds. Contributors could acquire more COMP to be able to pay themselves more... and **this is a great feature**! ### Individual grants funding Let's say the gov board approves a $250K budget to develop marketing materials. Let's also say that the gov board has empowered a multisig to control the whitelist for this role. That multisig whitelists alex.eth and adam.eth for the role as they're both two great candidates. Now let's say that the overall vote share distribution is: - a16z: 40% - Polychain: 40% - Getty: 10% - Tyler: 5% - Larry: 5% It's time for a vote on how the funds are distributed. a16z and Polychain choose to abstain because they are out of the loop on this initiative and they trust the other voters' judgements. This leaves the following pay share voting distribution: - Getty: 50% - Tyler: 25% - Larry: 25% They each vote 50% to alex and 50% to adam, so that becomes the end result - $125K annualized to adam and $125K annualized to alex. Now let's say a month goes by and alex abandons the project. A new vote is proposed, resulting in adam getting 100% of the pay for the role. Alex ended up getting $125K*(1 month / 12 months) = $10K for his work and is no longer on the payroll. Another month goes by and adam finishes the project. The majority of the voters agree that the work is worth all of the undistributed funds in the budget, so they close the payroll for this particular role, releasing all of the undistributed funds to adam. After 2 months, alex got $10K for his incompleted work and adam got the remaining $240K for his great work. ## Protocol spec This idea of decentralized protocol payroll was designed specifically for Compound, but it can also be expanded into a whole new protocol. The specs are as follows. - Customizable governance boards that can be deployed for any voting token such as COMP - Governance boards such as Compound Governor Bravo can give these boards specialized permissions to allow funding payrolls - UIs can be designed to display these additional governance boards alongside protocols' main governance boards - 0.05% of payroll is collected as fees - These governance boards can start out as just boards for voting on compensation (MVP) and can later be expanded to form a larger protocol for governance of any organization (in competition with Aragon) - The idea of customizable governance boards was _started_ in September of 2021 as an [opinionated adaptation of OpenZeppelin's governance contracts for Pythia](https://github.com/pythia-oracle/pythia-protocol-old/tree/development/contracts/governance).
Last changed by  
 
TylerEther
341

Read more

COMP Reward Adjustments v2

After many discussions with Getty, I'm pivoting my prior COMP Rewards Adjustments proposal. The objective of the COMP rewards program was initially to distribute the token to our users. The sad truth is that an overwhelming amount of the COMP rewards are being farmed and instantly sold off, making the rewards program ineffective in achieving the initial goal. I believe there’s a clear need to re-evaluate how best to distribute the token to our community. When a market first launches, we don’t see much activity until the market receives COMP rewards. There’s little incentive to deposit into it when there’s no borrowing demand (or rewards), and there’s no borrowing demand because there aren’t enough tokens to borrow to make the cost of the borrow transaction worth it. A market needs to have great enough incentives for depositors to provide enough liquidity to make the cost of borrowing worth it. The above statements I made in my prior proposal still hold. At the time of writing, I advocated for our users - who are also token holders - to continue receiving a share of the protocol. Decentralization of ownership matters. However, my perspective on the overall issue was slightly incorrect.

4/15/2022
Compound Market Listing Framework

Consideration points: Token Etherscan link Contract code verified and open-source? Team Who? Experience in their respective field

3/9/2022
COMP Rewards Adjustments

Building off Getty's discussion of COMP distribution speeds, I think we should be more intentional about how COMP is distributed. The objective of the COMP rewards program was initially to distribute the token to our users. The sad truth is that an overwhelming amount of the COMP rewards are being farmed and instantly sold off, making the rewards program ineffective in achieving the initial goal. I believe there's a clear need to re-evaluate how best to distribute the token to our community. This is something that will evolve over time, so it doesn't mean we have to completely figure this out before changing the existing program. Rather than distributing massive amounts of tokens arbitrarily to markets, I propose changing the existing rewards program (as just one of our rewards programs) to utilize COMP rewards to: Strategically incentivize growth while maximizing profits (minimizing losses), and Maintain minimum market sizes When a market first launches, we don't see much activity until the market receives COMP rewards. There's little incentive to deposit into it when there's no borrowing demand (or rewards), and there's no borrowing demand because there aren't enough tokens to borrow to make the cost of the borrow transaction worth it.

3/6/2022
Multi-Chain Evaluation Framework

Criteria Decentralization Consensum mechanism Number of active validators (past 14 days) Validator share distribution (past 14 days, gini coefficient) Token supply distribution (top 100 holders on Ethereum or on the chain itself, gini coefficient) Network statistics

3/4/2022
Read more from TylerEther
Published on HackMD