# `depositAndAllocateForPartyB` is broken due to incorrect precision

depositAndAllocateForPartyB passes native-precision amount to allocateForPartyB which expects 18-decimal precision, so 1000 USDC allocates only 0.000000001 USDC.

- Payout: Contest reward
- Severity: high
- Program: Symmetrical
- Credited: 0xChinedu
- Disclosed: 2023-06-05
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-symmetrical-judging/issues/222
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-symmetrical%3AH-5
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss

**Target:** AccountFacet depositAndAllocateForPartyB (symmio-core)
**Root cause:** depositForPartyB scales native amount to 18 decimals internally, but depositAndAllocateForPartyB forwards the same unscaled native-precision amount to allocateForPartyB, which expects 18-decimal internal accounting precision.
**Steps:**
1. Alice calls `depositAndAllocateForPartyB(1000e6, partyA)` for USDC (6 decimals).
2. depositForPartyB transfers 1000e6 and credits balance with `(1000e6 * 1e18)/1e6 = 1000e18`.
3. allocateForPartyB is called with the raw `1000e6` instead of `1000e18`.
4. Only 1000e6 (0.000000001 USDC in 18-decimal terms) is moved from balance to partyBAllocatedBalances.
**How found:** Code reading of the two internal functions revealed they expect different precisions (native vs 18-decimal) while the wrapper passes the same amount to both.
**Insight:** When a wrapper composes a deposit function (which self-scales) with an allocate/accounting function (which assumes scaled units), check that the unit contract of each callee matches; mixed-precision composition silently under-allocates.