# yIntercept of public vaults can overflow

Unchecked addition in PublicVault yIntercept overflows, making totalAssets far lower than actual and blocking LP withdrawals.

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

**Target:** PublicVault.sol yIntercept accounting (Solidity)
**Root cause:** yIntercept is updated with an unchecked addition in PublicVault.sol L323-325; large deposits overflow the uint256, wrapping the stored value.
**Steps:**
1. Deploy public vault via `_createPublicVault` with 14-day epoch.
2. Lend `309000000 ether` from address(1) to the vault.
3. Lend `10000000 ether` from address(2).
4. Observe `PublicVault(publicVault).totalAssets() < 10000000 ether` due to overflowed yIntercept.
**How found:** Code review of the unchecked block around yIntercept update in PublicVault.sol, then Foundry PoC with large lend amounts.
**Exploitation:** A large deposit causes yIntercept to wrap; totalAssets becomes far smaller than real holdings, so LPs cannot withdraw their share. Requires token precision high enough to reach overflow.
**Insight:** Audit unchecked arithmetic in share/accounting accumulators (yIntercept, slope) for overflow with high-precision ERC20s; test extreme deposit magnitudes.
