# Deadlock in vaults with underlying token with less then 18 decimals

WithdrawProxy.claim uses 1e18-scaled withdraw ratio against token balance without decimal scaling, so tokens with <18 decimals underflow and revert, deadlocking vault funds.

- Payout: Contest reward
- Severity: high
- Program: Astaria
- Credited: Tointer
- Disclosed: 2023-05-22
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-01-astaria-findings/issues/72
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-astaria%3AH-20
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** PublicVault/WithdrawProxy epoch claim flow
**Root cause:** PublicVault stores withdraw ratio in 1e18 scale, but WithdrawProxy.claim multiplies it by the token balance without converting to the token's decimals, producing a transferAmount far exceeding balance for tokens with <18 decimals.
**Steps:**
1. Deploy ERC20 with 8 decimals (e.g. WBTC-like).
2. Create PublicVault with that token via ASTARIA_ROUTER.newPublicVault.
3. Deposit, commit a lien, signalWithdraw, skip epoch, liquidate and bid so WithdrawProxy holds funds.
4. Call PublicVault.processEpoch() then withdrawProxy.claim() after finalAuctionEnd.
5. claim() computes transferAmount = balance * ratio(1e18) >> 18-scale, underflows balance and reverts, blocking epoch processing.
**How found:** Code reading of PublicVault's 1e18-scaled withdraw ratio versus WithdrawProxy.claim's use of that ratio directly against token balance; noticed missing decimal conversion and confirmed via modified testLiquidation5050Split with an 8-decimal token.
**Insight:** When a protocol normalizes ratios/shares to 1e18 internally, audit every consumer that multiplies them by a raw token balance — check for missing scaling to the underlying token's decimals, especially for USDC/WBTC vaults.