Continue POOL distribution. Lower distribution rates on Dai and USDC prize pools. Begin using a portion of each week’s reserves to buy back POOL.
Motivation
Improve overall tokenomics by optimizing POOL distribution rates and initiating a POOL buy back. This also sets the stage to more aggressively build prize pools on Polygon where lower gas costs enable more users.
Overview
The second period of POOL distribution is ending in the next ~10 days. This proposal:
Renews POOL distribution at the same rate for COMP, UNI, POOL, and SUSHI prize pools.
Decreases the distribution rate for USDC and Dai prize pools by 29% each, in aggregate this reduces total daily emissions by 20%. Details here.
Begins using 75% of weekly reserves intake to buy back POOL (~$2,500 - $3,500 daily).
Rationale
POOL Distribution Rates
The majority of POOL distribution is going to the Dai and USDC prize pools. Reducing those two prize pools by 29% each amounts to a reduction in total daily POOL emissions of 20%. The last reduction in distribution rates had a positive effect and the goal is to achieve a similar effect now (maintain deposited value while lowering POOL distributed). This reduction also us to begin using POOL incentives on Polygon where lower transaction fees attract many more users.
Improving Incentives PTIP-25 doubled the rewards for POOL depositors. This proposal builds on the theme of improving incentives for POOL holders by using a portion of the reserves accrued each week to buy back POOL. This POOL can then be sent to be distributed to POOL pool depositors. This will serve as a short term improvement well Llama DAO does more in depth research (PTIP-26) on larger adjustments.
Due to the fact that Llama DAO research is pending a larger changes are anticipated in the near future the initial implementation of the POOL buy back will be manually via a 2 of 3 multi-signature wallet with @TheRealTuna, @RegisIsland, @underthesea as signers. This proposal will fund the wallet with USDC and buy backs will be carried out. This will be a short term solution while larger changes are evaluated.
Technical Specification
The technical specification lays out the technical details of what is being proposed. This may include:
Transfer POOL to UNI, COMP prize pools to maintain POOL distribution at current rate
Transfer pPOOL to the SUSHI prize pool to maintain distribution at the current rate
Decrease USDC daily distribution rate from 1,400 to 1,000 POOL
Decrease Dai daily distribution rate from 700 to 500 POOL
Adjust COMP reserve rate from 100% to 99% (house-keeping change for improved user experience)
Transfer $100,000 USDC to buy-back multi-sig
Status
This proposal has been heavily discussed in two previous threads, thread 1 and thread 2
When did we jump from 50% of the reserve rates allocated to buy back to 75%? I have not seen any discussion about that.
The buy back will be executed by a mult-sig wallet, okay. However, I do think we still need to have a discussion about the parameters. How often will these occur, what is an acceptable price, … Seems like we are very much rushing this part if you want to go for a vote in ~24h.
The points of this proposal, were discussed in many of the previous presentations, I think it is time to implement them and evaluate their evolution. We will always have the opportunity to improve them and continue to grow.
Is this needed? I was told that since the lootbox is providing an award the 100% was fine from PTIP-25.
I’m also with @drcpu where did the 75% come from for buybacks? I’m fine with it, but it seems like the prior post agreed to 50%, not 75%. Was there a discussion elsewhere that caused this change? If so, it should be noted for reference if nothing else. Also what’s the metrics for the buybacks?
My initial thoughts:
Only buy when under $14, or more specifically what ever the price was we offered to the VCs
Initiate buys at different times from one week to the next, the multi-sig keeps those times known to themselves.
Minimal price impacts is a goal, meaning multiple buys could be necessary. I’ll leave the definition of “Minimal” in the hands of the multisig.
The amount bought is either 50% of what reserves brought in the prior week, or preferably, 50% of a rolling-average of the past 4 weeks.
Note sticking with 50% as that was the initial proposal
I’m not too fond of the sudden increase to 75%, but given how it will be implemented with $100k to a multi-sig which will spend it on buy backs, it doesn’t really matter. The percentage will just result in the $100k being spent 50% faster.
I agree with the parameters layed out by @Taliskye.
Buying below $14 seems reasonable as that was the approximate VC price and the argument has been made several times that everything below that should be seen as a good deal.
The amount that can be bought being a percentage of last weeks reserves seems reasonable too.
I don’t think the order size will matter that much since CoinGecko puts the 2% depth at $50k, so with the current reserve growth rate, I doubt the buy backs will have a noticeable impact on the price. If they would after all, I agree with Taliskye that this should be avoided by initiating multiple buys spread over the current week’s time frame.
Plus @Taliskye@drcpu you had similar questions so answering them here.
The change from 50% to 75% was my mistake. When I wrote that up last night I was just confusing numbers, so let’s stick to 50% as discussed earlier.
Exact timing of the buys is at the discretion of the multi-sig, however, the should be executed at minimum once per week. It’s pretty easy for us to track reserve growth on-chain and also track the buys happening via the multi-sig so accountability on this is not hard
My opinion is that this is less about targeting any specific prices and more about improving overall tokenomics. So even if the price goes up, I don’t think that changes much. The protocol is well capatilized right now thanks to our treasury diversification and even with the buy back we’ll still be adding at $2,000 -$3,000 to reserves every day. Given this is only 100k this is going to be pretty short term (should be exhausted in 6-8 weeks max).
I am glad others have brought up the specifics of the buyback because I think it’s easier to operate with less subjectivity. I am in the camp of having a price limit on the buybacks of the VC purchase price.
For a buyback price limit: torgin, drcpu, taliskye, and myself
Against: leighton, TheRealTuna , RegisIsland
As a signer on the multi-sig I am happy to execute however the community specifies.
The buyback particulars do not seem to be a show-stopper for anyone as there are as of yet zero votes against this proposal. I am excited to for the emissions reductions and also for the potential growth of new pools. I think new pools and Polygon are an under-tapped marketing oasis. And V4, we all know that’s going to make waves.
If we limit ourselves to a price the. We may never buy any tokens back. A buy back should buy at any price. Dollar cost average. Buy back no matter the price. That’s the whole point. Reward POOL holders.
Just wondering if we could look at taking something simple from tokensets, like buy below the 20 day SMA and keep loading the contract up with funds as they get exhausted. In general i think tieing in some simple trading to the buy back strategy is a good idea.
Not aiming this at any of the signers, but just stating a problem with the current set up. One or more of the signers could game this by buying before the bulk buy comes in each week and sell after the event to make a profit. I think ultimately the best way to structure buy backs are to hold off buying with reserves until market pressure events are occurring.
The key difference to me is that I’m thinking of this as a step towards implementing an xSUSHI type functionality (similar to what was proposed in the POOL Bar discussion: PTIP-23: Add The Poolside Bar - #15 by Leodisc19
Following this model, it really doesn’t matter what the price is (you wouldn’t want xSUSHI to simply stop yielding if SUSHI went over a certain price). This is more about adjusting how reserves are used rather than trying to time a strategic market buy back.
I think it’s gotten a bit confused because we have also had a discussion on that point (raising debt or using a large one-time allocation from our existing capital). I think if this was the case, price absolutely matters a lot. But if we view this as a step towards a longer term goal of improving incentives for POOL holders and it’s only an adjustment to usage of NEW incoming reserves… I don’t think price matters.
I am mainly thinking about this in terms of minimising potential for gamification of the buyback, but it is still in the interest of whoever is staking in the POOL bar that the buyback is smart about how it buys back. This will increase the yield for stakers in the POOL bar. If the buyback has to happen quite frequently you can still use an algorithm on a smaller timeframe like I proposed.
We want to optimise the efficiency of the buyback. You can either have a select group of people know when it will happen or everyone know when it will happen. In both cases it can be exploited to the loss of the POOL bar stakers. That is why I believe the best way to minimise the potential for exploitation is having an open algorithm that only buys when price is depressed. If pool is buying at random prices there is potential that someone can figure out how to manipulate the price higher so that is where we buy and then dump on the market after the buyback happens. We should optimise against this, even using a simple defence as it is the most dangerous type of exploit we will face.
Personally, not a fan of having few people deciding when to do a buyback. In my opinion, it should be a smart contract, especially because this is not the last time we are doing this (I assume), therefore we should have a completely transparent procedure for this.
// Assuming we want 1 buyback per day on average…
// if (last_execution > (now - 3600)) return // allow max 1 execution of the method per hour
// Get a random number from Chainlink % 24
// Check if it’s 7, if it is, execute swap from USDC to POOL
// last_execution = now
It could as well have parameters, maybe check if the token is under some price or whatever. And the contract could be funded (and parameters changed) by PTIPs.
Not a Solidity dev so maybe this has errors and false assumptions, in addition, I don’t know how much it’d cost to run such transaction each hour.
what you are proposing will take time to develop. This has trade-offs of course, but as @Leighton pointed out, this is a temporary strategy. We can work on developing a longer term strategy while we execute this simple mechanism so we can get started buying back now. Once we get the report from Llama Dao we can create a long term strategy. as a POOL holder myself I’d like to see a buyback initiated as soon as possible. We will not be buying enough to move the market, so I am not really concerned with someone front running a 3500 dollar buy.
Gotcha, yes, this makes more sense and is prudent. So I think we need to balance this against the broader context that this is designed to be the easiest to implement option while we research and design a more sophisticated system.
With that in mind, it seems like giving the multi-sig the high level guidance of
Flexibility to execute the purchase whenever they believe is most prudent within a 7 day time frame
A requirement to execute the purchase at least once every 7 days
The second requirement will make sure the buys do not get too large (and therefore not move the market too much), the first requirement helps improve execution.
We’ll also have the on-chain data from this so we can evaluate improvements after the first ~8 weeks.
This will be critical! Better to institute this modest buyback now and tune it later with some real data.
Eager to vote on this today! Seems like there is unanimous support for the idea, just some details need to be worked out which can be adjusted in the future. Think we have a good baseline and starting point though.
Vote 
Vote