TempleGold

TempleDAO
Foundry
25,000 USDC
View results
Submission Details
Severity: medium
Invalid

[H-1] DaiGoldAuction::startAuction can be called repeatedly by anyone right after contract deployment, leading to tokens being stuck permanently.

[H-1] DaiGoldAuction::startAuction can be called repeatedly by anyone right after contract deployment, leading to tokens being stuck permanently.

Summary

The startAuction() function in DaiGoldAuction can be called repeatedly right after the contract deployment, leading to tokens being stuck permanently. This occurs due to a lack of proper validation checks on the initial state, allowing the function to bypass necessary cooldown periods and start auctions prematurely.

vulnerability Details

  • additionally the function lacks an important validation which should have prevented such from happening, for example in SpiceAuction::startAuction implemented this check that stops such from happening in SpiceAuction if (config.duration == 0) revert CannotStartAuction(); , but in DaiGoldAuction no similar validation was implemented allowing anyone to call the startAuction right after contract deployment.

Code Reference:

function startAuction() external override {
if (auctionStarter != address(0) && msg.sender != auctionStarter) { revert CommonEventsAndErrors.InvalidAccess(); }
EpochInfo storage prevAuctionInfo = epochs[_currentEpochId];
if (!prevAuctionInfo.hasEnded()) { revert CannotStartAuction(); }
AuctionConfig storage config = auctionConfig;
/// @notice last auction end time plus wait period
if (_currentEpochId > 0 && (prevAuctionInfo.endTime + config.auctionsTimeDiff > block.timestamp)) {
revert CannotStartAuction();
}
_distributeGold();
uint256 totalGoldAmount = nextAuctionGoldAmount;
nextAuctionGoldAmount = 0;
uint256 epochId = _currentEpochId = _currentEpochId + 1;
if (totalGoldAmount < config.auctionMinimumDistributedGold) { revert LowGoldDistributed(totalGoldAmount); }
EpochInfo storage info = epochs[epochId];
info.totalAuctionTokenAmount = totalGoldAmount;
uint128 startTime = info.startTime = uint128(block.timestamp) + config.auctionStartCooldown;
uint128 endTime = info.endTime = startTime + AUCTION_DURATION;
emit AuctionStarted(epochId, msg.sender, startTime, endTime, totalGoldAmount);
}

Description:

The startAuction() function does not adequately validate the initial state right after contract deployment, leading to the possibility of starting multiple auctions in quick succession. The function checks if the previous auction has ended , However, these checks can be bypassed right after deployment because the initial state does not have a previous auction, allowing anyone to call startAuction right after contract deployment

Impact:

Allowing repeated calls to startAuction() immediately after deployment can have severe consequences:

  • Token Lock-up: Tokens intended for distribution in auctions can become permanently stuck, as multiple auctions start without completing properly.

  • Contract Usability: The contract's functionality can be compromised, making it unreliable and potentially unusable for its intended purpose.

  • total disruption of contract functionality

Proof of Concept:

The lack of validation for the initial state allows repeated calls to startAuction() as demonstrated in the following scenario:

  1. Deploy the DaiGoldAuction contract.

  2. Call startAuction() repeatedly without waiting for the cooldown periods.

Recommended Mitigation:

To prevent repeated calls to startAuction() right after deployment, it is recommended to implement additional validation checks to handle the initial state appropriately. This can include setting up similar validation such as the one in SpiceAuction::startAuction

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

`startAuction` the second the DaiGoldAuction is deployed can be used to DOS the contract

Support

FAQs

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