https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/linkStaking/FundFlowController.sol#L32
https://docs.stake.link/link-staking-contracts/fundflowcontroller#timeoflastupdatebygroup
The timeOfLastUpdateByGroup
variable within the FundFlowController
contract is expected to store timestamps for the last updates of individual vault groups. However, a discrepancy was discovered between the code implementation and the official documentation. The documentation describes timeOfLastUpdateByGroup as a uint64 value. This implies that each timestamp is stored as a single 64-bit unsigned integer, sufficient to represent Unix timestamps. The actual implementation uses a uint256[]
array, meaning that each vault group stores its timestamp as a 256-bit unsigned integer, with multiple timestamps recorded. This difference increases storage size and alters how the data is read or written.
Systems relying on the documented type may be configured to handle uint64 values. If the on-chain data is read as a uint256 array, it could lead to decoding errors, incorrect timestamp interpretations, or reverts in API queries. When the frontend or off-chain services query these timestamps, the returned data format might differ from expectations, potentially breaking functionality or displaying incorrect information.
Systems expecting uint64 timestamps may encounter issues when interacting with this contract, resulting in failed or delayed operations. Unnecessarily using uint256 increases gas consumption during operations involving timestamps. Any frontend or contract relying on the uint64 format for this variable might encounter reverts when the actual data structure differs.
Manual Review
Modify the type of timeOfLastUpdateByGroup from uint256[]
to uint64[]
to match the documentation and reduce storage size. This change will align the implementation with the documentation while also saving gas.
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.