If the protocol changes the lockTime
, it should only apply to new deposits and not affect existing ones. If the lock period is extended, users might be forced to keep their funds locked for a longer time than originally expected, preventing planned timely withdrawals during losses or profits. Conversely, if the lock period is shortened, early withdrawals from older deposits could disrupt trading strategies, leading to forced liquidations or premature position closures.
Extended Lock Period: Users unable to withdraw during desired periods, potentially leading to forced losses or reduced profits.
Reduced Lock Period: Unplanned withdrawals might disrupt vault strategies, causing position liquidations or premature position closures.
Implement logic to ensure lockTime
changes only apply to future deposits.
add a uint256 lockTime
variable to the DepositInfo
struct
and check for lock durations using each deposits respective lockTime and not the global parameter.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
Likelihood: Low, when admin changes lockTime setting. Impact: Informational/Low, it will change the lockTime for previous depositors, forcing them to wait longer than expected or allowing them to withdraw earlier. This is indeed a strange implementation and is not specified in the documentation. It deserves a low.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.