-
Notifications
You must be signed in to change notification settings - Fork 19
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
Add initial withdrawWindow calculations #35
Conversation
contracts/Pool.sol
Outdated
*/ | ||
function _setPoolLifeCycleState(IPoolLifeCycleState state) internal { | ||
if ( | ||
state == IPoolLifeCycleState.Active && _poolLifeCycleState != state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this check is enforcing that the timestamp is only ever set when the pool is activated
, should we name _poolLifeCycleStateTimestamp
to something more descriptive of that? Like _poolActivatedAt
or something like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah man must have been a rebase issue. it was going to set the timestamp based on any state change. Updated
_poolSettings.withdrawWindowDurationSeconds; | ||
} | ||
|
||
function nextWithdrawWindowIndex() external view returns (uint256) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this be used externally by lenders or frontends to time their claims? So they would take this value, and multiply it by the duration then + startTime basically?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we'd have another method to do that method directly, and this will become private since it's really an implementation detail.
_poolLifeCycleStateTimestamp = block.timestamp; | ||
} | ||
|
||
_poolLifeCycleState = state; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated to this PR really, but I wonder if this function should be the only one responsible for emitting the PoolLifeCycleTransition event (I think the PoolLib emits it right now, which felt strange to me).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thats a great point -- we should absolutely move it. Will do that.
|
||
function currentWithdrawWindowIndex() external view returns (uint256) { | ||
if (_poolLifeCycleState != IPoolLifeCycleState.Active) { | ||
return 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are there any unintended consequences of this if the pool is not active, but actually matured or faulted?
|
||
return | ||
(block.timestamp - _poolLifeCycleStateTimestamp) / | ||
_poolSettings.withdrawWindowDurationSeconds; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is user-configurable. Is it possible it's set to 0
?
withdrawWindowIndex
variable (0 when pool starts, 1 when the first window is open for withdrawals, 2 for second, etc).