# Unable to deposit to Tranche/Adaptor under certain conditions

When buffer ETH is exhausted with pending withdrawals, stakeAmount caps to zero, causing Lido/Frax adapters to revert and blocking PT/YT minting.

- Payout: Contest reward
- Severity: medium
- Program: Napier
- Credited: AuditorPraise
- Disclosed: 2024-01-24
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-01-napier-judging/issues/105
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-01-napier%3AM-10
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** BaseLSTAdapter / StEtherAdapter / SFrxETHAdapter deposit path
**Root cause:** prefundedDeposit caps stakeAmount to 95% of availableEth, which can be zero when availableEth=0 and a pending withdrawal exists; _stake then calls STETH.submit/FRXETH_MINTER.submit with 0 ETH, which reverts.
**Steps:**
1. Have a pending withdrawal request (queueEthCache > 0) and availableEth = 0 in the buffer.
2. Call `prefundedDeposit()`; stakeAmount = availableEth + queueEthCache - targetBufferEth, then capped to maxStakeAmount = (availableEth*95)/100 = 0.
3. `_stake(0)` executes `IWETH9(WETH).withdraw(0)` then `STETH.submit{value:0}` returning 0 stETH -> `revert InvariantViolation()`.
4. Same for SFrxETHAdapter: `FRXETH_MINTER.submit{value:0}` reverts with 'Cannot submit 0'.
**How found:** Code reading of the prefundedDeposit cap logic and the comment noting stakeAmount can be zero, then tracing into adapter _stake implementations and the external Lido/Frax submit contracts to confirm zero-value reverts.
**Insight:** When a cap formula multiplies by a buffer ratio, check the zero-input path: downstream external staking/deposit calls often reject zero value, turning a benign cap into a DoS on the core mint path.