Closed ThanatosOsomiak closed 3 years ago
I believe that the current system is fully adequate.
Great idea!
great idea, that would help to get more non-cake MNs...
I think with the latest discussion on lowering the collateral needed for MNs, this would be the perfect approach to bring in more MN owners with lower collateral requirements and help decentralise the project and distribute the MNs international and provide more independence from Cake! This would clearly provide a boost!
Closing this in the mean time to prepare for the next round of DFIP. Please re-open if it should be part of the next DFIP.
@ThanatosOsomiak I think it would make sense to reopen/ajust that again accordingly. And to impelent the freezing option. Or at least think about it. 🚀
Spontaneous idea: What about not demanding a higher collateral like described in #26 but using the target multiplier instead.
Example: When a collectively staked masternode runs on 20,000 DFI, the TM keeps raising by 1 every 6 hours. If the collateral drops down to, let's say, 15,000 DFI because someone rejected his/her collateral, the TM will be raised not after 6 hours but 7.5 instead. This will lead to a proportionally lowered minting activity. Additionally, the chain should be able to add up these missing 5,000 DFI as soon as someone wants to add a similar amount. This can be propagated through a kind of explorer which lists masternodes waiting for funding.
This will make #26 obsolete.
Collective Staking
Overview
At the moment one DeFiChain masternode is worth approx. $ 70,000. For lots of people, willing to stake, it’s not possible to gather such a huge amount. Therefore they use centralized third party organizations to gain rewards from their DFI. This leads to a huge centralization of the DeFiChain network. At the moment approx. 99% of all masternodes are under control of such centralized third parties. Due to this, not only the chain is centralized, also the individual DFI owner doesn't hold the keys.
Proposal
tl;dr: Masternodes based on locked DFI in a smart contract from different wallets. To enable parties holding way less than 20000 DFI to participate in the decentralization.
To prevent the network from spamming with reward transactions a masternode can be co-funded by a maximum number of wallets. 5 seem to be appropriate.
Funding
The masternode funding can take place privately (under known parties) or publicly (anonymously). During the masternode creation process the owner defines a public or private funding.
PRIVATE
PUBLIC
Each participant must contribute at least 50% of the remaining minimal locked DFI to gain the masternode status, except the last participant must spend the remaining amount of DFI.
This gives everybody the chance to lock large and small amounts of DFI.
Examples
Operational Costs
The masternode owner can define a specific percentage to collect from the co-funders to maintain and run the masternode. These costs can be set between 0 and 5%.
Unlocking Funds
Unlocking the funds by one of the funders leads to the decommissioning of the masternode. To guarantee network stability view DFIP12 (#26) . After Unlocking DFI it takes 14 days to decommission the masternode and unlock the funds. So the masternode owner has enough time to find a new co-funder and the Co-Founders do not unsakte due to any panic reaction. This process could be improved by buying out the old funder with the new one. A suitable graphical user interface provided by the Defi Wallet app or any third party will help a lot with that, too.
Voting
Voting will be possible through the smart contract. The masternodes voice will vote in the same way as the majority of the co-funder votes. Each co-funder has the voting power in relation to his share of the masternode funding. Co-funder not voting do count as not relevant and will increase the voting power of the existing votes.
This will also increase the network decentralization, due to the fact that more masternodes will provide their votes.
In most cases the Masternode owner will own >50% so he has the power to vote. Only if he owns 50% and/or he is not taking part in the voting the masternodes voting relies on the co-founders.
Interim solution:
As long as there is no change in the voting system and the voting takes place by signed GitHub comments, the MN Owner has the power to vote.