[L-01] TempleGold will be DoS-ed if the chainId changes

Summary

TempleGold minting can happen only on the chain with the given mintChainId. Since, there is no way to change this variable, if the chainId of the chain changes, the contract will no longer be usable.

Vulnerability Details

It's possible that a chainId gets changed because of chain reorgs or some other event.

Impact

If this happens, no mints will be executable.

Tools Used

Manual Review

[L-02] GnosisTeam will receive tokens even if params.gnosis == 0

Summary

According to the known issues

In Temple Gold contract, setDistributionParams() can be executed with 0 value for a parameter eg. params.gnosis - This is intentional to freely distribute minted TGLD to staking and dai gold auction only.

This is not entirely true.

Vulnerability Details

Because of rounding down, there will be some dust amount minted to the gnosis team even if their parameter's value is set to 0.

Impact

Increase in the balance of the gnosis team.

Tools Used

Manual Review

Recommendations

Document this behavior.

Recommendations

Add a function to manage the chainId.

[L-03] Gold dust amount cannot be rescued

Summary

DaiGoldAuction.sol dust amounts can never be claimed.

Vulnerability Details

The contract accumulates dust amounts over time because when a claim happens, the math will round it down. These dust amounts will be forever locked in the contract since the recover functionality allows withdrawing tokens for distribution that has not started.

Impact

Loss of funds

Tools Used

Manual Review

Recommendations

Consider if you wish to add a functionality that allows you to pull the dust amounts.

[!CAUTION]
Adding such functionality may introduce centralization issues

[L-04] DaiGoldAuction.isCurrentEpochEnded returns wrong value

Summary

DaiGoldAuction.isCurrentEpochEnded() returns true for not started epochs.

Vulnerability Details

The result of the function call is

This is not efficient for epochs that have either not been started yet or had their tokens claimed.

As we can see, a position with startTime = endTime = 0 will return true as if it has ended.

Impact

Wrong return value

Tools Used

Manual Review

Recommendations

[L-05] Wrong event emission

Summary

An event is emitted with a wrong value.

Vulnerability Details

The second parameter of the AuctionConfigRemoved event is epochId.

In removeAuctionConfig this value is always hardcoded to 0 instead of using the correct epochId.

Impact

Wrong value will be emitted.

Tools Used

Manual Review

Recommendations

[L-06] Discrepancy betweensetAuctionConfig and startAuction

Summary

There is a discrepancy about the minimumDistributedAuctionToken between the two functions.

Vulnerability Details

If we look startAuction, we can see that minimumDistributedAuctionToken is enforced only when activationMode == AUCTION_TOKEN_BALANCE.

However, setAuctionConfig reverts if the minimum is not set regardless of the activation mode. This means the check is redundant and one of the following is true:

• the minimum should be always enforced

• the minimum should be enforced only when activationMode == AUCTION_TOKEN_BALANCE and the code currently doesn't allow that.

Impact

Ambiguity about the minimumDistributedAuctionToken

Tools Used

Manual Review

Recommendations

Remove the redundant check and modify setAuctionConfig if needed.

[L-07] Setting an auction config is not possible if the previous epoch is active

Summary

SpiceAuction.setAuctionConfig()cannot set the config for an epoch if the previous one is active.

Vulnerability Details

The code tries to prevent the DAO from setting a config for an active epoch. In order to do that, it introduced the following check:

However, the info variable is about the current epoch, but setAuctionConfig always sets the config of the next epoch.

Impact

The wrong check disallows setting config for an auction when the previous auction has not ended.

Tools Used

Manual Review

Recommendations

Remove the whole if check.