The owner can set any arbitrary address as the wallet address (excluding the zero address). If the owner sets the wallet address to a contract that cannot receive tokens, it could lead to a potential honeypot scenario where funds become permanently locked. While the function validates against a zero address, it fails to verify if the target address is capable of receiving tokens. Add validation to ensure the wallet can only be set to an EOA (Externally Owned Account), preventing potential fund locks from incompatible contract addresses.

The contract contains two major flaws: first, the withdraw function uses unbounded loops that will grow in gas cost, leading to a permanent denial-of-service that locks all owner funds forever. Second, the promo code system is exploitable, allowing a bonus from a single, small purchase to be unfairly applied to all subsequent larger purchases within the same round, enabling users to drain unearned tokens.

The vulnerability originates in the getClaimableAmount function. While other functions like _applyPromoCode correctly limit a promo code's use to a user's single, initial purchase, the getClaimableAmount function fails to honor this restriction. When calculating the user's claimable tokens, its logic only checks if a userPromoCode has been set for the user, not which specific purchase it was applied to. As a result, it incorrectly calculates the bonus percentage on the user's total accumulated purchase amount for the round, rather than just the initial amount bought with the code. This allows any user to receive a significantly larger bonus than they are entitled to.The exploit can be performed in a simple sequence. First, with a round active that has a 10% user bonus, an attacker makes a small "bait" purchase of just 1 token using a valid promo code, which sets their userPromoCode on file. Then, in the same round, the attacker makes a much larger "real" purchase of 1,000,000 tokens without a code, bringing their total amountBought to 1,000,001. Finally, when the attacker calls claimTokens, the flawed getClaimableAmount function sees that a userPromoCode exists and incorrectly calculates the 10% bonus on the entire 1,000,001 token balance. This results in the attacker receiving 100,000.1 bonus tokens instead of the 0.1 they were actually entitled to.

The vulnerability is in the createRound function, where the number of vesting periods is calculated and then cast to a uint8. A uint8 can only hold a maximum value of 255. This creates a critical and immediate limitation, making it impossible to create any vesting schedule with more than 255 distinct release periods. This is not a theoretical long-term problem; it breaks the contract for very common, standard vesting schedules, such as daily releases over a single year. The contract is therefore unable to fulfill basic, real-world business requirements, forcing a choice between vesting frequency and total duration. A project wants to create a round with a standard 1-year daily vesting schedule. They call createRound with vestingDuration_ set to 365 days and vestingTimeUnit_ set to 1 days. The function calculates the number of periods as uint8(365 / 1), which overflows and becomes 109. If the project provides the corresponding array of 365 release percentages, the subsequent require check will fail because it expects the array length to be 109. The transaction reverts, making it impossible to create this round. The only way to support a year-long schedule is to use a large vestingTimeUnit (e.g., 30 days), which severely restricts claim frequency for investors.