# Sense redeem is unavailable and funds are frozen for underlyings whose decimals are smaller than the corresponding IBT decimals

Sense Redeemer.redeem compares PT amount (IBT decimals) to underlying received (underlying decimals), reverting and freezing funds when underlying decimals are smaller.

- Payout: Contest reward
- Severity: high
- Program: Illuminate
- Credited: hyh
- Disclosed: 2022-10-15
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2022-10-illuminate-judging/issues/228
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-illuminate%3AH-3
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Redeemer.sol Sense redeem() slippage check
**Root cause:** Sense PT inherits IBT decimals (e.g. cUSDC 8) not underlying decimals (USDC 6), but redeem() compares raw PT amount to raw underlying received without decimal normalization.
**Steps:**
1. Lender holds Sense PT for a market where IBT decimals > underlying decimals (e.g. cUSDC 8 vs USDC 6).
2. Call Redeemer.redeem(p=Sense, u=USDC, m, s, a).
3. amount = token.balanceOf(lender) in 8-decimal PT units; redeemed = underlying received in 6-decimal units.
4. Check `if (redeemed < amount) revert Exception(13,...)` always true, so redeem reverts and PT funds stay frozen.
**How found:** Code reading of redeem() slippage check comparing PT balance to underlying received 1:1, noticing Sense PT uses IBT decimals per Sense docs/etherscan token contracts.
**Escalation:** For underlying decimals > IBT decimals (DAI 18 vs cDAI 8) the check becomes a noop, exposing Sense AMM redemption to sandwich attacks on large amounts.
**Insight:** When a protocol compares a principal/derivative token amount to an underlying amount, verify the token's decimals match the underlying; PT/IBT tokens often inherit the wrapper's decimals, not the asset's.