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

Make Governor contract for upgrades #243

Open
edmundedgar opened this issue Feb 28, 2024 · 1 comment
Open

Make Governor contract for upgrades #243

edmundedgar opened this issue Feb 28, 2024 · 1 comment

Comments

@edmundedgar
Copy link
Contributor

edmundedgar commented Feb 28, 2024

We'll need a governor contract that has to pass a reality.eth proposition before it can do an upgrade. We intend to gate this to a multisig to avoid making unforkable assets too easy to steal if we have a low market cap. The reality.eth will be forkable using the ForkableStructure.

Issue: The multisig can decide not to support a fork, depriving them of upgrades. In practice does this break the whole idea?

We could use a gnosis safe + reality module for this, or make something custom. Probably custom as it shouldn't be much code.

Structure:

  • Do we need this to be forkable and fork every time (so also implement ForkableStructure or is a single contract ok?
  • How does the reality.eth know that the fork happened? Options:
    • Give ForkingManager a reality.eth instance, add calls to handleInitializeFork and handleExecuteFork.
    • For less tight coupling, we could have ForkingManager call a handleInitializeFork method etc against the Governor, and the Governor in turn calls reality.eth in turn. However the ForkingManager doesn't currently know is admin, so should it call it from its zkEVM?
    • Just let anyone call the reality.eth after the fork has happened. Less code in ForkingManager, but creates an extra state (X is forked but Y isn't frozen) that we have to think about.
@josojo
Copy link
Collaborator

josojo commented Feb 28, 2024

In practice does this break the whole idea?

i mean we need trust in the multisig for sure. but this is needed by any l2 theses days. the goverance concept allows the community to deny a proposed update from the multisig. I think its a nice feature, but not 100% necessary for the launch.
(maybe we should focus on the essentials first :))

Just let anyone call the reality.eth after the fork has happened. Less code in ForkingManager, but creates an extra state (X is forked but Y isn't frozen) that we have to think about.

yeah, wouldn't like that extra state.

Give ForkingManager a reality.eth instance, add calls to handleInitializeFork and handleExecuteFork.

I think this tight coupling is good.

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