# [M-01] Allocation can start before registration ends. Which can break things in strategies.

Allocation can start before registration ends, allowing a recipient to re-register and become pending, locking their allocated funds permanently.

- Payout: Contest reward
- Severity: medium
- Program: Gitcoin
- Credited: 0xkaden
- Disclosed: 2023-09-01
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-09-Gitcoin-judging/issues/751
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-09-Gitcoin%3AM-14
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:business-logic

**Target:** QVBaseStrategy and DonationVotingMerkleDistributionBaseStrategy contracts
**Root cause:** Timestamp validation allows allocationStartTime < registrationEndTime, so registration remains active during allocation. A recipient can re-register after receiving allocation, resetting status to pending; if registration ends before re-review, distribution reverts and funds are stuck.
**Steps:**
1. Recipient registers and is accepted during registration period.
2. Allocation starts while registration is still active (allowed by timestamp check).
3. Recipient receives allocation (credits) during allocation period.
4. Recipient calls `registerRecipient` again near end of registration period, resetting status to pending.
5. Registration period ends before `reviewRecipients` can re-approve the recipient.
6. Distribution attempts to pay the recipient but reverts because status is not accepted; allocated share of `poolAmount` is permanently locked.
**How found:** The auditor noticed that the timestamp validation check allows `allocationStartTime` to be less than `registrationEndTime`, meaning allocation can start before registration ends. They then reasoned that a recipient could re-register during allocation, changing their status and potentially causing distribution to fail.
**Exploitation:** A recipient (or anyone controlling a recipient address) re-registers during the overlap of registration and allocation periods after having received allocation. This resets their status to pending. If the registration period ends before the pool manager re-reviews them, the distribution function reverts for that recipient, and their allocated funds remain locked in the contract with no withdrawal path.
**Insight:** When auditing time-based state machines, check for overlapping phases that allow state transitions (like re-registration) after funds have been allocated. A recipient re-registering can reset their status, and if the review window closes before re-approval, funds become stuck. Look for functions gated by `onlyActiveRegistration` that can be called during allocation.