Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gov: replace Content and Proposal handlers in other modules with messages #10489

Closed
1 of 7 tasks
cmwaters opened this issue Nov 3, 2021 · 4 comments · Fixed by #11116
Closed
1 of 7 tasks

gov: replace Content and Proposal handlers in other modules with messages #10489

cmwaters opened this issue Nov 3, 2021 · 4 comments · Fixed by #11116
Assignees
Labels

Comments

@cmwaters
Copy link
Contributor

cmwaters commented Nov 3, 2021

Summary

Ref: #9438

Update: For v0.46.0, we are only doing MsgSoftwareUpgrade and MsgCancelUpgrade. Other Msgs will be added in future releases

This is a follow up issue on the use of an arbitrary array of messages in the proposal (#9810). Existing modules that use governance are still defining proposals as a Content and a proposal Handler. This needs to be replaced with their respective sdk.Msg type and a whitelist filter that only allows the governance module account to execute them. The following is a list of modules and the new messages:

  • x/distribution: CommunityPoolSpend. This could also be configured as the distribution module giving authorization to the governance module and then proposals would just be a regular spend from the distribution account to the recipients account.
  • x/params: ParameterChange. There is ongoing work to change this, so I'm not sure what the current status is.
  • x/upgrade: Upgrade & CancelUpgrade

cc: @blushi, @aaronc


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@cmwaters
Copy link
Contributor Author

cmwaters commented Jan 4, 2022

Update: We are going to keep Content and ProposalHandler's in the new design to allow for backwards compatibility. We should still try to convert the existing ones in the SDK to having their own messages but this can be pushed back to a later release if need be. Also there are going to be changes to x/params and potentially to x/distribution (see #10811) hence we should focus on x/upgrade first

@alexanderbez
Copy link
Contributor

We should still try to convert the existing ones in the SDK to having their own messages but this can be pushed back to a later release if need be.

I'm not sure we should even bother. What's the rationale behind that?

Also, why do we need to touch x/params at all?

@amaury1093
Copy link
Contributor

amaury1093 commented Jan 27, 2022

I'm not sure we should even bother. What's the rationale behind that?

We can provide an example (say in the docs) on how to create a Msg-based software upgrade proposal. To showcase the new proposal.

I'd say let's see next week how gov/group work advances. If the blocker is group, then we can include MsgSoftwareUpgrade into v0.46 in the meantime.

@alexanderbez
Copy link
Contributor

We can provide an example (say in the docs) on how to create a Msg-based software upgrade proposal. To showcase the new proposal.

Yes and leave the old ones as deprecated IMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
5 participants