# retainerc4626 flag mishandling in _updatemultideposit

When failed multideposit entries are filtered out in _updateMultiDeposit, the retainERC4626 flag array is not realigned, so surviving superforms get wrong mint-vs-retain behavior.

- Payout: Contest reward
- Severity: medium
- Program: Superform Erc1155a
- Credited: elhaj
- Disclosed: 2024-02-13
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_superform_erc1155a_dec2023.pdf#3.2.1
- Library page: https://bugbountylibrary.com/r/cantina%3Asuperform_erc1155a_dec2023%3A3.2.1
- Tags: domain:web3 impact:integrity kind:contest platform:cantina sev:medium tech:solidity technique:source-review vuln:business-logic

**Target:** CoreStateRegistry.updateDepositPayload / _updateMultiDeposit (Solidity contract)
**Root cause:** _updateMultiDeposit rebuilds superformIds, amounts, maxSlippages and hasDstSwaps arrays filtered by non-zero amounts but leaves retainERC4626 at its original length/order, so flags no longer correspond to the surviving superformIds.
**Steps:**
1. Bob submits singleXchainMultiDeposit with superformIds `[1,2,3,4]`, amounts `[a,b,c,d]`, retainERC4626 `[true,true,false,false]`.
2. Keeper calls `updateDepositPayload(payloadId, finalAmounts)` where deposits 1 and 2 fail (amounts resolve to 0).
3. _updateMultiDeposit filters arrays to superformIds `[3,4]`, amounts `[c',d']`, but retainERC4626 stays `[true,true,false,false]`.
4. Keeper processes payload; _multiDeposit reads retainERC4626[0..1]=true for superforms 3 and 4, minting superPositions instead of retaining ERC4626 shares.
**How found:** Code review of the array-filtering loop in _updateMultiDeposit, noticing every parallel array is rebuilt except retainERC4626, then tracing how _multiDeposit consumes the flag by index.
**Insight:** When a function filters parallel arrays by index, audit every sibling array for the same filter — any array left un-rebuilt silently shifts its association to the surviving IDs.