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

Feature: Establish a program update council #54

Open
mschneider opened this issue Oct 29, 2021 · 4 comments
Open

Feature: Establish a program update council #54

mschneider opened this issue Oct 29, 2021 · 4 comments

Comments

@mschneider
Copy link
Collaborator

mschneider commented Oct 29, 2021

There are a few workflows that require creating a new governance from the UI.
One example would be the recent vote I created to establish a program update council: https://dao-beta.mango.markets/dao/MNGO/proposal/GqowP2B2ZaACxrhUy2nAq7Hem4ZoN5HNtb4zpgRfzF8r

Here are the steps I went through to set this up:

  1. create a 0 decimal mint with spl-token cli
  2. create an associated token account for every council member with spl-token cli
  3. transfer mint under governance
  4. create a proposal to mint the tokens to the associated token accounts
  5. create a new realm governed by the new mint
  6. create a new governance governing the mango v3 program
  7. transfer program update key to the new governance

From now on we can vote on program updates using the council mint.

@jpbogle
Copy link
Contributor

jpbogle commented Nov 3, 2021

for step 2

create an associated token account for every council member with spl-token cli

can this be done lazily? i.e. when they visit the UI just generate the council member an aToken account for the council mint if they dont have one already?

I guess it would mean that the proposal in step4 would also need to generate them all aToken accounts? but seems like that piece of creating that proposal to give them all token is an optional thing this feature in the UI may not need to do automatically

@mschneider
Copy link
Collaborator Author

mschneider commented Nov 4, 2021

It would definitely be possible to create the account right before execution of the finalized instruction in the UI. I think that's a great idea!

The reason why this works is that aToken accounts are deterministic PDAs.

I'm currently working on issue #58 on this branch mschneider/assembly@ccc5ab9

My solution there was to write convenience functions into the main client library, so that I can easily create the atoken accounts when creating the proposal if they don't exist yet. This way it was easy to include the respective methods in integration tests and test in isolation of the governance UI.

For this feature #54 it does make a lot of sense to do it differently though. I'd welcome a PR with a lazy solution as you described it.

@jpbogle
Copy link
Contributor

jpbogle commented Nov 9, 2021

cool, I started looking at doing this and ended up getting a bit side tracked playing with other things as I dug deeper into the code.

Im curious for this feature what you imagine the UI looking like since it doesnt have a concept of governances right now it seems. do you think there should be like a list of all governances somewhere and you can add new ones, similar to the oyster UI or do you imagine hiding the concept of governances a little bit and just having a button that is like "create program update council" or more specific workflows

@mschneider
Copy link
Collaborator Author

mschneider commented Nov 13, 2021

Our approach for now is to hide governance whenever possible. As this process would include a proposal to vote on (4) it should just be another proposal type.

asktree pushed a commit that referenced this issue Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants