# `LenderCommitmentGroup_Smart` does not use `mulDiv` when converting between token and share amounts, possibly leading to DoS or loss of funds

LenderCommitmentGroup_Smart multiplies pool value by 1e36 without mulDiv, so high-decimal tokens overflow sharesExchangeRate and _valueOfUnderlying, bricking deposits/withdrawals.

- Payout: Contest reward
- Severity: medium
- Program: Teller
- Credited: 0x73696d616f
- Disclosed: 2024-04-18
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-04-teller-finance-judging/issues/39
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-04-teller-finance%3AM-3
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:dos vuln:precision-loss

**Target:** LenderCommitmentGroup_Smart share/token conversion math
**Root cause:** sharesExchangeRate() and _valueOfUnderlying() compute poolTotalEstimatedValue * EXCHANGE_RATE_EXPANSION_FACTOR (1e36) and amount * 1e36 in plain uint256 multiplication instead of Math.mulDiv, so large token decimals or TVL overflow the intermediate product.
**Steps:**
1. Note EXCHANGE_RATE_EXPANSION_FACTOR = 1e36 and rate_ = poolTotalEstimatedValue * 1e36 / totalSupply.
2. Pick a Uniswap-V3-supported token with high decimals, e.g. BBC on Polygon with 32 decimals.
3. Compute overflow threshold: (2^256-1)/1e36/1e32 ≈ 1.15e9 base units; at $0.01 that is ~$11.5M TVL.
4. Deposit principal via addPrincipalToCommitmentGroup() in small amounts that don't overflow.
5. Once poolTotalEstimatedValue crosses the threshold, sharesExchangeRate() and _valueOfUnderlying() revert, blocking withdrawals.
**How found:** Code review of the exchange-rate math; noticed raw multiplication by 1e36 and reasoned about overflow bounds for high-decimal ERC20s, then searched for real Uniswap-listed high-decimal tokens to prove reachability.
**Escalation:** Researcher escalated validity by citing a real 32-decimal Uniswap token (BBC) and a 27-decimal token, plus ERC4626 _decimalsOffset() of 3 pushing effective decimals to 30.
**Insight:** When a protocol claims support for 'any Uniswap-compatible ERC20', check fixed-point scaling constants (1e18/1e36) against the max realistic token decimals; a single high-decimal token can make share math revert and lock funds.