Proposal “dashcentral-operations1“ (Active)Back

Title:DashCentral operations
Monthly amount: 30 DASH (882 USD)
Completed payments: no payments occurred yet (6 month remaining)
Payment start/end: 2024-02-09 / 2024-08-06 (added on 2024-01-25)
Votes: 416 Yes / 7 No / 7 Abstain
Will be funded: Yes
Manually vote on this proposal (DashCore - Tools - Debugconsole):
gobject vote-many 705ed128b969f977eb832218c6d1eafb74c2522289aea43dcb04b806b2a42a67 funding yes

Please login or create a new DashCentral account for comfortable one button voting!

Proposal description

DashCentral stands as the primary governance platform for DASH, a role it has fulfilled since 2014. Over the years, I've consistently implemented changes to the website, ensuring its compatibility with the ever-evolving DashCore software.

The operational costs of DashCentral have been borne by me for the past decade, supplemented by the donations from the community (typically ranging from 1-2 DASH per month).

I am now seeking funding support amounting to 30 DASH per month to sustain the ongoing operations of DashCentral. This funding will cover hosting, sysops, and a monthly allocation of 0.5 working days for developer/sysop activities. This financial backing is required to maintain the website's uptime and ensure it's functionality remains synchronized with DashCore's continuous changes.

Show full description ...

Discussion: Should we fund this proposal?

Submit comment
3 points,20 days ago
Yes. You deserve it for the past 10 years.
Thx for all your work rango with supporting Dash Dao since the beginning!
3 points,21 days ago
Yes from me.
3 points,26 days ago
Are you going to fix the broken or at least unreliable voting threshold calculation?
According to it currently sits at 342
Also, some proposals occasionally show negative votes required to pass, like 'still needs -15 votes to pass'
2 points,21 days ago
DashCentral seems to calculate voting threshold at 296 votes, which is a staggering 13.2% too low.
Hopefully you are going to finally repair this, after your proposal is approved.
2 points,21 days ago
DC uses 10% of the weighted masternodes count (weighted by performance masternodes) to calculate the voting threshold. This value is currently 2956 and is equal to the value of 2956 shown here (

So i don't know how the voting threshold of 341 displayed on is calculated and whether it is right or wrong.

Any further insights would be helpful.
2 points,20 days ago
No Sir, you are wrong.
If you take a closer look, you can clearly see stated on:
3794/2956 1k MNs (Total/Enabled)
124/114 4k MNs (Total/Enabled)
Therefore the correct formula would be: (2956+(114*4))*0.10

Furthermore, you can easily check payment queue roundturn length on a Block Explorer, for a MN Reward which is configured as payout for a single node, like for example this payout address here:
The difference in block heights shows the length of the payment queue roundturn, of course it will only be correct if the node was not affected by a PoSE-ban between two payment blocks.
This would be an appropriate and accurate way to measure the correct 10% threshold, because it effectively takes into account misconfigured, old-versioned and PoSE-banned nodes.

Obviously such a method will no longer work after the Evo Pool will take effect and 4K MNs will only receive a single Reward payment on the Core chain.
After Evo Pool takes effect, it would be necessary to measure the length of payment queue roundturn *collateral*, divided by 1000 or 10000 respectively.

Please also try to troubleshoot the 'negative votes required' nonsense, which occasionally shows up.
3 points,20 days ago
The formula was correct, however they seem to have changed the Evo node label from "HighPerformance" to "Evo" during the most recent updates. That led to the last part of the formula being 0. The issue has been resolved.

I have implemented a fix that could also resolve the sporadic "negative votes required" issue. In case it still shows up, please let me know.

Thanks for your support. Is mnowatch managed by you?
2 points,20 days ago
Thanks for taking the time to investigate and fixing it so quickly.
Not sure, but i believe MNOwatch is run by xkcd & demo, i love those guys.
Last but not least i wanted to remind, that if a rounding function is used in the calculation, then unless its a full integer number, it should always round UP (!) but never round down, even in such an example:
341.2 rounded = 342 (instead of 341 resulting from default rounding)
To make sure a strict minimum of 10% is always respected, that should make sense.
2 points,20 days ago
What´s weird is, i just noticed there seems to be quite a huge discrepancy between the post-fix DC calculation (345 net votes)
and the figure posted by MNOwatch here: (340 net votes)

I guess only demo can help to solve this mystery, where is he?
3 points,19 days ago
Found and fixed another issue. The voting threshold is now correct (341).

Vote counts (YesCount,NoCount) are taken from "gobject list all proposals". I would assume that these numbers include votes of POSE_BANNED masternodes.
3 points,16 days ago
You may be interested to know that the `getgovernanceinfo` RPC was updated in v20 to make this easier on us all. It now includes the threshold required to pass.


"governanceminquorum": 10,
"proposalfee": 1.00000000,
"superblockcycle": 16616,
"superblockmaturitywindow": 1662,
"lastsuperblock": 2010536,
"nextsuperblock": 2027152,
"fundingthreshold": 341,
"governancebudget": 8528.33663416
2 points,19 days ago
WOW, that was really quick.
Rango, you are a genius, i tip my hat to you!
Thank you so much for repairing our DAO voting.
I´m gonna support your proposal.

Perhaps someday there will be an opportunity to discuss my objection regarding the above-mentioned default rounding with the CTO and also with demo, so that based upon their inputs and opinions, the always roundUp() function could be implemented across all services (DashCore, MNOwatch, DC, etc.) using the same identical logic.

Imagine an extremely important governance proposal with a super-tight voting result outcome,
where it could ironically make all the difference.
It would cause a lot of subsequent infighting, if half the community maintains it was barely approved, while the other half of the community knows for a fact it was short a single vote due to the down-rounding of the default rounding.
1 point,20 days ago
First of all, all calculations are wrong.

Here is why:

If you want to be compatible with dashcore, you should take into account the POSE_BANNED votes, while calculating the threshold by using the 10% formula.

793/2954 1k MNs (Total/Enabled)
124/114 4k MNs (Total/Enabled)

So the current threshold for every proposal is (4*114+2954)*0.1= 341

1 point,20 days ago
With regards to PoSe banned masternodes still being able to vote :

It looks like this git pull is getting hampered, by not working nicely with services like MNOwatch. Which is likely the reason why it has not been merged for now.
1 point,20 days ago
To be fair, a number of solutions have been proposed in that pull request, with each a downside.
1 point,20 days ago
Also note that for correct calculations, you should pair a leaderborad report with the appropriate stats, based on the correct report date.

For example this leaderboard

pairs with this stat
1 point,20 days ago
This happened in dashd V20

The change from HighPerforance to Evo is visible in these sequent reports:
4 points,26 days ago
I will obvioulsy vote yes for this.
3 points,26 days ago
Of course, after voting yes for the first month, I expect some improvements here in dashcentral in order for my yes to be kept for the next months too.
3 points,26 days ago
Yes, we support everyone else, I think we should support you.
1 point,26 days ago
No, the stupid masternodes do not support everyone.

For example, they do not support the Encointer Proposal, which is about to give an anonymous proof of individuality for every Dash member and thus make the Dash community members accountable for their stupid decisions.