As far as I understand from personal correspondence with the protocol team, the following is assumed to be invariant
Work.opensAt < work.closesAt. However, the protocol does not validate this in any way when creating a work, nor when changing the timeFrame in the Edition.sol::setTimeFrame function
Thus, the invariant can easily be violated by the user, intentionally or unintentionally
Vulnerability Detail
When a new job is created or the creator wants to change the timeFrame, work.opensAt and work.closesAt are not validated in any way
function setTimeframe(uint256 tokenId, uint64 opensAt, uint64 closesAt) external {
Work storage work = works[tokenId];
if (msg.sender != work.creator) revert Unauthorised();
// Update the open and close times for the work
work.opensAt = opensAt;
work.closesAt = closesAt;
emit TimeframeUpdated(address(this), tokenId, opensAt, closesAt);
}
Impact
Since the Readme says to report broken invariants, I included it in the bug, especially in combination with the issue described here Title: The work creator can manipulate FeeSize using front-running, it gives even more power to work.creator
For example, it can easily turn off mint for a certain interval, just by changing the timeFrame once, making opensAt > closesAt, checkTime will revert the transaction exactly at the interval (closesAt, opensAt)
BengalCatBalu
medium
Broken Assumtion of timeFrame behaviour
Summary
As far as I understand from personal correspondence with the protocol team, the following is assumed to be invariant
Work.opensAt < work.closesAt
. However, the protocol does not validate this in any way when creating a work, nor when changing the timeFrame in theEdition.sol::setTimeFrame
functionThus, the invariant can easily be violated by the user, intentionally or unintentionally
Vulnerability Detail
When a new job is created or the creator wants to change the timeFrame, work.opensAt and work.closesAt are not validated in any way
Creating a job
timeFrame change
Impact
Since the Readme says to report broken invariants, I included it in the bug, especially in combination with the issue described here Title:
The work creator can manipulate FeeSize using front-running
, it gives even more power to work.creatorFor example, it can easily turn off mint for a certain interval, just by changing the timeFrame once, making opensAt > closesAt, checkTime will revert the transaction exactly at the interval (closesAt, opensAt)
Code Snippet
Tool used
Manual Review
Recommendation
Check the invariant when assigning time