x/gov and x/group alignment

[aaronc]

This is something that has been discussed a few times ad hoc but isn't properly documented. For reference, x/group refers to the group module currently in https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1 and https://github.com/regen-network/regen-ledger/tree/master/x/group, and soon to be upstreamed here to the SDK.

Here are the changes I've had in mind that would align x/gov and x/group

x/gov protocol changes

MsgSubmitProposal

Proposed changes:

• add a string account field to refer to the governance account this proposal refers to, ex. staking governance, a group account or holders of a DAO token
• add repeated googlee.protobuf.Any messages field to replace content
• deprecate content

message MsgSubmitProposal {
  google.protobuf.Any content                       = 1 [deprecated = true, (cosmos_proto.accepts_interface) = "Content"];
  repeated cosmos.base.v1beta1.Coin initial_deposit = 2;
  string proposer = 3;
  
  // account refers to the governance account the proposal corresponds to. If it is empty it is assumed that the proposal is for the root chain governance account (i.e. staking token holders).
  string account = 4;
  
  // messages are the proposal content to be executed if the proposal passes
  repeated sdk.Msg messages = 5;
}

Create root account

Since MsgSubmitProposal always corresponds to some account, we would create a root module account that corresponds to the current staking governance. This has the advantage that the root account can now use x/authz to delegate certain permissions of chain governance to working groups.

Deprecate gov.Content and switch to regular Msgs

All of the gov.Content types correspond to actions that can only be performed by chain governance and there is no way for chain governance to perform the simple operation of sending some regular Msgs.

x/group just uses regular Msgs and we can extend this reuse of the Msg abstraction to the root chain governance by adding Msgs for parameter change and software upgrade proposals that can only be executed by root.

Tally or Decision Policy methods

Every account that can work with x/gov would need to have some sort of tally handler or DecisionPolicy (as in x/group associated with it). We will need to figure out how each module registers its DecisionPolicy but I think it would basically be a pluggable system where modules supporting x/gov would register policies for their account types. x/group has its mechanism for associating DecisionPolicys with group accounts and possibly x/group could be extended to support DAO token balances.

Tallying and Proposal Execution details

Currently x/gov does tallying after the voting period has ended whereas x/group does tallying with each vote. This is in part because x/group allows DecisionPolicys that will execute the proposal before the voting window has voted if there is a quorum, and also due to gas considerations. It does introduce the complication that in x/group, we need to deal with the case where the group membership changes. Currently this is handled by invalidating active proposals when group membership changes (because voting weights would become invalid). This would be hard to extend to token balances because token balances are in constant flux, so likely the x/gov EndBlocker approach is better suited for this. To support the group use case, it would be desirable to introduce a method to x/gov such as MsgTryExec which attempts to execute the proposal early with the msg sender paying the gas for tallying in this case.

Also, the EndBlocker approach only works for x/gov because the gas is paid for by the chain. We could potentially use the proposal deposit to pay for gas in the EndBlocker and then x/gov’s approach could become more generic. This could maybe address the concerns that led x/group to prefer tallying with each vote. Currently group accounts don’t require deposits which makes sense if a group is just a few people who know each other, so to support groups, x/gov deposits would need to be configurable.

---

@sunnya97 I know you've been thinking about this a fair bit too and would love if you’d chime into whether this aligns with your thinking or not.

/cc @hxrts @marbar3778 @blushi

[hxrts]

With this unification we could replicate the Gnosis multi-sig + Snapshot off-chain voting system. For example, representing the community pool, the "group" would be the set of all token-weighted accounts, the "group account" would then be a set of user accounts responsible for aggregating off-chain votes and submitting them on-chain, and the "decision policy" would replicate the escalation framework Gnosis uses, reality.eth (or something more naive to begin with).

Snapshot voting largely was motivated by high gas fees on Ethereum, which is less of a concern for Cosmos, but there is also a large UX improvement in not needing funds in your wallet to participate, or potentially deal with the accounting. Fee grants attempts to solve a similar problem, however the trust assumptions and potential use-cases differ.

[cmwaters]

This is a very nice write up 👍 I've been looking over the governance module (with the aid of Sam) over the last couple of weeks trying to gain some context about it and definitely agree with the notion that the executional aspect of a proposal should just be represented as an array of messages.

At a higher level, I think the scope of governance should not be to worry about execution so much but to focus on capturing the preferences/views of some arbitrary group of members (i.e. consensus). To me, this means fluidity in what people can vote for and the voting tally mechanism itself (I think this is what decision policy means right?)

I have a few clarification questions that I want to ask.

• Can you explain a little more about this account string? Is it akin to the Group Account where it ties to an aggregation of accounts with weights and a decision policy. Where would these accounts be stored? In governance itself or part of the groups module / other modules that use gov.
• Would the groups module use the gov module to allow groups to initiate proposals and vote on them that are in relation to that group? Or perhaps more broadly what is the relationship between gov and groups?

