# user.creation is updated incorrectly when the user tries to extend membership

Extending a FairSide membership miscalculates user.creation, pushing it years into the future and locking the user out of membership features.

- Payout: Audit contest
- Severity: medium
- Program: FairSide
- Found by: WatchPug
- Disclosed: 2021-12-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-11-fairside-findings/issues/61
- Library page: https://bugbountylibrary.com/r/c4%3A2021-11-fairside%3AM-02
- Tags: area:web3 domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** FSDNetwork.sol purchaseMembership membership accounting
**Root cause:** When extending an existing membership, durationIncrease is added to user.creation instead of being applied as an extension, so creation jumps forward by the added duration rather than staying fixed.
**Steps:**
1. Alice calls `purchaseMembership()` with 20 ether costShareBenefit on day 1: creation=day1, gracePeriod=day791
2. Alice calls `purchaseMembership()` again with 20 ether on day 2
3. elapsedDurationPercentage = 1/720, durationIncrease = 730 days
4. creation becomes day731 and gracePeriod day1521, locking Alice out of membership features for ~2 years
**How found:** Code review of the else branch in purchaseMembership, noticing durationIncrease is added to user.creation rather than extending the end date.
**Insight:** In membership/subscription accounting, extension logic should shift the expiry forward while keeping the start timestamp fixed; adding duration to the start timestamp silently pushes eligibility into the future.