# Vaults can be griefed to not be able to be used for deposits

Attacker deposits just enough ETH to leave a vault's remaining stake below MIN_STAKING_AMOUNT, permanently blocking completion of the 24 ETH validator deposit.

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

**Target:** SavETHVault / StakingFundsVault deposit logic (ETHPoolLPFactory._depositETHForStaking)
**Root cause:** Deposits require _amount >= MIN_STAKING_AMOUNT, but the final top-up needed to reach maxStakingAmountPerValidator can be smaller than MIN_STAKING_AMOUNT, making completion impossible.
**Steps:**
1. Vault holds 22 ETH for a validator (max 24 ETH).
2. Attacker deposits 1.9991 ETH, leaving 0.0009 ETH remaining to reach 24 ETH.
3. 0009 ETH < MIN_STAKING_AMOUNT (0.001 ETH), so any completing deposit reverts on `require(_amount >= MIN_STAKING_AMOUNT)`.
4. Vault cannot be completed; attacker repeats to keep delta under minimum.
**How found:** Reading _depositETHForStaking revealed the minimum-amount require combined with the max-staking cap, implying a residual window below the minimum that cannot be filled.
**Exploitation:** Attacker repeatedly deposits amounts sized so the residual to maxStakingAmountPerValidator stays below MIN_STAKING_AMOUNT, denying vault completion; even if depositors withdraw and redeposit, attacker re-tops to maintain the sub-minimum gap.
**Insight:** When a contract enforces both a per-call minimum and a cumulative cap, check whether cap-minus-current can fall below the minimum, creating an unfillable gap an attacker can steer into.