# Locked funds from tokenization are credited twice to user leading to protocol fund loss

FairSide releases NFT-locked FSD tokens twice when acquiring conviction back, letting a user drain double the locked amount from the protocol.

- Payout: Audit contest
- Severity: high
- Program: FairSide
- Disclosed: 2021-07-07
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-05-fairside-findings/issues/30
- Library page: https://bugbountylibrary.com/r/c4%3A2021-05-fairside%3AH-03
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** ERC20ConvictionScore / FairSideConviction Solidity contracts
**Root cause:** Locked FSD tokens are released once inside FairSideConviction._release() (via acquireConviction -> burn) and again immediately after the burn in ERC20ConvictionScore.acquireConviction(), double-crediting the user.
**Steps:**
1. Alice tokenizes her conviction score into an NFT and locks 100 FSDs.
2. Bob buys the NFT from Alice.
3. Bob calls acquireConviction() to reclaim the conviction score from the NFT.
4. The locked 100 FSDs are transferred in `_release()` (FairSideConviction.sol Line123) via burn.
5. The same 100 FSDs are transferred again on Line316 of `acquireConviction()` in ERC20ConvictionScore.sol.
6. Bob receives 200 FSDs instead of 100, at protocol expense.
**How found:** Code review of the tokenization/acquireConviction workflow, noticing the locked-funds release is performed in two separate places (FairSideConviction._release and ERC20ConvictionScore.acquireConviction).
**Exploitation:** Attacker acquires an NFT carrying locked FSD tokens and calls acquireConviction(); the redundant transfer on Line316 pays out the locked amount a second time from protocol funds, netting double the locked tokens.
**Insight:** When a value-release or refund path spans two contracts, trace every transfer of the locked asset across the whole call chain; a release duplicated in both the burn helper and its caller double-pays and drains protocol reserves.