The _initializeOwners() function at lines 118-130 lacks validation to prevent the same address from being added multiple times to the owners array. During deployment, if an address appears more than once in the _ownersList parameter, it will be added to the owners array multiple times without detection. While the isOwner mapping will only reflect true once, the array-based distribution logic in distributeETH() and distributeUSDT() iterates through the entire owners array and sends funds to each entry independently. This allows a duplicate owner to receive multiple payment shares during revenue distribution. For example, if Alice is added twice among three total entries, she receives two-thirds of the owner allocation instead of one-third, effectively stealing funds from other legitimate stakeholders. The issue persists throughout the contract's lifetime as the owners array is immutable after deployment.

The contract's sale phase logic creates an unintended lockout period when the presale sells out before the TGE date arrives. The isPresaleActive() function at line 167 requires both block.timestamp < TGEStart AND totalPresaleSold < PRESALE_SUPPLY to return true, while isTreasuryActive() at line 171 requires block.timestamp >= TGEStart. If the presale reaches its 2,000,000 token limit before the scheduled TGE date, both functions return false simultaneously, causing _checkSaleActive() to revert all purchase attempts. For example, if the presale sells out on January 15 but TGE is scheduled for January 31, there is a 16-day blackout period where buyers cannot purchase tokens despite 6,000,000 treasury tokens being available. The contract holds tokens ready for sale but the phase transition logic prevents any transactions, resulting in lost revenue, frustrated users, wasted marketing expenditure, and potential reputation damage as buyers encounter repeated transaction failures without understanding why.

The distributeETH() and distributeUSDT() functions at lines 433-454 and 456-476 implement a push payment pattern where funds are sent directly to each owner and the marketing wallet within a loop. Both functions use require() statements to validate transfer success, creating a single point of failure where any recipient's inability to receive funds causes the entire transaction to revert. If any owner address is a contract without a receive() or fallback() function, or contains logic that intentionally or accidentally rejects transfers, all distribution attempts will fail permanently. This can occur through malicious intent (an attacker deploying a rejecting contract and getting added as an owner), accidental misconfiguration (using a multisig or contract address that doesn't accept direct transfers), or contract upgrades that change receiving behavior. Once triggered, there is no recovery mechanism - the contract provides no functions to remove problematic owners, skip failed transfers, or implement emergency withdrawals. All collected ETH and USDT remains trapped in the contract indefinitely, affecting not just the problematic recipient but all legitimate owners and the marketing wallet, despite their addresses functioning correctly. The vulnerability is particularly critical given the potential funds at stake: with a $7M token sale generating substantial ETH/USDT holdings, a single misconfigured address can cause total permanent loss of all revenue.