Rationalizing Contributor Streams

This is an idea to simplify and rationalize the way that we pay and organize contributor streams. The above diagram shows a cadence and process for opening and closing YAM streams for existing, new, and departing contributors.

This process follows the changes made with YIP-84 to move to 6 month vested streams with a pay structure of up to 70% of streams paid in Stablecoins and the rest in YAM. 30% of a contributor’s pay must be in Vested (6-month locked) YAM.


  • Existing contributor are all renewed together at the same time, in 6 month intervals. At this renewal, TWAP prices are determined and the amount of YAM to be deposited in each stream is set.
  • If a new contributor is hired, they have a trial period that is to last at least one month (3 months max) where they are paid from the expenses multi-sig. During this period they are paid at the TWAP rate at the time of their payment.
  • After a trial period ends, they must be approved by governance in the normal way and a stream opened for them, prorated to end with the rest of the contributors. They then continue with the normal cadence.
  • If a contributor leaves, their stream should be stopped at that time. Ideally this should happen in a way that does not require an on-chain vote to prevent someone from quitting at the beginning of the month and still being paid for that month.

Open Issues/Questions

  • How should our vesting model work?
    • The simplest solution in my mint is to add a timelock on claims for streams. So a 6 month vested stream would accrue YAM linearly like it does now, but that YAM could not be claimed until after a certain timestamp. Ideally, this timelock should remain active even if the stream is closed, but this would require changes to the current stream system since closing streams sends the earned YAM to the recipient.
    • Another question that should be asked is whether this is simply a delayed payment mechanism, or whether this vesting requires that a contributor work the full 6 months in order to earn the YAM. This would change how the vesting would work.
  • Can we re-use the YAM stream model for USD payments?
    • If the rate at which funds are streamed is variable then this should work. Instead of streaming block by block, the stream could unlock in monthly increments.
    • This would require setting aside USD funds for the next 6 months of payment as they are locked in the stream. I don’t see this as a bad thing and we should always be sure we have at least 6 months of runway to pay contributors. At current pay rates and contributors this would be ~$300K - $400K deposited in the streams. If this is too much then this could be changed to quarterly deposits instead of 6 months.
  • How does the process for stopping streams work in practice?
    • We should have a way to close streams of contributors who leave or are fired. Requiring an on-chain vote to stop streams can delay this by up to a month, leading to the DAO paying contributors who are not working.
    • The HR Group could be empowered to close streams with a multi-sig (3-of-4 or 4-of-4) after a snapshot vote alerting the community that a contributor has stopped contributing.
    • This would require this multi-sig to have privileged access to the stream contract, but only with the ability to close the streams. On-chain governance would still have full control if needed.

Appreciate the visual and writeup. There are certainly many details to work out still. My overall input is to error on the side of simplicity while maintaining fairness. One bullet point that i don’t think would be fair is requiring a full 6 months of contribution in order to receive vesting. This could in fact be a disincentive. Finally, the TWAP working are unclear to me, as well as the payment process (streamed vs airdropped).

Thanks for the input. Those are good points, and I should add that there are really 2 parts to the above post:

  • the overall structure and flow of how contributor compensation is handled. Specifically getting everyone on the same schedule and flow, which is not really the case now and is quite confusing. Moving to a consistent cadence where everyone gets updated at the same time and in the same way is my way to simplify.
  • the questions around vesting (not yet implemented) and updating our process to be less reliant on monthly on-chain votes to pay contributors. These are the secondary question of the post and should be answered after the first point.

I agree with you that vesting shouldn’t require completing the full 6 month period to earn the YAM portion of payment, but it is something that we need to make sure we are clear on because it may impact how the smart contracts work that implement all of this.

I’m not sure exactly what you are asking here so I will be general. The TWAP is just a way to get an average price of an asset over a certain period of time. We use a 1 month average currently. When a stream is opened, the YAM is added at the beginning. Because pay is dollar denominated, the TWAP price is queried and that price is used to determine how much YAM is put into the stream.

So if you are earning $1000 a month in YAM, with a 6 month stream, then when the stream is opened, it needs to be loaded with $6000 worth of YAM. This amount is found by multiplying $6000 x TWAP price. This YAM will then be loaded and streamed to you and can be claimed as it comes available (how it currently works)

We don’t currently do USDC payments like this and instead airdrop them. I’m sure there are reasons, but @flygoing.eth recently proposed changing USDC payments to streams as well to make things easier on the devs and governance. The simplest version of this would be to create 6 month streams of USDC and allow them to accrue and be claimed continuously by contributors. The issue here is that if someone stops working, we need a way to stop payment. Right now contributors are paid USDC after performing work so we can manually adjust if someone stopped working mid month. With a stream that money keeps coming unless someone stops it. And since we typically only have on-chain governance votes at the beginning of the month, someone could quit right after a governance vote and earn all the money for the next month without working.