I hope I got your attention with the title. The content is a bit more nuanced but the big question remains the same:
The DAO is almost out of YAM tokens to spend. How should we proceed?
Determining how much YAM is needed to fund future work and initiatives is a difficult question to answer. It relies on assumptions around market conditions that may prove inaccurate over the long term. We can see an example of this in the previous token issuance plan that YAM deployed. The 2M YAM tokens that were minted were expected to last 3 years, but have only lasted about half that time.
The current payment model that the DAO uses pays contributors in YAM, but denominated in dollars. We do this to maintain a consistent pay rate for contributors. This means that if the price of YAM goes up then we pay less YAM, and if the price of YAM goes down we pay more YAM. This mechanism makes it very hard to estimate how much YAM we expect to pay out over any given period of time as the forward market price is inherently unknowable.
We could once again take a stab at estimating the amount that we need to mint and hope for the best. But even “realistic assessments” of the expected amount often leads to overly optimistic estimates of the token price and subsequent underfunding. Is there a better way?
I believe there is. We should consider issuance to pay contributors separately from issuance for incentives and individual programs like Protocol Owned Liquidity. Issuance for contributor compensation should be deterministic and based on the amount paid out in grants.
Contributor compensation (grants) is continuous expense. If a portion of that compensation is paid in YAM, the DAO needs a way to fairly determine how much. The easiest way is to denominate the YAM compensation in dollars, or another reference asset, which leads to variability in the amount of YAM dispersed over time. No matter the amount we estimate is needed to mint for this purpose, we will be wrong. The only question is by how much.
Because of this, I argue that there is no benefit to trying to guess. If we are committed to paying some amount of compensation in YAM, then that is what is important, not the amount minted. We can instead set a rate at which we pay YAM as part of funding grants (e.g. 30% in YAM) and create a contract function that mints YAM when we fund projects from the treasury. The key point here is that this doesn’t change the amount of YAM in circulation any more than minting all at once, but now we don’t have to worry about guessing correctly or running out of YAM.
If YAM token holders don’t want to continue paying in YAM or want to change the ratio then they can change the parameter in the contract via governance. They still always control the future flow of YAM minting.
- should we pay contributors partially with YAM? thread about that located here
- If so, how do we go about getting the YAM?
This is an optional, continuous expense. It can be denominated in YAM since voting is denominated in YAM. We can easily budget for this into the future. If we value token holder voting or delegating YAM tokens then these new tokens promote that and dilute those who don’t participate. The key here is making it easy to participate via delegation. This quantity could be set as a function of total supply, a function of total tokens used in voting, or another metric that stakeholders come up with.
- Should we compensate voters to vote?
- If so, how and with what assets?
- Should we incentivize voting or simply delegation?
This is another optional expense and can be denominated either in USD or YAM. With the silo/grant system, this YAM may not be needed if we allow projects to issue their own tokens. Personally, I have mixed feelings about product incentives. They are often very useful but also skew markets and can make it hard to tell if a product is successful or just over-incentivized. They become very easy to depend on.
Minting tokens in advance to use for incentives makes it hard to plan for their deployment into the future and will skew decision making toward the availability of the incentives instead of the need for the incentives. Ideally, incentives for different products and projects should be considered based on their own particular needs and context. If a project needs incentives to work then that incentives program should be designed around making it as successful as possible and not based on a pre-determined amount that may not have considered those needs when implemented.
- How should we think about product incentives?
These are one time projects like protocol owned liquidity and they should have clear metrics for how many tokens need to be minted. These projects should be denominated in whatever unit is most useful.
- What are these projects? Anything other than protocol owned liquidity.
I am curious to hear everyone’s thoughts on these ideas. I have recently come to the conclusion that a flexible system of determining issuance is a superior strategy than the typical “guess and hope we got it right” model that many crypto projects use. I have started writing a more detailed collection of my thoughts on why but it isn’t quite ready yet. I’m hoping some discussion here will help me clarify those arguments.