# Public vault slope can overflow

Unchecked addition in PublicVault.afterPayment lets slope overflow after a few max-rate loans, corrupting totalAssets and causing slope underflows.

- 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/418
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-astaria%3AM-10
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss

**Target:** PublicVault.sol afterPayment slope accounting
**Root cause:** Slope is accumulated with unchecked addition in afterPayment; with 48-bit slope and max interest rate, a handful of loans overflows the value, and subsequent slope updates underflow.
**Steps:**
1. Take an 18-decimal ERC20 token.
2. Originate 5 loans of 1000 tokens each at max interest rate 63419583966.
3. Slope accumulates as 5*1000*63419583966/2^48 = 1.1265581173, overflowing the 48-bit slope.
4. Observe totalAssets becomes incorrect and later slope updates underflow.
**How found:** Code reading of the unchecked block in PublicVault.afterPayment and the slope math in LienToken, noticing 48-bit slope is too small for realistic loan volumes at max rate.
**Insight:** When auditing fixed-point accumulator math, compute the overflow threshold from the bit-width and max configurable rate; a 48-bit slope with 18-decimal tokens overflows after only a few max-rate loans.