# LMPVault: DoS when `feeSink` balance hits `perWalletLimit`

LMPVault's per-wallet share limit applies to feeSink, so once fee shares push its balance over perWalletLimit, _collectFees reverts and rebalance/debt reporting break.

- Payout: Contest reward
- Severity: medium
- Program: Tokemak
- Credited: Ch_301
- Disclosed: 2023-06-30
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-tokemak-judging/issues/679
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-tokemak%3AM-15
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** LMPVault ERC4626 share token / fee collection
**Root cause:** _collectFees mints fee shares to feeSink via _mint, which runs _beforeTokenTransfer enforcing perWalletLimit on the recipient; the sink is not exempted, so minting reverts once its balance plus fees exceeds the limit.
**Steps:**
1. Deploy LMPVault with a perWalletLimit set and a feeSink address.
2. Accumulate fees so _collectFees computes shares = _convertToShares(fees, Rounding.Up).
3. Call _mint(sink, shares); _beforeTokenTransfer checks balanceOf(to) + amount > perWalletLimit.
4. Once balanceOf(feeSink) + shares > perWalletLimit, revert OverWalletLimit(to).
5. Any call path invoking _collectFees (updateDebtReporting, rebalance, flashRebalance) now reverts.
**How found:** Code reading of _collectFees and _mint: noticed the fee mint routes through _beforeTokenTransfer, which enforces perWalletLimit on the recipient, and reasoned the sink would eventually hit that cap.
**Exploitation:** Not an attacker-driven exploit; the DoS occurs naturally as fees accrue to feeSink until its share balance crosses perWalletLimit, permanently reverting fee collection and the rebalance/debt-reporting functions that call it.
**Insight:** When a contract mints shares/tokens to an internal sink address, check whether recipient-side transfer hooks (wallet caps, allowlists, cooldowns) apply to that sink; internal system addresses often need exemption from user-facing limits.