How we can implement Governance in a chain?

Question

I need to implement governance on my chain. Do we have any references which guide me in development?

Answer 1

Although your question is rather general and wouldn't usually make for a good StackExchange question, I see merit in providing a general answer that could serve as a broad entry point for others interested in implementing their chain's governance with Substrate.

Governance design

To begin, it's important to remind yourself that as a runtime engineer, you have complete control on the design and governance rules you're building. Models based on democratic systems are conscious design decisions for optimizing whatever the needs are of the system, such as with Polkadot's initial tri-cameral system. Other systems may better be modelled by alternative forms of governance depending on their scale and target participants. For example, corporate vs. non-profit governance models (possibly more suitable for smaller scales, like project based initiatives) or different types of democracy (possibly more suitable for larger scales, like sovereign nations).

Building out systems of governance

Once you've got a grasp of the type of system you're looking to build, there's a number of routes you could take, neither of which are necessarily mutually exclusive.

Use and modify existing pallets

There's a number of pallets you can use to compose your chain's system of governance, whether building out its core design (i.e. the underlying system) or adding functionality to it or refactoring existing components into more modular ones that suit your chain's needs (similar to how FRAME has seen a refactor in the democracy pallet).

Here are some examples of some existing building blocks used to compose systems of governance in Substrate chains:

• pallet_sudo: to designate a super-user that has control over the entire system.
• pallet_democracy: to handle stakeholder voting, including delegation and proposals.
• pallet_conviction_voting: to manage voting in polls and for referenda, containing voting data types.
• pallet_referenda: to execute referenda.
• pallet_preimage: for storing and managing the pre-image of a proposal, such as a runtime upgrade.
• pallet_collective: to form councils made of sets of account IDs that can be used as custom origins to dispatch otherwise gated runtime calls.
• pallet_membership: a way to manage memberships of account IDs inside a collective.
• pallet_schedular: to schedule the enactment of a proposal.

From this, there are a number of things built that use the core governance logic to meet certain system requirements or end-users' needs, such as with:

• pallet_treasury: a pot of funds that act as a central piece to making spending proposals to an on-chain council.
• pallet_bounties: a way to manage treasury spends specific for on-chain bounty work.
• pallet_society: an economic game to incentivize a set of members to maintain their membership in a society.

Implementing custom mechanisms

Within FRAME, there are a number of existing governance primitives that you can use to create your own custom pallets to meet your application specific needs. The pallets referred to above are all built using these (using custom data types and algorithms). At a high level, you can use these to create custom mechanisms such as:

• Voting mechanisms (using conviction, votes, delegation, locks, a simple majority implementation, quadratic voting algorithm).
• Reward mechanisms (slashing logic, rewards, tipping logic, treasury, bounty and payout logic).
• Mechanisms for proposals and enacting them (lock deposit logic, custom origin logic, scheduling).
• Forming councils and committees (using voting, memberships and origins).

Things to think about

Governance implementations should consider the problems that could arise depending on what is being governed and whatever the desired/undesired outcomes could be. The useful thing in Substrate is that anything can be upgraded, by design. Systems can evolve with changing end-user needs, inviting developer experimentation.

Some things to think about that come to mind:

Participation and fragmentation

• Whatever the democratic system you devise will only be as good as how active your target participants are. There are ways to address this with different mechanisms, such as tipping bots, signalling and off-chain verification mechanisms (oracles). But not necessarily all on-chain, such as attractive web and mobile applications, engaging UX.
• From a multi-chain and anti blockchain maximalist view, participatory systems should probably strive to avoid building walls around communities. Solutions that could fit the bill include multi-asset stake weighted voting or multi-chain UIs with a single user experience.

Collusion

• How to build systems that are resistant to whales or other forms of collusion, where more privileged accounts may game the system.

There is no single path to implementing your chain's system of governance. Each chain should implement a system of governance to meet their needs. As Substrate developers, we can stand on the shoulders of the battle tested FRAME pallets already in production. But we should be mindful that, out of the box, these are built to address the specific needs of application specific chains (i.e. Polkadot and Kusama) and may not necessarily be those we're looking to address.

Answer 2

You have to implement the pallet democracy pallet democracy , you can follow how it is implemented in the dev node,the github repository is a good start .

You will also need to implement the pallet_collective, except if you have your own way to handle the proposal execution.