# 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.`Content`s while the latter uses `sdk.Msg`s. 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.