TempleGold

Summary

The TempleGoldStaking contract implements a centralized reward distribution mechanism that relies on a single distributionStarter address or allows unrestricted access if set to zero. This design introduces a significant centralization risk that could potentially disrupt the reward distribution process, affecting all stakers in the system.

Vulnerability Details

The distributeRewards() function, which is crucial for distributing rewards to stakers, is gated by the distributionStarter address:

https://github.com/Cyfrin/2024-07-templegold/blob/57a3e597e9199f9e9e0c26aab2123332eb19cc28/protocol/contracts/templegold/TempleGoldStaking.sol#L180-L193

https://github.com/Cyfrin/2024-07-templegold/blob/57a3e597e9199f9e9e0c26aab2123332eb19cc28/protocol/contracts/templegold/TempleGoldStaking.sol#L125-L129

https://github.com/Cyfrin/2024-07-templegold/blob/57a3e597e9199f9e9e0c26aab2123332eb19cc28/protocol/contracts/templegold/TempleGoldStaking.sol#L152-L156

The distributionStarter can be set by an elevated access role:

This creates two problematic scenarios:

1. If distributionStarter is a non-zero address, only that address can distribute rewards.

2. If distributionStarter is set to address(0), anyone can call distributeRewards().

Additionally, the rewardDistributionCoolDown adds another layer of centralized control over the frequency of distributions.

Impact

The centralization in the reward distribution mechanism could lead to several high-impact issues:

1. Single Point of Failure: If the distributionStarter becomes unavailable or compromised, reward distribution could be halted indefinitely.

2. Manipulation: A malicious distributionStarter could manipulate distribution timing for personal gain.

3. Inconsistent Rewards: In the case where anyone can distribute (address(0)), uncoordinated or malicious distributions could lead to unfair reward allocation.

These issues could potentially affect all stakers in the system, disrupting the core functionality of the staking contract.

Tools Used

Manual review

Recommendations

1. Implement a decentralized governance mechanism for reward distribution, such as a multi-signature wallet or DAO.

2. Add a fallback mechanism that allows anyone to trigger distribution if it hasn't occurred within a set timeframe.

3. Implement time-locks on critical functions like setDistributionStarter to provide transparency and allow users to react to changes.

4. If maintaining a distributionStarter role, implement a 2-of-3 multisig or similar setup to reduce single point of failure risks.