Once a company is registered, the dashboard shows 4 options to configure the governance model. We have listed each option below
GovBlocks provides two member roles by default: Advisory Board, Token Holder. However, a dApp can configure new roles based on their requirements and use these roles as voting layers.
For example, an insurance application might require additional member roles like claim assessors, underwriters, cover holders etc. while a professional networking application might require roles like company owners, employees, validators etc.
New member roles can be created at any time in the dApp's life time.
To create a new role click on "Add Role" button. It opens up a popup shown below. Key parameters to be noted here are:
Limited Validity : If membership to a role has limited validity, eg: if admission as a board member happens for 5 years at a time, mark this parameter as Yes.
Allow authorization to external address: If set to No, admission/removal of a member to this role shall be via a governance proposal. However, if authorization to admission/removal of a member needs to given to a smart contract/special address mark this as Yes and enter the address. This is especially useful, if role allocation is a periodic action triggered by a dApp smart contract, ex: a role "validated member" is allocated to an address post KYC.
Clicking on the role name, gives a list of members in that role. You can add/remove members from a role if the member role is configured as a default address authorization.
The protocol identifies a member’s contribution in 3 ways:
Creation of a proposal
Submission of a solution to a proposal
Casting a vote for/against a proposal/solution
The value of a contribution is a function of 2 parameters:
Number of tokens that a member has locked for governance
Stakeholder's reputation in that dApp
These parameters are completely configurable and add a lot of flexibility to the dApp governance model. They can be changed by heading to the 'Configuration' tab in the left sidebar of the dashboard.
Quorum Percentage - The minimum % of members required to vote on a proposal. A proposal is denied if quorum % is not reached.
Reputation Weight - The weight given to reputation when calculating vote value.
Stake Weight - The weight given to locked tokens when calculating vote value.
You may change one or both of these factors to get the perfect balance for your dApp
Bonus Stake - This is the default amount of stake added to vote value calculation. This can be useful to reduce the relative vote value of high stake members.
Bonus Reputation - This is the default amount of reputation to vote value calculation. This can be useful to reduce the relative vote value of high reputation members.
Proposol Owner Reputation – Reputation awarded to the owner of the proposal
Solution Owner Reputation – Reputation awarded to the owner of the solution
Categories are the backbone of the protocol. Each proposal is categorized before it is opened for voting. The category decides the following:
The voting layers through which the proposal shall go through. You can configure as many layers as you want
The majority % and voting time period required at each layer. E.g. a greater majority % and lower voting time could be set for a layer with limited members like the advisory board.
Member Roles that are allowed to interact with proposals of this category.
Every proposal is given a sub category before it is opened for voting. every sub category belongs to a category and adds configurable parameters on top of those provided by the category. The sub category decides the following:
The Contract on which the automated action will be executed. If you wish to use your dApp contract address here, please follow instructions at Start using GovernChecker
Minimum stake: The minimum amount of locked tokens required to vote in this category.
Default incentives to be distributed on acceptance of a proposal for a category. Ex. setting default incentive as 100 for flagging a bad act in the ecosystem. The unit for incentives in the dApp token for categories in which only internal participation is allowed. If a category is open to all, it uses GBT for incentives.
Categories that always result in a known action like ‘transfer of funds’ etc can be configured for automatic action to be triggered once the proposal is accepted.
The GovBlocks network is a collection of applications that use the GovBlocks protocol internally. The network allows dApps to communicate with each other seamlessly. You can set contract address and function to call in the sub category to automate an external action. You can also set offchain API that you may want to be called once he proposal is accepted. These triggers are defined in sub categories.