I have another idea on how to ensure financial stability for witnesses. Every witness from top 20 will receive 25% upvote per day from blurtbooster. Witnesses can publish normal posts or automatic posts like @khrom does. The size of the upvote can be easily changed based on the market price of BLURT. In this way, we can burn a full 10% of BLURT printed for DAO, so my action of burning BLURT should affect BLURT price in a positive way.
RE: Initial Community Roadmap for the Blurt Blockchain
You are viewing a single comment's thread from:
Initial Community Roadmap for the Blurt Blockchain
I tried to reply you twice while testing the Blurt mobile app but received some errors, will just give you screenshots of what I was going to reply.
I agree with this solution. Under one condition: 10% that is allocated for DAO will be completely blocked (maybe as you wrote some time ago - by return proposal). A calculation would be needed: how much will this 5% give to witnesses and what will be the increase in their earnings.
These days many people think it's best to hold btc and do nothing. It will be hard to find people who want to invest in small blockchains like Blurt, so we need to limit inflation and wait for better times. Personally, I think that after the series of hardforks you have planned, Blurt has a chance to become more attractive to investors, which is why I still buy some BLURT, but not that much as before
I agree with you too, we should be keeping inflation under control. Yes once DAO is fixed Blurt Core is happy to put a backup burn proposal alongside yours and ensure all DAO rewards are burned.
I think I have an idea how much witnesses will get, so they currently get 10% of inflation, adding another 5% would increase earnings by 50%, so if top 20 witnesses earn say 14k BP per month, they will be upgraded to 21k BP pm, which sadly is still only 63 bucks at current price.
I agree bitcoin and Eth will be the biggest winners this bull market, however since BLURT is mostly priced in btc it should also go up a bit.
Blurt can be the gateway to btc for new users because it is way easier and has better feedback loop and group learning opportunity than btc which you can’t really do much with other than trade.
I must thank you, I am enjoying this cordial discourse and idea refinement. I am very pleased we are of the same mind on the future of Blurt.
@megadrive, @ctime
Since Blurt's inflation rate was reset when he was created, we find ourselves with a rate that is far too high, but also much higher than Steem and Hive.
Currently, inflation declines at a rate of 0.01% every 250,000 blocks until it reaches 0.95% in approximately 20.5 years.
I'd be in favor of variable inflation, depending on the activity on the blockchain and framed by a floor and a ceiling to keep control of it, this would enable Blurt to remain attractive in periods of high activity and limit the negative effects in periods of low activity. A floor of 3% and a ceiling of 6% seem to me to be a good idea.
As explained in my last post, we produce 3,456,000 BLURT/month, 10% of which goes to the DAO, i.e. 345,600 BLURT/month, and the same for the witnesses, since they also account for 10% of the BLURT created. So taking 5% of the DAO and giving it to the witnesses amounts to increasing them by 50%. If the distribution between witnesses is not reviewed, then a witness in the top 20 who currently earns 15,000 BLURT/month would earn 22,500 BLURT/month.
Finally, I'd like to remind you that I'm in favor of a return proposal, which has a positive image and the same results, rather than burning. What's more, it keeps opportunities open.
Interesting concept, however, I would leave it for the future. At the moment, let's do what we agreed to, hopefully these changes will be approved by witnesses
Switching to a variable rate based on blockchain activity requires development and probably further analysis to define the right floor and ceiling to put in place as well as the periodicity of rate adjustment and its proportion, so if the idea were to be approved I don't think it could be integrated before at least HF11 or even 12 (depending on the final schedule), so as not to delay the implementation of HF09 and 10.