# wrong calcLiquidityHoldings that leads to dead fund in the Pool

Pool mixes user LP tokens and Synth debt-LP tokens in one accounting balance, so burning both leaves stranded token B with no LP holder.

- Payout: Audit contest
- Severity: high
- Program: Spartan Protocol
- Found by: jonah1005
- Disclosed: 2021-09-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-07-spartan-findings/issues/71
- Library page: https://bugbountylibrary.com/r/c4%3A2021-07-spartan%3AH-12
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity vuln:accounting-error vuln:business-logic

**Target:** Pool contract LP/debt-LP accounting (calcLiquidityHoldings, burn paths)
**Root cause:** Pool mints the same LP token for user liquidity (addForMember) and for Synth debt (mintSynth), but the two burn paths compute redemption differently, so the combined balance misprices withdrawals.
**Steps:**
1. Alice calls `addForMember` with Sparta 1000 and token B 1000, creating a new Pool and receiving LP tokens.
2. Bob calls `mintSynth` with 1000 Sparta, receiving debt-LP held by the Synth contract.
3. Alice burns all her LP tokens and withdraws her share.
4. Bob burns all Synth debt-LP via the Synth contract, withdrawing Sparta.
5. Pool is left holding a large residual of token B with no LP holder to claim it.
**How found:** Reading the two separate burn implementations (burn original lp at Pool.sol L192-202 and burn debt-lp at L244-257) and noticing both draw on the same LP accounting, then reasoning through a two-actor add/mint/burn sequence.
**Insight:** When a pool mints one LP token for two economically different claims (user liquidity vs protocol debt), trace each burn path's redemption math against a mixed-holder state; the mismatch surfaces as stranded reserves.