# Vault Fee uses incorrect offset leading to wildly incorrect value, allowing strategists to steal all funds

VAULT_FEE() clone offset off by 7 bytes returns ~3e20 instead of 5000, letting strategists drain vault funds via inflated unclaimed shares.

- Payout: Contest reward
- Severity: medium
- Program: Astaria
- Credited: zzykxx
- Disclosed: 2022-11-07
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2022-10-astaria-judging/issues/19
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AM-24
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** ERC4626-Cloned.sol PublicVault clone immutable args
**Root cause:** VAULT_FEE() offset set to 172 but preceding uint8 occupies only 1 byte at 164, so correct offset is 165; reading 7 bytes too far yields garbage ~1e16x larger.
**Steps:**
1. Deploy PublicVault via ClonesWithImmutableArgs with intended fee 5000
2. Call `PublicVault(publicVault).VAULT_FEE()`
3. Observe returned value > 3e20 instead of 5000
4. Trace usage in `_handleStrategistInterestReward()`: `fee = x.mulDivDown(VAULT_FEE(), 1000)`
5. Strategist calls withdraw to drain inflated `strategistUnclaimedShares`
**How found:** Code review of ClonesWithImmutableArgs offset layout; noticed uint8 at offset 164 occupies 1 byte so next field should start at 165, not 172; confirmed with POC logging VAULT_FEE().
**Exploitation:** Strategist triggers interest handling so `_handleStrategistInterestReward` computes fee with the inflated VAULT_FEE, crediting billions of times the real interest to strategistUnclaimedShares, then withdraws to drain vault funds.
**Insight:** When auditing clone-with-immutable-args contracts, manually recompute each field offset from the packed struct layout (uint8=1 byte) rather than trusting declared offsets; a single misaligned offset silently returns garbage that flows into fee math.
