59115 sc low periodattimestamp function is incorrectly implemented and always returns period at current timestamp
Submitted on Nov 8th 2025 at 21:28:28 UTC by @Tadev for Audit Comp | Firelight
Report ID: #59115
Report Type: Smart Contract
Report severity: Low
Target: https://github.com/firelight-protocol/firelight-core/blob/main/contracts/FirelightVault.sol
Impacts:
Contract fails to deliver promised returns, but doesn't lose value
Description
Brief/Intro
As per the documentation, the periodAtTimestamp function is supposed to return the period number for the timestamp given. This function is defined as follows:
function periodAtTimestamp(uint48 timestamp) public view returns (uint256) {
PeriodConfiguration memory periodConfiguration = periodConfigurationAtTimestamp(timestamp);
// solhint-disable-next-line max-line-length
return periodConfiguration.startingPeriod + _sinceEpoch(periodConfiguration.epoch) / periodConfiguration.duration;
}The problem is that the current implementation is incorrect, always returning the period at the current timestamp.
Vulnerability Details
The periodAtTimestamp function fetches the periodConfiguration of the provided timestamp. After that, it computes:
The problem lies in _sinceEpoch internal function, which doesn't use the provided timestamp but block.timestamp instead:
This means the periodAtTimestamp function will return current period instead of period at given timestamp.
Impact Details
The impact of this issue is low as it consists of a logical error in periodAtTimestamp function. Anyone querying this function to know the period of a given timestamp will get a wrong result.
The impact is limited in the protocol itself because periodAtTimestamp function is used internally only in currentPeriod function, and the timestamp provided is the current block timestamp.
Proof of Concept
Proof of Concept
Please create a poc.js file in the test folder and copy paste the following code:
The output of this test is:
This tests highlights that when querying the period at a given timestamp in the future, the function doesn't return the correct result. This issue is the same when querying with a timestamp that is in the past.
Was this helpful?