-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
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:
|
I favour the use of relative time, because:
|
_time parameters can be used differently, depending on how current account state is.
After refactor _time become relative.
account.lockUntil = block.timestamp + _time
.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 usedeltaTime = _time - block.timestamp
The text was updated successfully, but these errors were encountered: