Skip to content
This repository has been archived by the owner on Jun 24, 2024. It is now read-only.

Determine how client upgradability should be handled #122

Open
Farhad-Shabani opened this issue Apr 4, 2024 · 1 comment
Open

Determine how client upgradability should be handled #122

Farhad-Shabani opened this issue Apr 4, 2024 · 1 comment
Labels
blocked Blocked by another (internal/external) issue or PR sov-light-client Related to Sovereign light client

Comments

@Farhad-Shabani
Copy link
Member

Summary

We need to determine how client upgradability should be handled on the Sovereign SDK rollups. Currently, there is no consensus or governance mechanism with the rollup. We must decide who should have the upgrade authority. Is it acceptable to have a centralized mechanism for this, or should a decentralized mechanism be considered?
@github-project-automation github-project-automation bot moved this to 📥 To Do in sovereign-ibc Apr 4, 2024
@Farhad-Shabani Farhad-Shabani added the sov-light-client Related to Sovereign light client label Apr 4, 2024
@Farhad-Shabani
Copy link
Member Author

Reply we got:

"Currently, Sovereign SDK does not support any upgrade mechanism. They may add an on-chain governance module at some point - but probably not in the short term. "

@Farhad-Shabani Farhad-Shabani added the blocked Blocked by another (internal/external) issue or PR label Apr 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
blocked Blocked by another (internal/external) issue or PR sov-light-client Related to Sovereign light client
Projects
sovereign-ibc
Status: 📥 To Do
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Farhad-Shabani