# Rotating LPTokens to banned BLS public key

rotateLPTokens lacks a banned-BLS-key check, letting a user migrate LP tokens onto a banned knot's LP token, risking protocol insolvency.

- Payout: Contest reward
- Severity: medium
- Program: Stakehouse Protocol
- Credited: HE1M
- Disclosed: 2023-01-20
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-11-stakehouse-findings/issues/64
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-stakehouse%3AM-02
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** ETHPoolLPFactory / StakingFundsVault smart contracts
**Root cause:** depositETHForStaking enforces isBLSPublicKeyBanned on the knot, but rotateLPTokens does not validate that the new knot's BLS public key is unbanned before migrating LP tokens.
**Steps:**
1. Call `depositETHForStaking` with an unbanned BLS key to obtain `_oldLPToken`.
2. Call `rotateLPTokens(_oldLPToken, _newLPToken)` where `_newLPToken` corresponds to a banned BLS public key.
3. Observe no `isBLSPublicKeyBanned` check on the new knot; LP token balance for the banned key increases.
**How found:** Code reading: noticed depositETHForStaking enforces the banned-key require but the parallel rotateLPTokens path omits the same check, an inconsistent-validation gap.
**Exploitation:** A malicious user rotates LP tokens onto a banned (potentially malicious) BLS key's LP token, inflating exposure to a knot the protocol intended to exclude, which can lead to insolvency.
**Insight:** When a guard like isBLSPublicKeyBanned is applied on one entry path (deposit), audit every other path that mutates the same LP-token accounting (rotate/migrate) for the missing equivalent check.