Every 90 days, the developer can choose to have a vote. Voting will range from anything between accepting a new ERC20 token as masternode collateral, to adding new team members.
With security in mind, there are a few limitations set to the voting mechanism. This is due to a lot of mistrust in remote contracts. These limitations have been built in to ensure that you can and do trust us.
Every contract needs majority approval before being exectuable. After each accepted vote proposal, the developers can propose a new voting contract.
Each voting contract will be up for acceptance voting by all masternodes, regardless of their balance or entry time.
The timeframe for having a propsal accepted or denied ranges depending on it’s urgence. The minimum voting time is 2 weeks, and the maximum is 6 weeks.
A majority of 60% is mandatory before any voting contract can become exectuable. This means, if less then 60% of the masternodes holders vote for a contract, it will be rejected and the proposed contract can not be executed.
The minimum masternodes required before voting can take place, is set at 10 users to ensure democracy.
Voting contracts are never allowed to exectute functions
All code execution happens from the published source of the main contract.
All critical functions inside the main contract are protected by being declared as internal, or having modifiers that allow the execution only by a specific contract (that has to be majority approved), and in some cases, can only be executed by the owner.
A voting contract should only contain the logic for voting, and it’s proposal.