search

logos-co / staking

SNT Staking contracts
Creative Commons Zero v1.0 Universal
0 stars 4 forks source link

Design restaking: Staking rewards exit the contract (no compouding) #17

Closed 0x-r4bbit closed 2 months ago

0x-r4bbit commented 1 year ago

Status Staking Summary describes the vaults and the re-staking process as follows:

Additionally, vaults can only be opened once by an initial stake, after that new stakes can not manually be added to the vault, they must be made as new vaults. Vaults can only grow from re-staking/compounding rewards earned by that vault. Earned SNT staking rewards can only be re-staked into the respective vault that earned them (note rewards can be withdrawn to a user’s address from any vault based on Withdraw logic discussed above).

The current implementation does not follow this logic as additional stake can be added after initial stake, re-staking is not possible without withdrawal. See the original document for context. These processes should reflect the cooldown periods that are a separate issue.

mart1n-xyz commented 1 year ago

Merging with Issue #12 When stake locked, restaked rewards become locked too:

There are only 2 states of the account with respect to locking: stake locked or unlocked. As this applies to the entire stake in a vault, it results in some undesirable/unnatural properties of the user journey. Probably the most problematic one is the fact that collected rewards (on locked stake) can be only restaked (in the same vault) if they also assume the existing lock time of the existing stake. Moreover, in the current implementation, they do not receive the lock bonus, only the 100% MP bonus that all staked SNT gets.

Possible solution One solution would be to redesign the contract and improve lock accounting - keeping track of locked stake amounts and time for fractions of total stake.

Alternatively, if this is too ambitious, we might decide to disable adding further stake if there is existing stake locked. However, this is bad UX as for a user who wants to maximalize rewards, each restaking and lock would equal deploying a new vault. That is not only a hinderance but also costly.

0x-r4bbit commented 8 months ago

@mart1n-xyz I remember I had a discussion with @3esmit about restaking and whether users should be able to add stakes to existing vaults or if adding stakes should always result in a new vault.

Can you leave your thoughts on this here so we can settle this with the correct implementation?

mart1n-xyz commented 8 months ago

I think our discussion ended at the point where we agreed that having users add stake is not worth the additional complexity. However, this has to be compensated by specific vault structure for restaking.

Specifically, one of the ideas was to have a special vault (in fact an AA wallet, covered in https://github.com/logos-co/staking/issues/34) where all rewards (from user's all vaults) are collected. Then if the user decides to restake, a new vault is deployed from there. Or if there is a withdrawal request, the cooldown applies and the withdrawal is processed.

The problem is that this does lead to a vault explosion over time. Hence there was a follow-up and inconclusive discussion whether we could enable vaults without lock to be merged to mitigate the number of vault instances. This is, nevertheless, the same as allowing adding stake.

0x-r4bbit commented 2 months ago

With the latest work done on MP estimation (#97) we no longer allow for adding stake to existing vaults. For new stake actions, new vaults will be created.