The distributeRewards function contains a critical design flaw that exposes it to a Denial of Service (DoS) attack. The function is designed to distribute stablecoin rewards to all eligible token holders by iterating through the entire holders array within a single transaction. While this works for a small number of holders, the gas cost of the transaction grows linearly with the size of the array. As the token gains popularity and the number of holders increases to thousands or tens of thousands, the gas required to execute the function will inevitably exceed the blockchain's block gas limit. For example, if the holders array grows to 50,000 addresses, the loop would consume an enormous amount of gas, making any transaction calling this function fail. At this point, it would become permanently impossible to distribute rewards using this method, effectively freezing the reward mechanism and breaking a core promise of the token.

The reward distribution mechanism is critically flawed in two ways, leading to incorrect and unfair payouts. Firstly, the reward calculation in both distributeRewards and distributeRewardsBatch incorrectly uses the token's totalSupply() as the denominator. This significantly dilutes payouts because it includes tokens from reward-excluded addresses (like the treasury), causing a large portion of the reward pool to go undistributed. For example, if the reward pool is 1,000 USDC and eligible holders collectively own only 10% of the totalSupply, the current formula will only distribute 100 USDC in total, leaving 900 USDC locked in the contract instead of being paid out to the community. Secondly, the distributeRewardsBatch function is unfair because it reads the live stablecoin balance for each batch. This means holders processed earlier are paid from a larger pool than those in later batches, so two holders with identical token amounts will receive different rewards simply based on batch order.

The contract owner possesses the centralized capability to halt all token transfers by invoking the pauseTransfers() function. This action sets the transfersPaused boolean flag to true. The internal _transfer function enforces this state, reverting any transaction if transfersPaused is true. An exception is made for addresses that are excluded from tax, which includes the contract owner and the treasury wallet. This allows privileged addresses to continue transacting while all other holders' assets are effectively frozen. While a corresponding resumeTransfers() function exists, its execution is also exclusively controlled by the owner. This creates a single point of failure and a significant centralization risk. A compromised or malicious owner could abuse this functionality to manipulate the market or lock up user funds indefinitely.