# Cross-chain unstake and fast redeem operations fail due to minAmountLD not accounting for LayerZero dust removal

wiTryVaultComposer sets minAmountLD equal to amountLD, so LayerZero dust removal makes the slippage check revert for any amount not divisible by 1e12, breaking cross-chain unstake and fast redeem.

- Payout: Contest reward
- Severity: medium
- Program: Brix Money
- Credited: jerry0422
- Disclosed: 2026-02-10
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-11-brix-money#m-02
- Library page: https://bugbountylibrary.com/r/c4%3A2025-11-brix-money%3AM-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** wiTryVaultComposer.sol cross-chain unstake/fast redeem via LayerZero OFT
**Root cause:** minAmountLD is set to the full assets amount, but OFTCore._debitView removes dust (truncates to decimalConversionRate multiples) before comparing against minAmountLD, so any non-divisible amount fails the SlippageExceeded check.
**Steps:**
1. User unstakes an amount like 10000000000000000001 wei (10 ether + 1).
2. Composer builds SendParam with amountLD=assets and minAmountLD=assets.
3. OFT _debitView calls _removeDust: (amount/1e12)*1e12 truncates to 10000000000000000000.
4. Check amountReceivedLD < minAmountLD: 1e19 < 1e19+1 → reverts SlippageExceeded.
5. Repro via forge test --match-contract DustRemovalRevertPOC -vv.
**How found:** Code review of wiTryVaultComposer SendParam construction noticed minAmountLD set equal to amountLD, then cross-referenced OFTCore._debitView/_removeDust to see dust truncation precedes the slippage check.
**Insight:** When integrating LayerZero OFT, minAmountLD must account for _removeDust truncation to decimalConversionRate multiples; setting min equal to amount guarantees reverts on any non-divisible amount, and ERC4626 share conversions/fee deductions almost always produce dust.