When NFT boost is activated, _updateUserRewards() sets userRewardPerTokenPaid = rewardPerTokenAtEpochStart, then _updateNFTMultiplier() increases effectiveAmount by 50% WITHOUT adjusting userRewardPerTokenPaid. The extra effective stake earns retroactively from epoch start rather than activation time. In contrast, stake() correctly applies a weighted RPT average on line 768 when adding new effective stake. This inconsistency means NFT registration on day 4 of 7 credits the extra 500K effective for all 7 days instead of 3 remaining days. Example: 1M OVPP user registering NFT on day 4 overpays ~21,430 OVPP, diluting other stakers.

Transfers the contract's entire OVPP balance to EMISSIONS_MANAGER with no precondition checks on outstanding user obligations. The balance includes staker principal (totalStaked), accrued rewards (totalAccruedUnclaimed), and in-flight unbonding amounts. The intended flow (terminate → massWithdraw → claimRemainings → collectFunds) is not enforced. Admin can drain all user funds immediately after termination. Example: Alice has 1,000,000 OVPP staked. Admin terminates, calls collectFunds(). Alice's subsequent unbond() reverts with insufficient balance.

When a user fully withdraws their stake by calling unbond() with an amount equal to their entire staked balance, the function correctly reduces stakes[msg.sender].amount and stakes[msg.sender].effectiveAmount to zero, decrements the global totalStaked and totalEffectiveStaked counters, and creates an unbonding request. However, it does not reset the user's userStartEpoch, totalClaimedByUser, lastUpdateEpoch, or hasNFT fields. This stands in direct contrast to the _fullExitUser() function (lines 619–660), which is invoked only during post-termination exits and properly resets all of these fields via delete stakes[user], userStartEpoch[user] = 0, and totalClaimedByUser[user] = 0. The consequence is that when a user who originally staked in epoch 1 fully unbonds in epoch 5 and later re-stakes in epoch 50, the cumulative reward cap computed by _getCumulativeCap() at line 838 uses the stale userStartEpoch of 1, calculating epochsCount = 50 - 1 + 1 = 50. A fresh staker entering at epoch 50 would have epochsCount = 1. This gives the returning staker a cap that is 50 times larger than intended, effectively removing the 100%-per-epoch reward ceiling that is designed to prevent over-extraction. This issue directly amplifies the Critical finding C-01 (returning staker stale RPT baseline), because the inflated cap removes the last safety net that could have otherwise limited the amount of retroactive rewards the attacker can claim per cycle.

The contract tracks a user's initial deposit using principalAmount to prevent compounded rewards from inflating their geometric reward cap. However, the unbond() function blindly subtracts the total withdrawal amount from both the total amount and the principalAmount. If a user attempts to fully withdraw after compounding rewards, this causes a fatal arithmetic underflow. For example, a user stakes 1,000 OVPP (principal = 1,000) and compounds 50 OVPP in rewards (total = 1,050). If they call unbond(1050) to exit, the contract attempts to subtract 1,050 from their 1,000 principal. This reverts the transaction, permanently trapping the 50 OVPP of compounded rewards inside the protocol.

In the _advanceEpoch function, when advancing to the next epoch, the contract deducts the required rewards for both staking and points from the totalPool. If totalPool reaches exactly 0 after this deduction, the code enters an if (totalPool == 0) block. Inside this block, the contract state is set to Terminated and it emits an EpochStarted event for storedEpoch + 1, but it immediately returns without actually updating the storedEpoch variable to nextEpoch. For example, assume the current storedEpoch is 5. The admin advances to epoch 6. The funds for epoch 6 are successfully deducted from totalPool, dropping it to exactly 0. The program terminates and returns early. The storedEpoch remains stuck at 5. However, epochConfigs[6].pointsRewardsAmount has already been funded and recorded. When the admin later calls batchDistributePointsRewards(6), the function checks if (!(epoch < storedEpoch || (storedEpoch == epoch && programState == ProgramState.Terminated))). Since storedEpoch is still 5, checking epoch 6 results in (6 < 5) which is false, and (5 == 6) which is false. The transaction reverts permanently with PointsDistributionEpochNotAllowed(6). The allocated points funds are locked in the contract forever.

The collectFunds function guards against sweeping funds that are still owed to users by checking that totalAccruedUnclaimed, totalStaked, stakers.length, totalPointsLeftover, and totalStakingCapSurplus are all zero. However, the new lockedCurrentEpochRewards field is intentionally not tracked in totalAccruedUnclaimed — the locking system is designed as a two-phase mechanism where rewards are held in lockedCurrentEpochRewards first, then promoted to rewardsEarned (and totalAccruedUnclaimed) only when released via _releaseLockedCurrentEpochRewards. Because the promotion never happens in the path described in Issue 1, the 50 OVPP owed to Alice exists physically in the contract but is invisible to every accounting variable that collectFunds checks. After massWithdrawUsers incorrectly removes Alice from stakers, all five guards in collectFunds pass cleanly and the admin transfers the full contract balance — which includes Alice's 50 OVPP — to themselves. When Alice subsequently calls claimRewards, the contract correctly releases her locked rewards to rewardsEarned and increments totalAccruedUnclaimed by 50, but then attempts a safeTransfer against a zero contract balance, causing a permanent revert. Alice's tokens are irrecoverably lost.