# Prime.sol - User can claim Prime token without having any staked XVS, because his stakedAt isn't reset whenever he is issued an irrevocable token

Prime.issue() fails to reset stakedAt when minting an irrevocable token, letting a user later claim a revocable Prime token with zero XVS staked.

- Payout: Contest reward
- Severity: high
- Program: Venus Protocol
- Credited: deth
- Disclosed: 2023-11-29
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-09-venus-findings/issues/633
- Library page: https://bugbountylibrary.com/r/c4%3A2023-09-venus%3AH-01
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:high tech:solidity technique:incomplete-fix technique:source-review vuln:access-control vuln:business-logic

**Target:** Prime.sol staking/claim contract
**Root cause:** issue() resets stakedAt only in the revocable branch; the irrevocable mint path leaves the original stakedAt intact, so eligibility state survives token burn.
**Steps:**
1. Deposit 10k XVS via xvsVault.deposit; stakedAt set to now, 90-day period not elapsed.
2. Admin calls `prime.issue(true, [user])` minting an irrevocable token without resetting stakedAt.
3. User withdraws all XVS via requestWithdrawal; irrevocable token not burned.
4. Protocol calls `prime.burn(user)`; token.exists=false but stakedAt still nonzero.
5. Advance time >90 days (`time.increase(8640000)`).
6. User calls `prime.connect(user).claim()`; passes stakedAt!=0 and elapsed check, mints revocable token with 0 XVS staked.
**How found:** Code-reading of issue()/claim() comparing which paths delete stakedAt; noticed the irrevocable branch omits the reset that the revocable branch and claim() perform, then traced the burn-then-claim lifecycle.
**Exploitation:** Attacker needs to have been granted an irrevocable Prime token (e.g. large depositor), then withdraws all XVS, waits for the protocol to burn the inactive token, waits out the staking period, and calls claim() to mint a fresh revocable Prime token with no stake, gaining Prime rewards eligibility for free.
**Insight:** When auditing eligibility gates keyed on a timestamp, enumerate every state transition that mints/upgrades/burns the entitlement and check whether the gate variable is cleared on each path; asymmetric cleanup between sibling branches is a common source of stale-eligibility bugs.