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
When migrating a position from balancer to CL, a user that was SFS should be frozen in place for whatever remaining time that user had on their balancer lock. This is to allow a retroactive slash in the even their SFS got slashed during migration
Migrating should only be a temporary message that eventually gets removed. We should add a gov feature that enables and disables migrating for specific pools.
We really need to consider what this retroactive slash would even look like. Imagine a user with 1 min freeze left gets slashed and then IBCs out. We couldn't slash this individual. It feels like there needs to be some hook in place that freezes the position indef in the event their migrated position would have been slashed.
Additionally, the above retroactive slashing should be explicitly approved by governance before being added to the upgrade.
Suggested Design
Implement freeze logic
Implement gov messages
Acceptance Criteria
Tests added
Have an answer for retroactive slashing design
The text was updated successfully, but these errors were encountered:
Background
When migrating a position from balancer to CL, a user that was SFS should be frozen in place for whatever remaining time that user had on their balancer lock. This is to allow a retroactive slash in the even their SFS got slashed during migration
Migrating should only be a temporary message that eventually gets removed. We should add a gov feature that enables and disables migrating for specific pools.
We really need to consider what this retroactive slash would even look like. Imagine a user with 1 min freeze left gets slashed and then IBCs out. We couldn't slash this individual. It feels like there needs to be some hook in place that freezes the position indef in the event their migrated position would have been slashed.
Additionally, the above retroactive slashing should be explicitly approved by governance before being added to the upgrade.
Suggested Design
Acceptance Criteria
The text was updated successfully, but these errors were encountered: