Contributor Compensation and Transparency report Process Change Ideas

Introduction

In a previous post I discussed options to streamline the flow for paying contributor streams and rationalizing the process so all participants understand how the process works and what is required of them. You can read that here: Rationalizing Contributor Streams

That post mainly dealt with the YAM portion of contributor compensation. This post will build on that and focus on similar principals, but try to address both stablecoin and YAM compensation, as well as how to keep the process transparent, accountable, and scalable.

Because the DAO works primarily through on-chain actions, paying contributors has been a larger effort endeavor than many expected when first designing the compensation system. What started out as a process to pay contributors in a transparent and incentive aligned way has not always lived up to those promises and as time has gone on, this process has taken up more and more valuable time from contributors. And after some recent departures, it now needs an overhaul.

Goals

Before we get into my proposed plan, lets lay out how we want the process to work and what the goals of it are.

  • The Process should be transparent for contributors and token holders.
  • Contributors should be held accountable for the work they do and not be able to “game” the system
  • Contributors should be fairly rewarded for their work.
  • Payment should be incentive aligned.
  • Payments should be for work that has already been done.
  • The process should require as little overhead as possible from contributors and token holders to achieve the above goals
  • [Happy to add more if people have suggestions]

How the Current Model Works

The existing compensation works as follows:

  1. Contributors make a proposal to governance to work for the DAO and lay out what their roles will be and what they expect their compensation to be. It is unclear what is required to submit these proposals, or whether they are vetted or not. A HR committee was created to try and streamline this process (I am a part of that committee).
  2. Once approved, contributors will work on a trial period for a few months, where they are paid entirely in YAM.
  3. After the trial period they will earn their full compensation in the breakdown of their choosing, up to 70/30 stable/YAM split.
  4. Every month, contributors are expected to fill out a contributor compensation report to be posted publicly on this forum. The HR committee reviews the performance of contributors monthly.
  5. Contributors are paid monthly in stablecoins for work done over the last month. They have streams opened every 3 months for their YAM portion of pay.
  6. If a contributor stops contributing or leaves, the HR committee has to actively stop their stream and make sure that they don’t get paid their stablecoins. This puts a lot of power in the hands of the HR committee, and also a lot of work to assure that everyone is on task and contributing sufficiently.

Issues with the current model

  • The YAM vesting doesn’t work as intended: The idea of the YAM streams was for vesting to occur over a 3 month period. But this implies that the YAM earned for the last month would vested over the next 3 months. Instead, the YAM to be earned over the next 3 months is streamed in real time.
  • Accountability requires additional overhead from the HR group.
  • Transparency reports are not seen as important (based on how quickly they are filled out) and require that the HR group coordinates and pesters contributors to fill them out.
  • There is limited ability for contributors to work a flexible schedule that varies from month to month because the rates are set beforehand.
  • There are limited opportunities to do work via different models (bounties, milestone based compensation, etc).
  • YAM voters rely on a small group of contributors to make sure that work is being done efficiently and that all contributors are working effectively.
  • The DAO risks becoming an “employer,” which could lead to regulatory issues.
  • Doing all compensation via on-chain transactions via full governance adds overhead and complexity for paying contributors.

Proposed Changes

These proposed changes come in 2 parts. One part is the changes to the process that contributors would follow and the other part is the changes to the process that that DAO would follow to pay them.

Contributors

  1. Those who wish to contribute to the DAO will post to the forum with their initial proposal. It should describe what they plan to work on, expertise, and an hourly rate (guidelines should be provided). This information can be ratified via snapshot voting, and is very similar to the current procedure where a contributor will “apply” to governance.
  2. If desired, a trial period can be created for a new contributor in which some of their compensation is held back until the end of the trial, at which they are paid in full. If they are not a good fit and do not reach the end of the trial then they will no receive the held pay.
  3. At the end of the month, all contributors who have done work that month and wish to get paid will need to submit a compensation request to the forum, outlining the work that they have done in the prior month and confirming the rate and total amount. These requests are like public timesheets.
    • The requests will be reviewed before being added to the contributor payment transactions
    • The requests also serve as transparency reports and give insight into what each contributor has been doing.
    • Contributors who do not submit a compensation request by the deadline will not be paid in that month’s transaction and will have to wait until a later transaction.
  4. Contributors will be paid stablecoins for the work they did at their pre-determined rate. The YAM portion of their Pay will be determined based on the 30-TWAP determined at the end of that month and deposited into a custom (or sablier) stream with a continuous vesting period (3 months)

Governance and DAO process

  1. YAM governance will need to review initial contribution proposals with the help of the HR committee, when new contributors are on-boarded.
  2. The HR committee should review contributor compensation reports and the public can also review all contributor compensation requests as they are made monthly.
  3. Governance pays contributors who correctly and accurately submit compensation requests in monthly batches.

Streamlining Payment

Right now, all payments happen via on chain vote. This requires a lot of overhead from contributors and governance. We can move to a multi-sig model that limits risk of lost funds for the DAO, but greatly increases speed and flexibility of the process.

A new contributor compensation multi-sig would be created that holds funds to be distributed monthly. It can be filled monthly or quarterly from the treasury with stablecoins and YAM earmarked to pay contributors. This multi-sig can be signed by the HR group as a 3 of 5 model. Payment is sent to contributors directly from this multi-sig, and new streams are opened from here as well.

As a further addition in the future, a new contributor compensation guardian contract can be added to allow the community to use governance to stop any transaction from the multi-sig and revoke funds if it is deemed that the HR group is acting against the wishes of governance. A new implementation of this model of optimistic approval has been created by withTally using gnosis safes and compound governance (like what YAM uses): GitHub - withtally/safeguard: Safeguard is a tool for on-chain Ethereum DAOs to delegate funds to multisigs while keeping some level of control

Conclusion

Moving to a model like this will clear up the interactions between contributors and the DAO, allow more transparency, and pave the way for a more decentralized future for YAM. We need to start thinking about contributors to the DAO as contractors, and the payment mechanisms as contracts between contributors and the DAO, and not as an organization with employees and traditional corporate structures. Those structures can get built on top of the DAO as it grows and requires more specialized work. This will also allow different groups of contributors to craft different types of organizations to contribute to YAM as they see fit.

All of these changes will require work and additional consideration, but this is a key part of building a better foundation for YAM as we move into the future.

1 Like

It’s good Ross. Definite improvement, but is this focused only on core contributors? Have you explored ideas around other models of compensation for non core folks, gig work, etc?

I agree with @designer that this is a definite improvement.

I started the original contributor compensation over a year ago with guidance from the YAM founders and initially, I believed it was the proper course but as we have developed over this year, the team dynamics have changed and Yam has grown. I now believe our previous compensation system needs an upgrade and this is on the right track.

Overall this feels like a much lighter weight contractor compensation system, where each contributor is responsible to get their work done but also make a request to be paid for the work done. Here are some notes:

  1. Streamlining payment - Something def needs to be done, it requires a lot of overhead to submit and process payments. If we want a more flexible compensation system, it needs to be easier to use vs on-chain proposals. What is the procedure / overhead / setup required for using withtally?
  2. HR committee needs to make sure they are regularly reviewing and approving. They are not responsible for compensation but only to verify and and provide guidance for a snapshot vote for the actual payment. HR committee is not an employer.
  3. Pre-determined rate for each contributor should be calculated down to a hourly rate based on a commonly accepted salary site (ie. Salary.com) + a % multiplier due to the lack of benefits vs normal employment. Each month, contributor is required to keep time card records to be submitted to HR. Maybe this is too complicated, open to suggestions.

Ideas above, open for discussion.

I see this as focused on the current contributors, but not specifically toward full or part time, or what might be considered core contributors.

I imagine that the model proposed above would work better for “non-core” folks and I think we should start to move away from this idea that there is a “core team.” There are people that work on the project regularly and the community has come to trust who could be considered a core team, but are not in some position of power other than what is specifically given by governance.

So some members may have admin roles in discord because they have shown interest and willingness to moderate. Some developers have shown commitment to the project so they have github admin powers, Etc. Some contributors may coordinate privately, but we should all come together for public coordination meetings, and it would make sense that there is one, or more people whose role involves this coordination.

I’m curious to hear more about how we think other models could be rolled in. I know we are exploring gitcoin bounties, and those may live outside of this system, even if they are paid by the same multi-sig.

There is a probably a step before the full implementation of the optimistic approval process from withTally, which is just using a multi-sig for payments and implementing a transparent model for the community to review the transactions.

We can add the new guardian from the Tally implementation after the multi-sig.

The HR committee feels like a crutch, at least in it’s current implementation. We should continue to look at ways that we can keep the community informed and contributors accountable without having “bosses”. For the time being, a group of contributors doing that who are aware of most of the things going on makes sense.

This is how imagine it too. The DAO hires contractors to work for it and they have to submit backup for the work they have done. It isn’t quite as simple for the people working for the DAO, but it adds a lot of flexibility around how people want to work. Maybe a group of contributors want to work on a project and it isn’t billed hourly but by milestones. We could do that this way. Or a group of contributors form their own company to work for the DAO and bill through that structure. The current model limits itself to individuals doing set amounts of work like a normal 9-5 job and adds complexity to the DAO that could be pushed out away from the governance layer.

@ross This looks great. Miles better than what we have rn.

I have some questions about the submission of compensation requests. It makes sense tying contributor transparency with initiating compensation.

How exactly will these requests be submitted? Via a form? A document? What are you thinking currently?

I’m thinking of ways this can be automated. I can see this becoming a chore to do, despite being a 5 minute task. What if we integrate with tools (figma, github, google meet, notion, etc) to show a feed of work being done in a discord channel? That way we won’t need to manually post about our contributions. What do you think?

Also, please please please, can we drop the 3 month vesting period? It’s confusing af since we are earning a stream. It’s hard to tell if you’re being compensated properly without doing some crazy maths. We definitely need better representation of compensation and it’s something I’m working on for the new Yam.xyz site

1 Like

Hey Blokku, thanks for the response!

I was assuming the MVP would just be posting in a section of the forums here. But we could work on making this more streamlined and automated like you mentioned. I just don’t want to delay the basic implementation in order to try and make it perfect. Let’s start off with the basic version and improve it based on what works and what doesn’t.

I agree that this is confusing and that is partly due to how we have is set up. The way that I believe it was first intended to work was that YAM paid out is streamed (that is the vesting) over X months. That makes sense if the YAM earned each month are dropped into a stream every month. So with a 3 month stream, the YAM earned in January are dropped in at the end of the month and stream for 3 months (until the end of april) and then the YAM eaned in February are dropped in a stream at the end of the month and stream until the end of may.

That means USD pay is immediate, but YAM pay is always time released from when it is paid out. The way that this works now is not like that. USD is pay for work done and immediate upon payment, but YAM could currently be considered streamed in real time, which is not the intent (as I understand it.)

I could be convinced that we should remove all vesting, but I do think there is benefit in the vesting/streaming period if done right.

I agree with @blokku-chan we should just drop the vesting period unless it can be done easily and efficiently. I solid reasonable pay for everyone with a % limit cap on Stables vs Yam that is paid out monthly based on work done from the multisig is simple easy and efficient.

Each contributor needs to pass a governance vote that sets their pay rate and max number of hours and scope of work they are doing. This will allow HR to verify their work monthly and sign the multisig. There should be strict rules for all parties involved that will minimize the over head but also keep everyone accountable.

Feddas

I have been asked what I think the implementation of this process change could look like. There are a few parts so lets go into them.

Social Implementation

  1. The first thing I am looking for is general buy in from our contributors and developers who use and operate the current system. If contributors hate it then it probably won’t work. So far it seems like contributors are generally supportive, but I want to make sure everyone can voice their opinion.

  2. Once there is consensus among the current contributors that this is a good plan, we should throw a vote up on snapshot to make sure the community agrees. Before doing this, we probably need to flesh out some more details like hourly rates, edge cases, process, etc.

  3. Assuming that snapshot passes, we could start this process immediately without any further votes or changes to the process. All contributors would submit monthly pay requests outlining work done and the HR committee could verify the work had been done. (We could use another mechanism for verification, but for right now this is the infrastructure we have so it makes sense to start with it.) After the monthly reports are reviewed, the compensation amounts can be calculated and paid out to contributors via an on-chain vote (like we currently do).

On chain and code implementations

Multi-sig

If we want to further streamline the process to move compensation to a multi-sig then we would need to determine who the signers should be (It could start as the HR committee, or could add signers, or could be other signers.)

  1. A snapshot vote would be needed to ratify the multi-sig signers and an on-chain vote would be needed to send funds to the multi-sig from the treasury. Monthly, or quarterly, on-chain votes could be used to re-fill the multi-sig for the next month’s payment.
  2. contributors would then be paid via multi-sig monthly, removing the need for the more complex on-chain contracts currently used to pay contributors.

YAM Streams

Upgrading the YAM stream model could also happen gradually. The simplest solution would be to send YAM from the contributor vesting pool (where the YAM is currently stored) to the multi-sig, or if we are still using on-chain governance for compensation, to simply pay contributors part in YAM and remove the vesting temporarily.

  1. If we assume that we will move to a multi-sig model for payments, then we can start using sablier streams, or update our own streams contract to be paid out monthly. Every month when the compensation requests come in, we use the multi-sig to send out stables as owed, and we open up new streams for the YAM portions of the payment, based on the 30 day TWAP set at the end of the last month.

6a. Doing the same without a multi-sig just means that the on-chain transactions would pay and open streams for each participant.

Updating the streams in this way will change how our compensation page works, and will require that it can show that users have multiple streams open that can be claimed from. Or we could update to use a service for this management like liquifi, which is essentially a sablier management system with added bells and whistles.

Optimistic execution

The most complex and ambitious piece would be adding guardrails to the multi-sig via a governance controlled guardian. I imagine this comes last in the process.
*note: there already are guard-rails for the multi-sig if only enough funds to pay contributors for a month are 2 are sent to the multi-sig at a time

  1. Implementing the guardian would require engineering and smart contract work, including deploying a new contributor-payment-multi-sig timelock contract and the guardian for that contract. It would also require the design of an interface for governance to interact with it.

That’s it, let me know if you think I missed anything.


Addendum: Even more decentralization

If we find ourselves at a point where we want our contributor compensation multi-sig (or another multi-sig) to be more decentralized, we can find a middle ground using safesnap and the withTally guardian. Safesnap would allow tokenholders to vote directly on multi-sig transactions with a custom quorum and then be cancelled by full governance with a higher quorum requirement.

This would allow streamlined and free voting to propose and pass proposals, and a higher bar and cost to cancel them. This may just be unnecessary, but we are moving to a place where there are lots of trade-offs available in the efficiency/trustlessness spectrum for getting things done.

There are other tools coming out that allow similar processes. One is comp.vote and uni.vote, which allows users to sign messages as votes (like snapshot) and those signatures then get aggregated and submitted as one (or 2) votes in on-chain governance.

can you elaborate on your thoughts about these rules?

My suggestion would be just to do away with all streams and pay according to work done at the end of the month after contributor report submission.

  1. Creating a template and procedures for any and all contributors to fill out for governance approval of compensation.
    Term could be limited from 6 months to a Year but at will termination if HR decides that the contributor is not following what was approved by governance. ie. Dev says I will be updating yam.synths front end for all new projects and completing it on time for deployment and they end up missing many deadlines to deploy on time. HR reviews work and recommends for termination based on what was not completed satisfactory. Obviously unreasonable timeline or work load will be discussed during team meetings, where if it is too much to handle, we won’t announce deployment by xx date. The point is to create a system of coordination / responsibility / accountability.

  2. Creating HR procedures to keep contributors accountable.
    HR meeting once a month to review all previous work done.
    A template for each contributor to submit their timecard/work for the month with more detail than our current monthly transparency reports. Let’s find a good template and fork it.

Just some ideas.

Feddas

This is definitely the simplest way, but it is not the most incentive aligned. The goal of the vesting is to give contributors some skin in the game. The vesting means that they can’t just sell everything immediately. We changed the ratio of stables to YAM so that contributors can earn what is hopefully a competitive pay rate without having to sell their YAM. If the YAM vests over the next few months after earning it, a contributor is incentivized to hopefully continue promoting looking out for the best interests of the project.

The current model doesn’t do that since the YAM is essentially earned in real time. A 3 months stream opened in January has 3 months of the YAM portion and pays out linearly until those 3 months are up. So it is both confusing and doesn’t align incentives any better than just paying YAM normally.

A 3rd option to think about for the future, if we move to a model where you lock YAM to vote and earn rewards is that we pay in locked YAM and that is our vesting.

I agree we definitely need this.

We should make sure that the recommendations for this are done publicly and doesn’t devolve into a shadowy group of bosses who decide who gets hired and fired. That requires that job descriptions and deliverables are well stated and we can make good decisions based on it. What happens if we have an incredible contributor who fills out really shitty compensation reports? I guess we cross that bridge when we get to it.

We also need a way to keep the HR group accountable. They should answer directly to the other contributors and governance.

I seem to always be posting links to DXDAO, but that’s because they have their shit together. They do a similar form of this. Here are some examples:

Part of what we will need to do is lead by example. If the current contributors are just writing 6 lines about what they did then people aren’t going to write good proposals. If we can show our own examples of what we expect for these proposals then we can hold everyone else to that standard.

1 Like

Yes, this looks great. Let’s move forward with next steps.

One last post here before I move this forward as a proposal.

We have been discussing how the YAM portion of contributor payment should be paid. I still believe that adding some vesting to the YAM paid is worthwhile, but understand that it adds complexity to do it right and will add a bit of developer overhead. So with that in mind, I want to show that our current “streaming” model for YAM is equivalent to sending YAM monthly just like stables.

In the current model, governance approves streams to be opened in 3 month chunks, and 3 months of YAM compensation is deposited into the new stream. While it is somewhat subjective whether you consider the stream opened as paying for the next 3 months, or for the past month and future 2 months, based on the way our trial period works, I view the streams as paying contributors for the 3 months looking forward.

In practice, this means that streams pay in real time, as every second, or block, some of the stream is unlocked to be claimed. Because 3 months of YAM compensation is dropped in the stream at the beginning, after the first month, 1 month worth of pay will be available to claim. After the second month, 2 months worth are available. And after 3 months, all is available. It should be clear to everyone that this is equivalent to just paying out un-vested YAM every month in the same way stable-coins are paid out.

Lets look at the the pros and cons for streams.
Pros:

  • Contributors can claim from streams whenever they want.
  • there only needs to be one governance transaction per 3 month period.

Cons

  • Contributors with streams are taking on additional price risk since the TWAP is determined at the beginning of the stream.
  • Contributors may be able to claim streams on their own terms, but they still have to pay ETH fees to claim.
  • Although streams remove some overhead from governance (3 month instead of monthly transaction requirements), We already have to do monthly transactions for pay, so this doesn’t gain much in terms of efficiency, and we seem to be constantly opening, changing, and upgrading streams monthly anyway.
  • We have added another layer of complexity to the model that doesn’t actually do anything different.
  • Regulatoryaccountability risk from paying in real time for work that may not have been done.

Given that the current streams model can be seen as equivalent (or worse) to just paying contributors monthly for work done over the past month, I recommend we stop using streams until we determine how to use them to actually fulfill the goals we want (vesting, alignment).

1 Like

I agree, going with simplicity now will allow the team to focus on more critical issues.

Yam can still win if the payroll system is removed. There will always be some people who only receive wages, do not work, and have no hope of development. The developed project cannot be launched for one year, and the employees who are paid must be reviewed

1 Like

I also want to ask Ross what contribution you have made in the past year, with such a high salary, what code or program have you developed that is useful to the community

@taomail You are welcome to browse through the contributor transparency reports to review what I have been working on: Informational Center - Yam Forum. All there under my name in each monthly report.

I can give a longer rundown if you really want it, but this thread is not the place. In the system proposed in my original post, this information would be available monthly, and by contributor as a requirement for them to get paid.