Inside the general sell loop, when sellableTBC > userDeposited, the code correctly caps sellableTBC = userDeposited. However, line 358 then unconditionally executes positionWiseTBC[stage][i] = 0 and line 357 executes stageWiseUserTBC[stage][userOnPosition] -= remainingOnPosition, permanently deleting the full position regardless of how much was actually sold. Payment at lines 361–374 is made only for sellableTBC, while the difference remainingOnPosition - sellableTBC is erased from state with no compensation and no way to recover it. For example, if a user has a position of 1000 TBC with only 400 TBC deposited, the protocol pays for 400 and silently destroys the remaining 600 with no record, no refund, and no error message.

Function: __updateStageWiseSell — TBCDistributionPlan.sol The function contains two sequential loops. Loop 1 at lines 296–324 iterates over stageWiseUserPosition[stage][communitySeller] and enforces a hard cap of 20% of totalTBC via sellerSellLimit. Loop 2 at lines 340–395 iterates over the general positionWiseTBC[stage] array starting from stageWiseCurrentSellPosition[stage]. Since __updateStageWiseRecord adds all positions — including the communitySeller's — to the same positionWiseTBC[stage] array, the communitySeller's position indices appear in both data structures. If any of their indices fall within the Loop 2 scan window, Loop 2 processes their remaining balance again under the general 30% user quota with no check for ownership. Loop 1 may sell 20% from the communitySeller; Loop 2 then sells additional amounts from the same positions. The communitySeller can effectively capture up to 50% of each transaction, directly at the expense of legitimate FIFO-queue sellers.

The function iterates over old position indices i from start to end. At line 615, for valid (non-zero) positions, it records stageWiseUserPosition[stage][newBuyer].push(i) — the old contract index — while at line 616 it pushes data to the new positionWiseTBC[stage] array sequentially. If the old contract has any zero-address entries (skipped by the if(buyer != address(0)) guard at line 614), the new array gains fewer entries than the old index suggests. For example, with old positions [Alice, address(0), Bob]: Alice is added at new index 0 (records i=0, correct), the zero address is skipped, Bob is added at new index 1 but records i=2. When Loop 1 in __updateStageWiseSell later reads positionWiseTBC[stage][stageWiseUserPosition[stage][Bob][0]], it accesses index 2, but the new array only has indices 0 and 1 — an out-of-bounds revert in Solidity 0.8+. If Bob is ever used as communitySeller, every buyTBC call at that stage reverts permanently. The presence of if(buyer != address(0)) in the code confirms the developers anticipated zero-address entries but did not handle the index shift.

Every bonus function in the contract has a balance guard before paying except __referralBonusDistribution. At lines 422 and 434, it calls __transferTo(sponsor, reward) directly without checking IERC20(ausd).balanceOf(address(this)) >= reward, while __workingBonusDistribution at line 468 and __royaltyBonusDistribution at line 516 both check balance before transferring. When systemTBC is zero, the shortage mechanism at lines 329–332 redirects the system's 50% share obligation to user sellers (userSellLimit += shortage). At stage 0 where incentivePerStage[0] = 0, sellers receive 100% of TBC value in AUSD: sellerFund = (sellableTBC * 1e18) / 1e18 = sellableTBC AUSD. If user sellers cover the full totalTBC = packageAmount, they receive the entire packageAmount in AUSD, leaving the contract balance at zero. The subsequent call to __referralBonusDistribution at line 238 then calls safeTransfer with a zero-balance contract, reverting the entire buyTBC transaction. Since systemTBC naturally depletes as the protocol matures, this becomes a guaranteed failure condition on all stage-0 purchases.

The AUSD contract at AUSD.sol line 118 enforces notBlacklisted(receiver) on all transfers. Inside Loop 2 of __updateStageWiseSell, seller payments are made at lines 374 and 393 via __transferTo(userOnPosition, payableFund), which calls IERC20(ausd).safeTransfer(userOnPosition, sendAmount). If that seller has been AUSD-blacklisted — for any reason, whether regulatory, admin action, or compromised key — safeTransfer reverts. There is no try/catch wrapper. The revert propagates through __updateStageWiseSell and causes the entire buyTBC to fail. Critically, because the transaction reverts, stageWiseCurrentSellPosition[stage] is never advanced past the blacklisted position. Every subsequent buyTBC call hits the same position and reverts identically. With potentially thousands of sellers across the position array, any single blacklisted address creates a complete and unrecoverable purchase freeze.

The function has no access control and accepts a caller-specified topSponsor for each user. Reward tier is determined by the split between topSponsorSale and remainingTeamSale, which changes depending on which direct downline is chosen. At line 680, monthlySaleClaimed[user][month] = payableReward permanently marks the user as claimed, and line 652 prevents any re-claim with if (monthlySaleClaimed[user][month] != 0) continue. An attacker monitors the mempool for a user's optimal claim transaction (choosing the downline that maximizes the minimum of both legs for the highest tier) and front-runs with a transaction using a suboptimal direct downline of that user. The suboptimal split may qualify for the 5M/5M tier (400,000 AUSD) instead of the 10M/10M tier (1,000,000 AUSD). The 600,000 AUSD difference is irrecoverable — no admin function can reset monthlySaleClaimed, and no upgrade path exists without full redeployment. A bot can automate this attack against every eligible user every month at zero capital cost.