# ShortLongSpell#openPosition uses the wrong balanceOf when determining how much collateral to put

ShortLongSpell#openPosition passes uToken balance instead of vault balance to _doPutCollateral, leaving vault tokens stranded in the contract for anyone to steal.

- Payout: Contest reward
- Severity: high
- Program: Blueberry
- Credited: 0x52
- Disclosed: 2023-05-02
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-05-blueberry-judging/issues/31
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-05-blueberry%3AH-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error

**Target:** ShortLongSpell.openPosition collateral deposit logic
**Root cause:** The collateral amount is computed from ISoftVault(vault).uToken().balanceOf(address(this)) rather than the vault token balance, so the deposited amount mismatches the actual vault tokens held.
**Steps:**
1. Call `ShortLongSpell#openPosition` with a strategyId whose vault is a SoftVault
2. Observe `_doPutCollateral(vault, IERC20Upgradeable(ISoftVault(vault).uToken()).balanceOf(address(this)))` uses uToken balance
3. Vault tokens received remain in the spell contract instead of being deposited
4. Attacker sweeps the stranded vault tokens from the contract
**How found:** Manual code review of the collateral deposit path, noticing the balanceOf call targets the uToken rather than the vault token that is actually being deposited.
**Exploitation:** After a user opens a position, vault tokens are left in the ShortLongSpell contract; an attacker calls a sweep/withdraw path or triggers the leftover balance to be taken, capturing the stranded collateral.
**Insight:** When a contract wraps tokens (uToken vs vault token), verify every balanceOf/amount computation references the exact token being transferred; mismatched wrapper balances strand funds in the spell contract.