0

I would like to use the sudo pallet instead of the democracy pallet.

Now I would like to force the sudo user to wait three months until a runtime upgrade can be applied. So, that there is no way to execute a runtime upgrade before this period of three months has passed (not even an emergency upgrade). How is this possible?

What transactions should be filtered, so that this rule can't be avoided by the sudo user?

1 Answer 1

1

What transactions should be filtered, so that this rule can't be avoided by the sudo user?

You do not force sudo to do anything. Sudo is the force.
Sudo::sudo results in Root and can arbitrarily change your runtime, eg. via set_code, thereby removing any call filters.

Sudo is the wrong approach here. Is a way too powerful tool for the job. You need a very restricted origin that can do JUST that. Queueing runtime upgrades with a 3 months lead. I think Gov V2 has the tools for that. Not sure about how it would look like with the current gov.

2
  • Then I will develop an own pallet, which just does that. Pallet democracy doesn't fit my intention. Thanks a lot! My intention is to have a pallet, which can enact runtime upgrades, but after a review period of 3 months. User can decide, if they want to participate in the protocol any further (3 months to get all funds back and away to another chain).
    – Chralt
    Jan 13 at 5:19
  • Yea a custom pallet would do well here. Jan 13 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.