GovBlocks Browser v0.5, released on the Ethereum Kovan & Rinkeby Testnet!

Extremely proud to announce that the GovBlocks browser v0.5 was launched on the Ethereum Kovan & Rinkeby Testnet in March 2018. We’ve now released the wiki docs that provides a step-by-step guide for using the browser. 😁

Here are links to some topics covered in the wiki - getting started, registering a dApp, configuring governance model and use GovBlocks for decision making.

What to expect from v0.5?

GovBlocks v0.5 has three components 1) protocol on solidity 2) js-wrappers of the protocol and 3) a browser/portal dApp for using the protocol. Here’s the architecture diagram (see the blue layer):

GovBlocks v0.5 architecture

The 3rd component of the blue layer i.e. GovBlocks browser was released in March 2018. GovBlocks browser is a web application that uses the Protocol JS (javascript-wrappers) to communicate with the GovBlocks Protocol written as smart contracts on the Ethereum Testnet. We will soon be releasing the Protocol JS and smart contracts as well.

There are two main user-stories in the GovBlocks browser. 1) For dApps, who can configure their governance models and 2) for token holders, who can participate in decision making of existing dApps.

Whenever a new dApp starts using the GovBlocks browser, separate versions of the GovBlocks smart contracts are created with standard configuration. Using the GovBlocks Browser, the dApp community can configure the governance model that suits their community, on a sliding scale of decentralization. The idea is to provide a decision making spectrum that helps in configuring multifactorial consensus at the application layer.

Sliding scale of decentralized governance, configurable via GovBlocks Protocol

Configuration of decision points also requires setting up of the voting mechanism that will be applied in different scenarios. There are decision points that require one layer of voting, while others require multiple levels. Some of the decision points that are common to each dApp are highlighted in the image below.

Common Decision Points in a dApp

An important thing to note is that each of these decision points require different level of human coordination on top of the logic in smart contracts. For example, implementing a business pause in case of emergency situations cannot wait for the entire community to vote on. However, release of a new smart contract code requires different layers of consensus. First the tech team needs to be sure of the capability of the smart contracts, followed by code auditors, and then the business team before it is put out to a community vote.

v0.5 supports simple on-chain voting. We do realize that the current on-chain voting is heavy on gas consumption and hence scalability is an issue. We’re working on new voting mechanisms like proxy voting, commit & challenge and shall make attempts to release them as an update to this version soon. Feedback is most welcome!

In addition to voting, a dApp can configure financial stake locking and incentives for the community to participate in the decision making process. This is further supported by contributor reputation management. More details in the wiki.