Beatland Festival
AI First Flight #4
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Impact: low
Likelihood: low
Invalid

The createPerformance() function enforces a strict check that the performance startTime must be **in the future**:

hark017

Description

The createPerformance() function enforces a strict check that the performance startTime must be in the future:

solidity

require(startTime > block.timestamp, "Start time must be in the future");

This prevents the organizer from scheduling a performance that starts immediately (i.e., in the same block as the transaction that creates it).

While the intention is likely to avoid accidental "past" performances, this restriction is overly strict and reduces flexibility. In real-world festival scenarios, organizers may want to create and activate a performance right now — for example:

  • Starting an impromptu set or surprise performance

  • Fixing a missed performance by creating one that begins immediately

  • Testing or demo purposes during deployment

Allowing startTime >= block.timestamp would enable immediate starts without compromising security or logic.

Impact

  • Low severity: No security vulnerability, no funds at risk, no incorrect reward calculation.

  • Reduced flexibility for the organizer (onlyOrganizer-gated function).

  • Poor user experience in legitimate edge cases where immediate activation is desired.

  • Forces organizer to wait at least one block (typically 2–12 seconds) before a performance can begin, which can be operationally inconvenient.

Falls under Low / QA per CodeHawks severity classification.

Proof of Concept

The following Foundry test demonstrates the current restrictive behavior:

solidity

function test_CreatePerformanceCannotStartNow() public {
vm.prank(organizer);
​
vm.expectRevert("Start time must be in the future");
festival.createPerformance(
block.timestamp, // exactly now
2 hours,
10 ether
);
}

This test passes — showing that even setting startTime to the current block timestamp causes reversion.

If the check were changed to >=, the above call would succeed and the performance would be active immediately.

Recommended Mitigation

Change the strict inequality to allow starting in the current block:

solidity

require(startTime >= block.timestamp, "Start time must not be in the past");

Updated function snippet:

solidity

function createPerformance(
uint256 startTime,
uint256 duration,
uint256 reward
) external onlyOrganizer returns (uint256) {
require(startTime >= block.timestamp, "Start time must not be in the past");
require(duration > 0, "Duration must be greater than 0");
​
performances[performanceCount] = Performance({
startTime: startTime,
endTime: startTime + duration,
baseReward: reward
});
emit PerformanceCreated(performanceCount, startTime, startTime + duration);
return performanceCount++;
}

This change:

  • Prevents past performances (still safe)

  • Allows immediate activation when needed

  • Improves operational flexibility

  • Has negligible gas impact

  • Aligns with common patterns in event/ticketing contracts

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 4 hours ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!