Also, I have appended a few thoughts (I'm not sure how well constructed they may actually be)

• In regards to deprecating Content, I think a proposal should still include some way for the proposer to actually state the purpose of the proposal and be able to justify it (i.e. there should be some description or at least a link to a description)
• I think having this bonding period concept (or some delay) helps with the problem of members leaving and joining a group. If this period is longer than the voting period then I don't believe it is necessary to invalidate active proposals. In regards to weight changes this is a difficult one, we would want to avoid the scenario where someone can temporarily prop up their voting power just to make the vote and then return back to their normal voting power.

[aaronc]

This is a very nice write up 👍 I've been looking over the governance module (with the aid of Sam) over the last couple of weeks trying to gain some context about it and definitely agree with the notion that the executional aspect of a proposal should just be represented as an array of messages.

At a higher level, I think the scope of governance should not be to worry about execution so much but to focus on capturing the preferences/views of some arbitrary group of members (i.e. consensus). To me, this means fluidity in what people can vote for and the voting tally mechanism itself (I think this is what decision policy means right?)

I have a few clarification questions that I want to ask.

• Can you explain a little more about this account string? Is it akin to the Group Account where it ties to an aggregation of accounts with weights and a decision policy. Where would these accounts be stored? In governance itself or part of the groups module / other modules that use gov.

account is a regular SDK account address. The group module creates a type of module account called a group account. If the group module became a plugin to the gov module then likely we would need a plugin interface that pulls the decision policy from the plugin that manages each account.

• Would the groups module use the gov module to allow groups to initiate proposals and vote on them that are in relation to that group? Or perhaps more broadly what is the relationship between gov and groups?

Yes, as I mentioned above I'm imagining group would implement a plugin to gov.

Also, I have appended a few thoughts (I'm not sure how well constructed they may actually be)

• In regards to deprecating Content, I think a proposal should still include some way for the proposer to actually state the purpose of the proposal and be able to justify it (i.e. there should be some description or at least a link to a description)

Totally.

• I think having this bonding period concept (or some delay) helps with the problem of members leaving and joining a group. If this period is longer than the voting period then I don't believe it is necessary to invalidate active proposals. In regards to weight changes this is a difficult one, we would want to avoid the scenario where someone can temporarily prop up their voting power just to make the vote and then return back to their normal voting power.

So I think bonding makes sense when you're thinking of a DAO coin. Bonding doesn't make sense when a group is a set of individuals who know each other or maybe a group of elected officials. With the plugin model I have in mind, each plugin would specify the decision policy, weighting, bonding, etc. for the accounts that it manages.

[aaronc]

I do not believe we should give members who have been added mid-vote a voice in decision-making that's already in-progress. We should lock-in voting weights (token or otherwise) when a proposal submitted. This is more straightforward to reason about as a voter (I know exactly how much my vote counts for a given proposal) and less game-able overall.

I can't actually think of any conventional voting scenarios where locking in weights at the start of voting is what you would want. Usually, I think we have the expectation that voting is based on the final weights. It wouldn't make sense that if say an elected official is removed from congress that they still get to vote on laws that were proposed while they were still in office. Once somebody loses their power they can't vote. I think voting weights at the start might make sense if we're talking about DAO coins, but that's just one case. Ultimately, I think this should be something that is pluggable based on the type of voting account.

I do want to mention that taking a snapshot of weights at the start is something that requires extra technical considerations. Either, a) you copy all the weights into the proposal which could be a lot of state if there are a lot of accounts eligible to vote, b) you invalidate proposals when weights change but this doesn't work for token balances, or c) chains have state snapshots at predefined epochs and these epochs are used for proposal start times. I'm leaning towards thinking that c) is a more elegant, scalable option but it is fairly involved to make work at the protocol layer.

Regarding gas fees perhaps I understanding wanting to lower the barrier to entry for groups to coordinate, but I think the UX around submitting a follow-up transaction for the proposal to execute once passed is quite poor and outweighs the deposit requirement. Estimating the correct deposit will be a challenge.

I don't think there's a simple answer and likely we will want to support both pre-paid and post-paid fees.

[hxrts]

I think your politician term analogy isn't quite right here. More appropriate might be joining a coop on the day of a board election. It's not unreasonable that the new member wouldn't be eligible to vote for some probationary period.

Could we use the account snapshot at prior epoch and then track a small change set to time of proposal?

[aaronc]

I think your politician term analogy isn't quite right here. More appropriate might be joining a coop on the day of a board election. It's not unreasonable that the new member wouldn't be eligible to vote for some probationary period.

Whatever analogy we use, I think it is true that there are cases where voting should be based on initial state and cases where it should be based on final. I could argue the contrary for a coop - I belong to a food coop here and I'm quite sure I could join and vote on the day of the election. Anyway, my main point is that technically we should support both.

Could we use the account snapshot at prior epoch and then track a small change set to time of proposal?

Hmm... if there's a high transaction volume, I think that would slow down the chain a bit. I was more thinking that proposals always start and end at epoch points when we want to use initial state. This would need a fair bit of design for sure.

[ethanfrey]

I can't actually think of any conventional voting scenarios where locking in weights at the start of voting is what you would want. Usually, I think we have the expectation that voting is based on the final weights. It wouldn't make sense that if say an elected official is removed from congress that they still get to vote on laws that were proposed while they were still in office. Once somebody loses their power they can't vote.

Uh, I'm sorry but all US law works that way.

When congressman looses the election on Nov 4th, they still vote for 2 more months.

Eligability to vote in a public election is based on election roles which are fixed 1-2 month prior to the election. If someone died the week before or just moved to a new area, that is not reflected in the voter eligabilty.

I think "virtual snapshot at time of proposal" is the most expected behavior. It cares efficiency issues, but if you can resolve those, it is definitely the most desirable approach.

[cmwaters]

I spent some of the weekend looking over this and have came back with a few more thoughts that I would like to document here.

Looking back at the changes proposed for MsgSubmitProposal and going over the groups module ADR , It almost seems redundant to have any form of a proposal type in x/gov (or even vote type for that matter). It feels more to me that x/gov should be an implementation of x/groups. In this regard, x/gov only has the following responsibilities:

1. Defines and manages the group members (based on their stake).
2. Allows modules to register proposal types. This can be either that the module needs to pass a handler to x/gov in baseapp (as it is currently) or that the module is programmed to receive msgs from the governance group address.
3. Defines a set of "core" decision policies that modules (like params and distribution) can use when registering their proposals. It also needs to keep track of the decision policy for each active proposal.

On top of this, it would be nice if:

4. Gov module was capable of creating and organising election-based subgroups where these subgroups were given certain capabilities. This would enable "councils" that could be responsible for specified subsections i.e. a group that can manage params or the community pool.
5. The ability to vote to change decision policies or perhaps just particular parameters within that decision policy.

[aaronc]

Interesting approach to consider. I think 3 is handled already by the group module for each account and isn't really scoped to the specific types of proposals. 4 is handled by the authz module. 5 is already handled by the group account admin role.

One important thing that this approach enables is associating different decision policies with staking governance. If we consider gov to just be a group based on staking weights then this is possible - we simply associate different decision policies with gov to create different group accounts and use authz to delegate permissions to the "sub accounts".

I don't have a strong preference for whether the core propose and vote functionality lives in x/group or x/gov, but I do think we should aim for this sort of architecture.

[aaronc]

Just as a follow-up, we met today with @cmwaters @blushi and @hxrts to discuss this topic and the general consensus was that making x/gov a plugin to x/group as @cmwaters is describing makes sense architecturally.

[ethanfrey]

I'm curious as to the timeframe of this.

This is not being considered for 0.43 is it? (As it will significantly delay that release)

Is this part of 0.44 planning? I assume it goes along with replacing Keeper usage with Message passing (which seems to be a building block to allow the governance proposals to be used as normal messages)

[aaronc]

This is definitely part of planning for the next release. I would consider most discussion threads here as part of future release planning. The 0.43 scope is pretty set in stone at this point IMHO and just subject to change based on QA.

[sunnya97]

Love to see this! @ValarDragon, @antstalepresh, and I have been thinking quite a bit about similar ideas as well. We wrote up 90% of a proposal actually for this a couple weeks ago, which I'll repost here. I think it's pretty aligned with a lot of these ideas.

---

Account permissioning governance

Currently all governance updates must be voted on by the entire staked token set. However its very easy to imagine situations where certain on-chain items that are being governed, should not be governed by the staked token holders.

• An on-chain AMM module may want to be governed by its LP's, or other governance token holders (e.g. $UNI)
• A Circuit Breaker may want to be maintained by a multi-sig of semi-trusted entities
• Certain on-chain parameters may want to be updated by anyone who provides a proof that it would be better. (Imagine someone providing a proof that the average block time in the last month was X, and then updating the blocks / year parameter accordingly).

The current answer for those situations is to engineer a new specialized governance system for those items. However it would be nice to make a unified permissioning approach for all of these. Module accounts enable us to do this.

Dividing up the permissions for this

Governance fundamentally is about managing who is allowed to update a given object. So we can frame the existing proposal types as TextProposals simply record some data to state, and parameter change proposals are mutating the

This change then requires governance proposals to be "triggerable" from a given account. So every governable object in the SDK should have an associated list of owners field, which can trigger an update to the object.

