DAI proposal: Buy back HOPR token and burn

Hi all,

Here my 1st proposal. I suggest using the 168,763 DAI generated from LP pool to buy back HOPR from the market / Uniswap and subsequently burn the bought tokens so that they are gone from circulating supply.

Buy back should not be done at once with the whole amount, but distributed in time so that HOPR is bought back at local bottoms. It’s not about pump and dump.

4 Likes

an interesting idea, I think it would increase the price of the token

If 160K DAI will be able to change the price, then it can be good.
But I am afraid it’s not too much for current trading volumes…

1 Like

burning 500k tokens will not give any global effect for the price with a full capitalization of 1 billion. This is only 0.05% and will cause confusion in the figures of the calculation of shares and distribution. I think this is a bad suggestion

2 Likes

Thanks for this proposal @Wojt

To answer the concerns here on the actual price impact: The HOPR-DAI Uniswap pool alone is currently holding around $18m in liquidity and therefore such a buyback would not significantly move the price. You can check the Uniswap UI to see how much: The maximal allocation of 168,763 DAI * 40% = 67,505.2 DAI currently seems to have a price impact of 0.5%.

2 Likes

Well then let’s reduce liquidity for the time of buy back :joy:

It would be interesting to implement it on the downtrend. But while there is no serious destruction, it is necessary that they are not idle.

1 Like

I get your point, but as Sebastian outlined, the impact won’t be that big.

Thanks for proposal @Wojt
Good idea to decrease supply. It seems it wont have significant impact, but it would.

Hi @Wojt and thanks for the proposal!

I’ve currently marked it as invalid, because it doesn’t currently address the criteria listed here: http://forum.hoprnet.org/t/updated-proposals-making-proposals-validity-rules-and-template

As commenters have noted, it’s not clear from your proposal how this would help to grow HOPR in the medium and long term.

The implementation details are also unclear (this doesn’t need to be precise, but “distributed in time” feels too vague).

If you like, feel free to update and ping me or @jayveq and we can reassess.