Blockchains are becoming more and more interconnected. While today, governance on a chain is typically tied to assets that are present on that chain. For example, the Cosmos Hub is governed only by Atom that is locked as stake on the Cosmos Hub. As DeFi applications become more popular and with the rise of shared security solutions such as Babylon and Eigenlayer (providing security with locked Bitcoin and Ethereum respectively), less stake needs to be locked on the chain to provide security, and assets can instead be more freely used in DeFi applications.

If these assets are still sufficiently tied to their origin chain, we likely want them to be able to participate in governance. For example, Atom that is locked in LP pools on Osmosis is doing an important job providing liquidity to the network, so it is important if those funds can still participate in governance, even if they are directly providing security.

Additionally, we also want more expressivity for cross-chain agreements. For example, the Cosmos Hub is an interchain security provider chain and gives security to consumer chains like Neutron. Some parameters on the Hub might have immediate impacts on Neutron, and it would be useful if Neutron could have a say in those parameters. In turn, for some proposals on Neutron, it might want to give the Hub a say in the decision. One prominent example are IBC rate limits. The rate limits on both chains could be different, but in the case of light-client attacks, the rate limit on the receiver side actually safeguards the sender chain, so these parameters are perfectly suited to be jointly owned by the sender and receiver.

ccgov(1).png

Architecture

ccgov_archi(1).png

There is one main contract on each chain that is responsible for voting on and executing proposals. Each proposal has a list of PrerequisiteRemoteProposals that need to have finished on the remote chain before the final outcome of the proposal is known. When the voting period of a proposal is passed, anyone can permissionlessly Execute the proposal to tally the votes (and pay gas for this). If there is a prerequisite remote proposal that we have not gotten the results for yet, the execution will fail, but the contract instead queries the remote prerequisite proposal contract for the result. Once the host chain has received the results of all prerequisite remote proposals, trying to Execute the proposal will succeed and determine the final outcome.

The voting power of voting users is provided by an additional VotingPowerSource contract. For now, there is just an implementation of a simple power source contract that gives each user a fixed voting power; in reality, these contracts would query e.g. the user's stake on the chain, the LP tokens they have locked in a certain pool, etc.

Right now, the contract just sums the votes for all remote prerequisite proposals with the local votes and uses that to determine the outcome, but in principle there could be more complicated logic. One example would be having Neutron stakers vote on a proposal on the hub, but the hub having a veto right.