Missing max reward allocation check enables exceeding 10 percent token supply limit

The StakingContract allows the owner to fund rewards without any limit through the fundRewards function:

function fundRewards(uint256 amount) external onlyOwner {
    require(amount > 0, "Amount must be greater than zero");
    stakingToken.safeTransferFrom(msg.sender, address(this), amount);
    emit RewardsFunded(msg.sender, amount);
}

According to the protocol's tokenomics (shown in README.md), only 10 percent of the total supply should be allocated for rewards. However, there is no on-chain enforcement of this limit, which could lead to overfunding beyond the intended allocation.

If the protocol becomes successful and active for a long period:

• Owner could accidentally fund more than 10 percent of total supply.
• This breaks the tokenomics promises made to users and investors.
• Excessive rewards dilute token value.
• Could affect other token allocations (team, partnerships, etc.).

Import OpenZeppelin's Pausable, add MAX_REWARD_ALLOCATION and totalRewardsFunded state variables, expose pause/unpause, and modify fundRewards to enforce the 10 percent limit:

function fundRewards(uint256 amount) external onlyOwner {
    require(amount > 0, "Amount must be greater than zero");

    uint256 maxRewards = (stakingToken.totalSupply() * MAX_REWARD_ALLOCATION) / 100;
    require(totalRewardsFunded + amount <= maxRewards,
        "Exceeds max reward allocation");

    totalRewardsFunded += amount;
    stakingToken.safeTransferFrom(msg.sender, address(this), amount);

    if (totalRewardsFunded >= maxRewards) {
        _pause();
    }

    emit RewardsFunded(msg.sender, amount);
}

Add whenNotPaused to stakeTokens. The protocol then never exceeds its promised 10 percent reward allocation; staking is automatically paused if the maximum allocation is reached; the owner has explicit control over pausing and unpausing through dedicated functions.

Ample Protocol: Fixed.

Zealynx: A new issue (F-2025-0005) was raised because the mitigation was not followed exactly as proposed. Update: fixed and verified.