# _getInterest() function uses block.timestamp instead of the inputted timestamp

Astaria's _getInterest() checks block.timestamp instead of the passed-in timestamp, returning wrong interest values that propagate into debt and slope calculations.

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

**Target:** LienToken.sol _getInterest() interest calculation
**Root cause:** The branch condition uses block.timestamp instead of the function's timestamp parameter, so the max-interest cap path is chosen based on current time rather than the queried time.
**Steps:**
1. Call `_getInterest(lien, timestamp)` where `block.timestamp >= lien.start + lien.duration` but `timestamp` is within the lien: returns max interest instead of accrued interest.
2. Call with `block.timestamp < lien.start + lien.duration` but `timestamp` far past lien end: skips cap and computes `delta_t = timestamp - lien.last`, over-accruing interest.
3. Observe wrong values propagate to `_getOwed()`, `calculateSlope()`, `changeInSlope()`, `getTotalDebtForCollateralToken()`.
**How found:** Code reading of _getInterest() revealed the branch condition referenced block.timestamp rather than the timestamp parameter, contradicting the function's stated purpose of computing interest at an arbitrary timestamp.
**Insight:** In Solidity interest/debt math, verify every time reference inside a function that accepts a timestamp parameter actually uses that parameter, not block.timestamp; mismatches silently corrupt downstream debt and slope calculations.