# Wrong initial TwoCurve liquidity computation

ZapMathLib.computeSharesToTwoCrypto ignores PT/vault decimal mismatch, so initial TwoCurve liquidity add computes zero shares and reverts, breaking pool bootstrap.

- Payout: Contest reward
- Severity: medium
- Program: Napier
- Credited: Christoph Michel
- Disclosed: 2025-03-11
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_napier_february2025.pdf#3.2.1
- Library page: https://bugbountylibrary.com/r/cantina%3Anapier_february2025%3A3.2.1
- Tags: domain:web3 impact:dos kind:contest platform:cantina sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic vuln:precision-loss

**Target:** ZapMathLib / TwoCryptoZap createAndAddLiquidity
**Root cause:** computeSharesToTwoCrypto converts initialPrice*principal/WAD (asset decimals) into previewSupply which expects target/vault decimals, ignoring the PT-vs-vault decimal difference; with 6-decimal asset and 18-decimal vault the result truncates to zero.
**Steps:**
1. Deploy vault with 18 decimals over 6-decimal asset (e.g. Morpho USDC vault).
2. Call `zap.createAndAddLiquidity` with shares=10*10**18.
3. Observe `underlyingReserveInPT = previewSupply(0.7e18*1e6/1e18=0.7e6)` then `0.7e6*scale/1e18` with scale=1e6 yields 0.
4. Zero shares passed to `two_crypto.add_liquidity`, call reverts.
**How found:** Code-reading of the decimal units in computeSharesToTwoCrypto: noticed previewSupply expects target decimals while the price*principal/WAD term is in asset decimals, then confirmed with a PoC using a 6-decimal asset and 18-decimal vault.
**Insight:** When a math helper mixes a price (18-dec WAD) with token amounts, trace each operand's decimals against the downstream function's expected unit; vaults commonly use 18 decimals regardless of underlying, so PT-vs-vault decimal skew is a recurring truncation-to-zero source.