-
Notifications
You must be signed in to change notification settings - Fork 1
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
Allow accounts to exit the system #66
Milestone
Comments
3 tasks
Realized that leaving the system only makes sense when there's upgradeability in place. So this is somewhat blocked by #20 |
Related to logos-co/staking#148 |
0x-r4bbit
added a commit
that referenced
this issue
Oct 28, 2024
This adds a new emergency mode that can be enabled by the owner of the system. When in emergency mode, stakers or `StakeVault`s can leave the system immediately. Closes #66
3 tasks
0x-r4bbit
added a commit
that referenced
this issue
Oct 28, 2024
This adds a new emergency mode that can be enabled by the owner of the system. When in emergency mode, stakers or `StakeVault`s can leave the system immediately. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Oct 29, 2024
This adds a new emergency mode that can be enabled by the owner of the system. When in emergency mode, stakers or `StakeVault`s can leave the system immediately. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Oct 30, 2024
This adds a new emergency mode that can be enabled by the owner of the system. When in emergency mode, stakers or `StakeVault`s can leave the system immediately. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 26, 2024
This adds a new emergency mode that can be enabled by the owner of the system. When in emergency mode, stakers or `StakeVault`s can leave the system immediately. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 27, 2024
This adds a new emergency mode that can be enabled by the owner of the system. When in emergency mode, stakers or `StakeVault`s can leave the system immediately. This also applies when there was a malicious upgrade and a call to `emergencyModeEnabled()` panics. To have this in a fully secure manner, we still have to add the counter part of "leaving" the system. This will allow users that don't agree with a (malicious) upgrade to get their funds out of the vaults regardless. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 27, 2024
This adds a new emergency mode that can be enabled by the owner of the system. When in emergency mode, stakers or `StakeVault`s can leave the system immediately. This also applies when there was a malicious upgrade and a call to `emergencyModeEnabled()` panics. To have this in a fully secure manner, we still have to add the counter part of "leaving" the system. This will allow users that don't agree with a (malicious) upgrade to get their funds out of the vaults regardless. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 27, 2024
This function allows users to `leave()` the system if they can't or don't want to trust the stake manager. This is the case when the owner of the stake manager performs an upgrade (upgradeability lands in future changes). In case of such an upgrade, the stake manager will be marked as not trusted which prevents the user from staking, unstaking, locking etc. The user can then either explicitly trust stake manager (will happen in future changes) to enable the vault's functionality again, or, `leave()` the system at which point it will try to perform a benign `leave()` operation and then move the funds out of the vault. Closes #66
3 tasks
0x-r4bbit
added a commit
that referenced
this issue
Nov 28, 2024
This adds a new emergency mode that can be enabled by the owner of the system. When in emergency mode, stakers or `StakeVault`s can leave the system immediately. This also applies when there was a malicious upgrade and a call to `emergencyModeEnabled()` panics. To have this in a fully secure manner, we still have to add the counter part of "leaving" the system. This will allow users that don't agree with a (malicious) upgrade to get their funds out of the vaults regardless. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 28, 2024
This function allows users to `leave()` the system if they can't or don't want to trust the stake manager. This is the case when the owner of the stake manager performs an upgrade (upgradeability lands in future changes). In case of such an upgrade, the stake manager will be marked as not trusted which prevents the user from staking, unstaking, locking etc. The user can then either explicitly trust stake manager (will happen in future changes) to enable the vault's functionality again, or, `leave()` the system at which point it will try to perform a benign `leave()` operation and then move the funds out of the vault. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 28, 2024
This adds a new emergency mode that can be enabled by the owner of the system. When in emergency mode, stakers or `StakeVault`s can leave the system immediately. This also applies when there was a malicious upgrade and a call to `emergencyModeEnabled()` panics. To have this in a fully secure manner, we still have to add the counter part of "leaving" the system. This will allow users that don't agree with a (malicious) upgrade to get their funds out of the vaults regardless. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 28, 2024
This function allows users to `leave()` the system if they can't or don't want to trust the stake manager. This is the case when the owner of the stake manager performs an upgrade (upgradeability lands in future changes). In case of such an upgrade, the stake manager will be marked as not trusted which prevents the user from staking, unstaking, locking etc. The user can then either explicitly trust stake manager (will happen in future changes) to enable the vault's functionality again, or, `leave()` the system at which point it will try to perform a benign `leave()` operation and then move the funds out of the vault. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 29, 2024
This function allows users to `leave()` the system if they can't or don't want to trust the stake manager. This is the case when the owner of the stake manager performs an upgrade. In case of such an upgrade, the stake manager will be marked as not trusted which prevents the user from staking, unstaking, locking etc. The user can then either explicitly trust stake manager (will happen in future changes) to enable the vault's functionality again, or, `leave()` the system at which point it will try to perform a benign `leave()` operation and then move the funds out of the vault. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 29, 2024
This function allows users to `leave()` the system if they can't or don't want to trust the stake manager. This is the case when the owner of the stake manager performs an upgrade. In case of such an upgrade, the stake manager will be marked as not trusted which prevents the user from staking, unstaking, locking etc. The user can then either explicitly trust stake manager (will happen in future changes) to enable the vault's functionality again, or, `leave()` the system at which point it will try to perform a benign `leave()` operation and then move the funds out of the vault. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Nov 29, 2024
This function allows users to `leave()` the system if they can't or don't want to trust the stake manager. This is the case when the owner of the stake manager performs an upgrade. In case of such an upgrade, the stake manager will be marked as not trusted which prevents the user from staking, unstaking, locking etc. The user can then either explicitly trust stake manager (will happen in future changes) to enable the vault's functionality again, or, `leave()` the system at which point it will try to perform a benign `leave()` operation and then move the funds out of the vault. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Dec 1, 2024
This function allows users to `leave()` the system if they can't or don't want to trust the stake manager. This is the case when the owner of the stake manager performs an upgrade. In case of such an upgrade, the stake manager will be marked as not trusted which prevents the user from staking, unstaking, locking etc. The user can then either explicitly trust stake manager (will happen in future changes) to enable the vault's functionality again, or, `leave()` the system at which point it will try to perform a benign `leave()` operation and then move the funds out of the vault. Closes #66
0x-r4bbit
added a commit
that referenced
this issue
Dec 1, 2024
This function allows users to `leave()` the system if they can't or don't want to trust the stake manager. This is the case when the owner of the stake manager performs an upgrade. In case of such an upgrade, the stake manager will be marked as not trusted which prevents the user from staking, unstaking, locking etc. The user can then either explicitly trust stake manager (will happen in future changes) to enable the vault's functionality again, or, `leave()` the system at which point it will try to perform a benign `leave()` operation and then move the funds out of the vault. Closes #66
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Once #14 is done with its most minimal basic functionality, we need to teach the reward streamer the notion of "exiting" the system.
In the previous protocol, this was done via a
leave()
function.We probably want a similar one in the
StakeVault
that lives in this repository.The text was updated successfully, but these errors were encountered: