Skip to content
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

Lock and Stake _time parameter is confusing #79

Closed
3esmit opened this issue Mar 5, 2024 · 3 comments · Fixed by #84
Closed

Lock and Stake _time parameter is confusing #79

3esmit opened this issue Mar 5, 2024 · 3 comments · Fixed by #84

Comments

@3esmit
Copy link
Collaborator

3esmit commented Mar 5, 2024

_time parameters can be used differently, depending on how current account state is.

After refactor _time become relative.

  1. If account state is not initializated, or not locked, executes account.lockUntil = block.timestamp + _time.
  2. If account is locked, _time executes account.lockUntil += _time

For both, _mintIntialMP would use _time.

Previously before refactor (#63) _time was absolute, therefore account.lockUntil = _time, and checks were done to ensure this parameters was within boundries of block.timestamp, and _mintIntialMP would use deltaTime = _time - block.timestamp

@3esmit
Copy link
Collaborator Author

3esmit commented Mar 6, 2024

I changed to time be relative together with the initialization of accounts based on lockUntil.

Unlocked accounts basically are accounts that lockUntil the exact same time they deposit, so the _time for locking is the block.timestamp of the transaction that initialized the staking.

Therefore, if an account have a lockUntil == 0, this means this account is not initializated, because timestamp 0 is an invalid timestamp value, therefore this value was used to determine initialization of an account.

Previously the refactor, the _time was absolute, this means that the parameter was exact timestamp of lockUntil. and therefore the parameter could be considered _lockUntil. Or it could be zero, that would use _lockUntil as block.timestamp.

After the refactor, the amount of seconds to increase, relative from:

  • block.timestamp if blockUntil < block.timestamp;
  • else relative from blockUntil.

@3esmit
Copy link
Collaborator Author

3esmit commented Mar 6, 2024

I favour the use of relative time, because:

  • 0 means 0 time to increase, not a wildflag.
  • its easy to determine behavior:
    • users can't set exact input of account.blockUntil;
    • if a condition this, else this.
    • _time value set exact input of _mintInitialMP()

@0x-r4bbit
Copy link
Collaborator

There's a chance that changes done here are related to #80
@3esmit do you think we can get your _time related changes in?

If you confirm it's this commit introducing the necessary changes (c12d1ee), we can cherry-pick it.

@3esmit 3esmit mentioned this issue Mar 11, 2024
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants