# Accrued perfomance fee calculation takes wrong assumptions for share decimals, leading to loss of shares or hyperinflation

Popcorn Vault/AdapterBase performance fee math hardcodes 1e36 denominator assuming 18-decimal shares, causing zero fees or hyperinflated fee shares for other decimals.

- Payout: Contest reward
- Severity: medium
- Program: Popcorn
- Credited: DadeKuma
- Disclosed: 2023-09-07
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-01-popcorn-findings/issues/306
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-popcorn%3AM-24
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss vuln:reward-distribution

**Target:** Vault/AdapterBase performance fee accounting (Solidity)
**Root cause:** accruedPerformanceFee multiplies totalSupply by performanceFee and divides by fixed 1e36, assuming share decimals are 18; non-18-decimal shares break the denominator.
**Steps:**
1. Deploy vault/adapter whose share token has decimals != 18.
2. Accrue performance so shareValue > highWaterMark.
3. Call accruedPerformanceFee(): with decimals < 18 result rounds to 0; with decimals > 18 fee shares are disproportionately large.
4. Observe FEE_RECIPIENT gets no fees or hyperinflated shares diluting users.
**How found:** Code review of the fee formula noticing the hardcoded 1e36 denominator implicitly assumes totalSupply and performanceFee are both 1e18.
**Insight:** When auditing fee/share math, check every hardcoded 1e18/1e36 denominator against the actual token decimals() of the share token; non-standard decimals silently break rounding.