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
In case we need to do a redeploy or some sort of fork of this contract, can we make a constructor that can copy over the state of a previous contract?
This could also be used to revert state in case of a major breach.
For Example, let's say a ton of wallets got burned accidentally. We could revert to unburn them, but that would require whole community support to accept the new chain.
Also how would all other contracts that make use of BurnMyWallet update to point to new Burn Contract? Perhaps should have mini intermediary contract that just contains contract address to point to.
Or Perhaps that is already covered by Open Zeppelin upgradeable contracts? Look into that more, otherwise will need to setup a Pointer Contract in between so can switch contract addresses easily as long as the same interface is maintained (or at least is backwards compatible)
Also in case a migration was necessary of state, no sneaky state changes can be made since Repo is open source so the migration code would be visible, and would be verified on chain as well.
The text was updated successfully, but these errors were encountered:
In case we need to do a redeploy or some sort of fork of this contract, can we make a constructor that can copy over the state of a previous contract?
This could also be used to revert state in case of a major breach.
For Example, let's say a ton of wallets got burned accidentally. We could revert to unburn them, but that would require whole community support to accept the new chain.
Also how would all other contracts that make use of BurnMyWallet update to point to new Burn Contract? Perhaps should have mini intermediary contract that just contains contract address to point to.
Or Perhaps that is already covered by Open Zeppelin upgradeable contracts? Look into that more, otherwise will need to setup a Pointer Contract in between so can switch contract addresses easily as long as the same interface is maintained (or at least is backwards compatible)
Also in case a migration was necessary of state, no sneaky state changes can be made since Repo is open source so the migration code would be visible, and would be verified on chain as well.
The text was updated successfully, but these errors were encountered: