Eggstravaganza

First Flight #37
Beginner FriendlySolidity
100 EXP
View results
Submission Details
Severity: low
Invalid

Unreachable code path in getGameStatus function

Summary

In the EggHuntGame contract, the getGameStatus function contains unreachable code due to logical contradictions between the game initialization in startGame and the status checks in getGameStatus. When a game is started, startTime is set to the current timestamp, making it impossible for the condition block.timestamp < startTime to ever be true while gameActive is true.

Vulnerability Details

The issue exists in the following code:

function getGameStatus() external view returns (string memory) {
if (gameActive) {
if (block.timestamp < startTime) {
return "Game not started yet"; // This branch is unreachable
} else if (block.timestamp >= startTime && block.timestamp <= endTime) {
return "Game is active";
} else {
return "Game time elapsed";
}
} else {
return "Game is not active";
}
}

This unreachable condition occurs because of how the game is initialized in the startGame function:

function startGame(uint256 duration) external onlyOwner {
require(!gameActive, "Game already active");
require(duration >= MIN_GAME_DURATION, "Duration too short");
startTime = block.timestamp; // startTime is set to the current time
endTime = block.timestamp + duration;
gameActive = true;
emit GameStarted(startTime, endTime);
}

When startGame is called, startTime is set to the current timestamp (block.timestamp), and gameActive is set to true. This means that once the game is active, it's impossible for block.timestamp to be less than startTime because:

  1. startTime is set to block.timestamp at the moment of game activation

  2. block.timestamp can only increase in subsequent blocks

  3. Therefore, block.timestamp < startTime will always be false once gameActive is true

Impact

This is a low-severity issue that does not pose a security risk, but it indicates a logical flaw in the contract design that could cause confusion for developers or users interacting with the contract. Specifically:

  1. It represents dead code that will never be executed

  2. It could cause confusion when reading or maintaining the code

  3. It might lead to incorrect assumptions about the game state transitions

  4. Gas is wasted on code evaluation that can never be reached

Tools Used

  • Manual code review

  • Logical flow analysis

Recommendations

Option 1: Remove the unreachable code

Option 2: Allow scheduled future games

Updates

Lead Judging Commences

m3dython Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Out of scope
Assigned finding tags:

Gas optimization

Strategy to save gas and minimize transaction costs

Support

FAQs

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