Setting the Positive Rebase Sale Rate via Continuous Voting

Setting the Positive Rebase Sale Rate via Continuous Voting

In the discussions about the “mint and sell” rate on positive rebases that are currently in vogue, there has been little discussion of a dynamic rate setting mechanism. There are numerous options and possibilities that can be explored if we consider a dynamic mechanism. Let’s start as simple as possible.

With the right mechanism, Yam Stakers can continually vote for their preference to either raise or lower the rate by depositing Sushiswap ETH/YAM SLP tokens. We could make 2 (or 3) incentivizer contracts to stake in. One contract would vote to increase the tithe/tax/donation rate and the other would vote to decrease it. If you were neutral you could either stake equally in both or we could provide a neutral 3rd pool. The rate (A) could be adjusted every n blocks depending on the ratio of the 2 pools. This would measure market sentiment on the rate in close to real time. The rate of increase or decrease could be calculated with a set percentage x that is added every block, multiplied by the ratio or difference between the pools.


The rate of change (x) could be bracketed to have a max rate at which A can change per block. For example, we could set the max rate at which A can change at .01% per block if the ratio of the pools reaches .25/.75 either way… That would be a 0.50 difference between the 2 pools (pool.diff). This becomes our way to set x:

0.01% max rate = x * 0.50 pool.diff
x = 0.0001/0.50
x= 0.0002

If we did this every block: = A.old + (0.0002 * pool.diff)

Below I am assuming A.old is our current rate of 0.10

Equal YAM in each pool

50+/50- : pool.diff = 0 = 0.10 + (0.0002 * (0)) = 0.10 or 10%

A bit more YAM voting to raise the rate

55+/45- : pool.diff = 0.1 = 0.10 + (0.0002 * (0.1)) = 0.10 + (0.00002) = 0.10002 of 10.0002%

A bit more YAM voting to lower the rate

45+/55- : pool.diff = -0.1 = 0.10 + (0.0002 * (-0.1)) = 0.10 + (-0.00002) = 0.09998 or 9.998%

Max YAM voting to lower the rate

25+/75- : pool.diff = -0.5 = 0.10 + (0.0002 * (-.5)) = 0.10 + (-0.0001) = .0999 or 9.99%

Further thoughts

A lower bound for A could be set by governance or it could be allowed to drop to 0. In this form, anything below 0% would be nonsensical. At the max rate of change described with the parameters above, the rate would drop to zero within 1000 blocks unless people moved their stake to the other pool. This is probably too fast, but these numbers can all be adjusted to meet our needs.

Next Steps

In a forthcoming post I will dive a little deeper into a model that builds on this idea and also uses the difference between the Treasury value and YAM market cap as a scalar. This scalar algorithmically lowers the rate when the treasury value is closer to the market cap and raises it when the treasury value is further from the market cap. Stay tuned.


Rate Setting - Part II
Using the Marketcap and treasury value to help set rates

In my last post, I discussed a mechanism in which token holders can continuously vote to raise or lower the positive rebase sale rate (YAM funding rate). This mechanism measures sentiment and directly applies it to the rate. This is direct and simple, but may not lead to optimal outcomes over the long term if voters choose to vote in their short term interests (a tragedy of the commons).

Instead of continuous voting, we could use a rate curve that would either raise or lower the funding rate by a proportion determined from the treasury value and the YAM total marketcap. This ratio would be a comparison of the Marketcap value and the treasury value (M/tV ratio). The first choice that we would need to make is whether the rate increases as the M/tV ratio increases or whether it decreases. Let’s explore both options

Increasing the Rate as M approaches tV

This option means that when the YAM marketcap and YAM treasury values are close to equal (M/tV=1), the funding rate is at its highest. As the marketcap of YAM outgrows the treasury value, the rate drops. Token holders who want to pay a lower rate need to increase the marketcap to do so. Anyone who wants to add to the treasury will need the marketcap to decrease in relation to the treasury and will be seen by those token holders as lowering the value of their tokens by increasing the tax. This pits these 2 groups against each other. There is an argument that this could serve as a counterbalancing mechanism if we were worried that the project risks takeover by one side. But I would argue this is exactly what we don’t want. It perverts incentives and pits those who believe in the value of the treasury against those who believe in the value of the YAM token. They rely on each other but are always at odds. Growing the treasury increases the tax rate on users who may not be seeing the benefit of that growth directly.

One Equilibrium point here is right near your max funding rate when the price is low. Low rate proponents cannot change it because no one who shares their worldview will buy YAM to unseat the high rate party. An opposite equilibrium occurs when the treasury is kept artificially low so that the tax rate can be as low as possible. Raising the size of the treasury then becomes counter to YAM holders short term interests. This may work if there are significant revenues coming in, but not in our current situation.

I view this as a harmful relationship and exacerbates the problems we already have. So let’s look at the other option.

Decreasing the Rate as M Approaches tV

This option would have a minimum funding rate when the market cap and treasury value are equal (could be 0%). As the market cap rises above the value of the treasury, the funding rate also increases, affecting all token holders based on how much higher the market cap is above the treasury value. This means that when the treasury value is close to the marketcap, token holders are given a reprieve from contributing and the community must use the existing treasury funds to build value. As the marketcap grows, the rate increases. If the marketcap greatly outpaces the treasury size then the treasury will grow more to catch up.

Growing the treasury faster than the marketcap lowers the rate. This is a direct feedback loop that incentivizes YAM holders to add value to the project. Since a larger treasury means lower taxes, there is another feedback loop where extracting funds from the treasury has a clear cost to YAM holders. Once the treasury is earning revenues all holders will have to consider the tradeoffs between taking dividends and lowering the tax rate. If you don’t mind the rate, then you would choose to take more dividends. If you think the rate is too high then your priority should be to grow the treasury.

This will most likely remain as a political issue, but it is one in which both sides want something good for YAM. Namely a bigger market cap or a bigger treasury. In situations like today, where there are no revenues to be shared with YAM holders and the market cap is close to the treasury value, the funding rate would be low. If the marketcap continues to fall, the rate will fall with it. As revenue streams are added to the treasury, the rate will continue to drop if the marketcap doesn’t follow the treasury. At some point, it will be in the best interest of YAM holders to issue themselves a dividend even if it raises the tax rate.

This relationship aligns incentives much more strongly than the first option. As an added bonus, we would gain the ability for our funding rate to go negative if the marketcap value drops below the treasury value. Combined with a pool of ETH dedicated to this purpose, a negative funding rate could determine how much ETH is sold for YAM on negative rebases. This needs more exploration and I will address it in a later post.

Other Thoughts and Next steps

The above mechanism can also be combined with the continuous voting proposal of the previous post. The voting mechanism would no longer directly impact the rate, but could adjust the slope or shape of the curve used to determine the funding rate. Modelling this curve to better understand what the parameters should be is the next element I hope to tackle. For those of you who are good at math and find this compelling, I welcome any help, feedback, and criticism.

My initial reaction is that the continuous voting is a very interesting and cool mechanism, but I’m unsure if it’s value warrants the development resources necessary to implement at this point in time.

I think it adds an interesting coordination element and allows for community members to actively coordinate to determine fundraising on an ongoing basis, which is definitely valuable. I’m imagining a scenario in which the community can actively decide when to scale fundraising up and down based on funding needs.

I’m hesitant to codify a relationship between market cap and fundraising rate described in the second post, as increasing the rate as market cap increases in relation to treasury value could slow market cap growth.