# Functions cancelMinipool() doesn't reset the value of the RewardsStartTime for user when user's minipoolcount is zero

cancelMinipool() fails to reset RewardsStartTime when minipoolCount hits zero, letting node runners claim GGP rewards without running a node the required duration.

- Payout: Contest reward
- Severity: medium
- Program: GoGoPool
- Credited: unforgiven
- Disclosed: 2023-03-21
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-12-gogopool-findings/issues/555
- Library page: https://bugbountylibrary.com/r/c4%3A2022-12-gogopool%3AM-10
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** MinipoolManager.sol cancelMinipool / _cancelMinipoolAndReturnFunds
**Root cause:** cancelMinipool decreases minipool count but never resets the node runner's RewardsStartTime, so eligibility tracking retains the original start time even after all minipools are cancelled.
**Steps:**
1. Create a minipool near the start of the GGP reward cycle; RewardsStartTime is set for the node runner.
2. After the cancel moratorium (~5 days) with the minipool not launched, call `cancelMinipool(nodeID)`; minipoolCount decreases but RewardsStartTime is unchanged.
3. Wait ~20 days, then near cycle end create another minipool and run the node briefly.
4. At cycle end `ClaimNodeOp.isEligible()` returns true based on the stale RewardsStartTime, granting GGP rewards for time not actually validating.
**How found:** Code review of cancelMinipool/_cancelMinipoolAndReturnFunds noting decreaseMinipoolCount without any RewardsStartTime reset, then tracing how ClaimNodeOp.isEligible consumes RewardsStartTime.
**Exploitation:** Node runner registers a minipool early to stamp RewardsStartTime, cancels it after the moratorium to recover funds, then re-registers near cycle end; eligibility check uses the stale timestamp so rewards are paid despite minimal actual uptime.
**Insight:** When a counter gates a timestamp-based eligibility check, audit every decrement path (cancel, slash, withdraw) for a matching reset of the timestamp; stale start times are a common reward-gaming vector in staking protocols.