Q1-Accelerated Development Work

#1

Given the ambitious agenda set out in our 2018 roadmap, we want to be able to attract and reward solid blockchain engineers and other developers for immediate roadmap projects. This work will focus specifically on the roadmap items for Q1, including the launch of the marketplace and the Phore Android wallet, as well as upgrades and maintenance work on the core blockchain protocol code.

This 5,760 Phore will help us achieve our upcoming development milestones, and the funds will be directed by the core Phore team.

#2

I like both proposals and voted for them, but I’m asking myself if it’s possible to fund both.
We have 43201 blocks between the superblocks. So a total budget of 30240.7 phore.
Your and toby’s proposal add to 33260 phore.
I don’t know what happens to the blockchain in this case, but I’m eager to find out :slight_smile:

#3

Looks like we need to check out the maths
The one with the most votes goes through.

#4

I appreciate that you are so detail oriented about this, Crypt0k3vin. You’re my kind of guy.

I was not on the Phore team when the coin was launched, but I recently dove into the budget code to understand how it worked. I won’t go on for pages of detail, but the bottom line is for this period of funding up until block 250,000 which is in March I believe, the calculation of the total budget is based on a subsidy of 7.7 PHR per block, not 7 PHR. It is a 30 day cycle, the math formula more precisely is:

((block reward / 100) * 10) * 1440 (seconds per day) * 30 (days per cycle)

((7.7 / 100) * 10) * 1440 * 30 = 33,264

You can verify yourself on the GitHub that this code has not changed since these brackets were changed from the forked PIVX code (which had much higher block reward brackets). The readme.md file needs to be updated to match the code as that did state that the budget was 0.7 PHR per block.

I will add that the helpful mnbudget projection command should help us out here. It should simulate what would be in the budget if it were finalized at that moment. The algorithm for choosing proposals first filters out any that have less than 10% of masternode votes, after subtracting any no votes from the yes votes (so we need a net 45 or so yes votes right now, I’d shoot for higher to be safe). Then it ranks them by ratio of (yes / (yes + no)) votes, and pays them out in that order until it runs out of funds or skips ones that are too big and pays out smaller ones that fit lower on the list until it reaches the end.

So if I’m wrong and the two proposals will not fit, once we have enough yes votes and the proposals have been around a full day, mnbudget projection should only show the one with the best vote ratio and the other one would be filtered out for being too big.

If there is a problem we can ask people to vote no to this proposal and put in a smaller one. I would also want to make sure the main proposal has a better ratio than this one, if it came to that, and we could ask a few people to change some of their votes to no or abstain on this one if that was needed.

#5

Very nice explanation, thank you!
In February I’ll have time to overhaul the governance page that I’ve put on github, which will include a little pdf about the technicalities of the governance system.
Any chance you remember which .cpp file contains the governance functions?

#6

Almost all of it is in masternode-budgets.cpp. I can help document it at some point given that I’ve spent many, many hours figuring it out and testing it.

#7

awesome, many thanks!
I’ll send you the link for github and overleaf once I start working on it, this way you can contribute when you feel like it.

#8

how will you make the progressive web application for the Android platform and how can we scan it for our safety from the online resource developed by kaspersky antivirus error 1922