# convert_to_yang_helper() loss precision

Opus gate.cairo convert_to_yang_helper divides by 1e18 before multiplying, truncating shares to zero for low-decimal assets like BTC, causing depositor fund loss.

- Payout: Contest reward
- Severity: high
- Program: Opus
- Credited: bin2chen
- Disclosed: 2024-03-08
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-01-opus-findings/issues/195
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-opus%3AH-02
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:precision-loss

**Target:** Cairo gate contract deposit share conversion
**Root cause:** Overloaded Wad operators perform an intermediate division by 1e18 before multiplying by total_assets, truncating the result for assets with fewer than 18 decimals.
**Steps:**
1. Deploy gate with BTC (decimals=8), add_yang with INITIAL_DEPOSIT_AMT=1000 giving total_yang=1e13, total_assets=1000
2. Call deposit() with asset_amt=90_000 (0.0009e8 BTC)
3. convert_to_yang_helper computes (asset_amt * total_yang)/1e18 = 0 due to Wad operator truncation
4. Shares returned are 0; user loses deposited 36 USD worth of BTC
5. Fix: compute asset_amt.into() * total_yang.into() / total_assets.into() in u256 before converting to Wad
**How found:** Researcher read convert_to_yang_helper and recognized that Wad's overloaded operators implicitly divide by 1e18 mid-expression, then tested with BTC's 8 decimals to show truncation to zero.
**Insight:** When a fixed-point type overloads * and /, the implicit scaling happens per-operation; check intermediate truncation for tokens with decimals below the Wad scale, especially high-value-per-unit assets.