Prop 935: Create the Cosmos Hub’s Governance-Controlled Interchain Account on Neutron

Summary

The Cosmos Hubs most recent upgrade enables the Hub to create Interchain Accounts (ICAs) on remote chains that are controlled directly by the Hubs governance. This is a proposal for the Hub to create an ICA on Neutron that is controlled by the Hub's governance. While there are many reasons why the Hub might want this ICA on Neutron, one reason to create the ICA now is to enable the Hub to migrate its three current liquidity sharing deals off of the multisig controlled by AADAO and onto a trustless solution. To be clear, this proposal does not commit the Hub to performing any specific actions with the ICA. Rather the goal is to establish a general purpose ICA to Neutron for a wide variety of future use cases.

Reducing reliance on multisigs for remote actions

Composability in an app chain world requires the ability to perform remote actions. Today, all remote behavior must be performed via multi-sigs with nominated committees, which have numerous issues:

Administrative overhead

Recruiting the people necessary to manage the multisig takes time, as does coordinating each signing event among many parties. Due to the high security nature of multisig operations and lack of tooling, using a multisig requires a high degree of technical sophistication (e.g., interacting with node binaries via CLI, Ledger compatibility, etc.). This means a very limited number of people are currently eligible to participate, most of whom are extremely busy. These factors compound to make the coordination of signing events immensely painful. Moreover, to rotate members off of a cryptographic multisig actually requires instantiating an entirely new account and moving all funds. This makes member rotation for cryptographic multisigs incompatible with certain types of remote actions. DAODAO is a significant improvement on a number of dimensions, but is not yet available.

Liability

The liability surface of being a multisig signer makes it impossible for some to participate, and exposes those who do participate to unknown legal risk.

Trust Vulnerabilities

Even after finding willing and able multisig members, those dependent on the multisig are counting on the multisig members continuing to act in good faith. An extraordinary amount of effort is dedicated toward making protocols trustless – having a multisig act perform a core protocol function is contradictory to the ethos of crypto.

Operational Risk

Even if the individuals on the multisig continue acting in good faith, members of the multisig could lose their passphrase, have their accounts compromised by a malicious actor, or execute an incorrect message.

Slow Response

Even if the people on the multisig have nothing better to do than manage the multisig, the manual work required means that the funds managed by the multisig members cannot respond in real time to on-chain events. This precludes the introduction of automated mechanisms and the range of remote actions the Hub could take.

Interchain account as an alternative to multisigs

Establishing an ICA on Neutron that is controlled directly by Hub governance would enable the Hub to engage in a wide range of remote actions without the need for an intermediary multisig.

We at Timewave are excited to use the ICA to eliminate the need for the Hubs existing multisigs and use the ICA in conjunction with our Covenant System to expand the number of actions that the Hub can take in a trustless manner using this ICA. That said, the creation of this ICA DOES NOT commit the Hub to any specific remote actions. Establishing this ICA now simply removed the need for the Hub to have to deal with this technical step in the future when seeking to take a remote action.

Conclusion

Lets make it happen.

Who we are: Timewave

Timewave is a team dedicated to increasing the scope and scale of interoperability between crypto-native organizations. If you have ideas for how we can further this mission, we would love to hear from you: @TimewaveLabs.

Governance votes

The following items summarize the voting options and what they mean for this proposal:

Yes - You wish for the creation of a Hub-controlled ICA on Neutron No - You do not approve of a Hub-controlled ICA to be created on Neutron Abstain - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal. NoWithVeto - A NoWithVeto vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of NoWithVeto votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.