Permissioning Governance Params

We need a way to refer to these different governance sets. The address namespace enables us to do this, as it can refer to both module accounts and user accounts / multisigs. A module account

We could design a new namespace to refer to different governance procedures, but we reckon there's already an existing namespace that can be re-used for this purpose: the account addresses.

We suggest that each goverance procedure should be associated with an Address (a process for determining these addresses is already laid out in ADR-028). This is similar to what happens currently on Ethereum, in which both smart contracts and EOAs are accounts with indistinguishable addresses. Because of this, an application can assign governance control to a designated address, without caring whether said address is an EOA, DAO smart contract, multisig contract, etc.

Along with combining the namespaces for "governance accounts" and "external accounts", we should also combine the interfaces of "governance-triggered actions" and "account-triggered actions". Currently the former uses gov.Contents while the latter uses sdk.Msgs. Because governance processes are going to be accounts with addresses, all current gov.Content types should be replaced with equivalent functionality sdk.Msgs.

For example, the ParameterChangeProposal that currently looks like this:

type ParameterChangeProposal struct {
	Title       string
	Description string
	Changes     []ParamChange
}

would be replaced by a MsgParameterChange that looks like this:

type MsgParameterChange struct {
	Changes     []ParamChange
    Sender     sdk.AccAddress
}

x/gov will then only need a single Content type that executes a Msg:

type ExecuteMsgProposal struct {
	Title           string
    Description     string
    Msg             sdk.Msg
}

This proposal would be voted on by the governance procedure whose address is proposal.Msg.Sender.

And then the x/params module can choose which addresses are allowed to update particular parameters.

But these addresses don't have to be what we typically think of normal accounts today. Instead, an address should be able to refer to think like a Groups Module account, a CosmWasm contract, etc. In Ethereum, smart contracts and EOAs both exist as types of accounts. This is nice, because you can assign permissions to an address, without caring whether it's an EOA or a DAO or a stateful multisig.

So in this paradigm, even instantiations of the governance module would themselves become accounts. For example, we can have a special root account that sending a Msg from require passing the governance process in which staked tokenholders vote. But we can also create new "instantiations" of a x/gov account that's based on a different voting set.

As an example, we could have a DAO in our chain that wants to upgrade its parameters via a governance proposal of its own token holders (which is distinct from the chain's staking token). It can permission these updates such that they're required to come from the address of the x/gov account that sends Msgs based on governance of the daotoken.

These procedures for whose votes to tally and the logic for how to tally them is called a TallyStrategy.

[sunnya97]

We also have some sample code for creating modular TallyStrategies here: sikkatech#64

Note, that this code uses a new namespace called TallyRoutes instead of the address space as proposed above. However, the TallyStrategy concept is a good sample prototype.

[cmwaters]

So thinking further on how governance interacts with x/groups, I can foresee two paths we can look to go down:

Path 1: Governance as an instance of groups (no x/gov path)

• We have the staking module to have it's own staking group which has the responsibility of updating group member weightings when delegations/staking amounts change.
• Other modules like params or distribution give authorization for the staking group to make changes to the params / community spend. Then validators/delegators can simply propose to the staking group with these msgs and others can approve / disapprove
• The outstanding problem with this approach is that proposals are aborted when there is a group membership change. Even with epoch staking, we'd still expect membership to change far too frequently. It could be an idea to make the DecisionPolicy decide whether a proposal is aborted or not. If we allowed free movement of membership then this would require some notion of snapshotting where the weights at the time of the proposal would be saved and then the Tally for that proposal would refer to the snapshot when adding votes
• The second incongruity is with the deposit mechanism which adds friction to proposals and prevents spamming (which is especially important when using snapshots)

In summary of this path, I think the main question here is how willing are we to make groups accommodate for both small simple static groups as well as large dynamic and complex groups.

Path 2: Governance as a standalone module

• This is more akin to the current standing where governance is a separate module yet takes some of the concepts of groups (DecisionPolicy and Tally ) to make it more feature rich.
• Governance proposals contain an array of messages to be executed if passed
• Governance is still capable of creating sub groups and giving permissions to these (i.e. councils)
• To begin with governance would probably have a single decision policy for all proposals (that could be changed), but in later iterations, governance could select different decision policies for different categories of proposals.

[blushi]

Here are some updates from the gov/group WG.

We talked about doing a two phase approach:

• In the midterm we should do a minimal integration between the gov & group module as specified in Minimal x/gov & x/group Alignment #9438
• Long-term, we're working on a more refined design (see https://hackmd.io/7QeyCqGES_SFy3WLcyNXGg and specs in repo https://github.com/interchainberlin/metachain). Focus on use cases is the primary step in this direction in order to inform the design.

Also check out https://linktr.ee/cosmos_gov for more updates.