Core Contracts

Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Submission Details
Severity: low
Invalid

Inconsistent Constant Naming for Timelock Delay in Address Update Function

Summary

The contract uses a constant named TREASURY_UPDATE_DELAY to set the timelock delay for both treasury and repair fund address updates. This inconsistent naming can lead to confusion about whether the same delay should apply to both functions or if a separate constant should be used for repair fund updates.

Vulnerability Details

In the setTreasury function, the effective time for a treasury address update is set using the constant TREASURY_UPDATE_DELAY:

pendingTreasury = PendingUpdate({
newAddress: newTreasury,
effectiveTime: block.timestamp + TREASURY_UPDATE_DELAY
});

In the setRepairFund function, the same constant (TREASURY_UPDATE_DELAY) is used despite the function relating to a different parameter (the repair fund address):

pendingRepairFund = PendingUpdate({
newAddress: newRepairFund,
effectiveTime: block.timestamp + TREASURY_UPDATE_DELAY
});

Using TREASURY_UPDATE_DELAY in the repair fund update function is inconsistent. This raises questions about whether a distinct constant (e.g., REPAIR_FUND_UPDATE_DELAY) was intended for repair fund address updates, or if the naming should be unified under a more generic constant (such as UPDATE_DELAY) if the same delay applies to both cases.

Impact

  • Developer Confusion: The inconsistent naming might lead to misunderstanding about the timelock configuration, causing developers or auditors to assume that different delays might be applied to treasury and repair fund updates.

  • Configuration Risk: If the intention was to have different update delays for treasury and repair fund address changes, using the same constant could lead to unintended behavior. This may limit flexibility in managing the protocol’s funds.

  • Maintenance Issues: Future changes to the timelock delay may inadvertently affect both parameters if the constant is modified, which might not be the desired outcome if the delays are meant to differ.

Tools Used

  • Manual code review

Recommended Mitigation

  1. Rename the Constant: If different delays are intended for treasury and repair fund updates, define a separate constant for the repair fund (e.g., REPAIR_FUND_UPDATE_DELAY) and use it in the setRepairFund function.

  2. Generalize the Naming: If the same delay is indeed intended for both, rename the constant to a more generic name (e.g., UPDATE_DELAY) to accurately reflect its use in updating any fund address.

Updates

Lead Judging Commences

inallhonesty Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
inallhonesty Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

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