You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
ForkableStructure
or is a single contract ok?ForkingManager
a reality.eth instance, add calls tohandleInitializeFork
andhandleExecuteFork
.ForkingManager
call ahandleInitializeFork
method etc against theGovernor
, and theGovernor
in turn calls reality.eth in turn. However theForkingManager
doesn't currently know isadmin
, so should it call it from itszkEVM
?ForkingManager
, but creates an extra state (X is forked but Y isn't frozen) that we have to think about.The text was updated successfully, but these errors were encountered: