📌 Description
set_min_liquidity(asset, floor) and set_max_settlement_amount(asset, amount) gate the single-asset withdraw_liquidity/open_settlement paths. The batch variants provide_liquidity_multi/withdraw_liquidity_multi validate "no duplicate assets" per the README, but it's not documented whether each per-asset leg of the batch is checked against the same floor/cap as its single-asset counterpart.
🧩 Requirements and context
- Add a test where a batch
withdraw_liquidity_multi request includes a leg that would violate min_liquidity for that asset — assert the whole batch is rejected (atomic, per the existing batch semantics), not partially applied.
- Add the equivalent test for a per-asset
max_settlement_amount cap and open_settlement-adjacent batch behavior if applicable.
- Fix
src/lib.rs if either guard is currently only enforced in the single-asset path.
🛠️ Suggested execution
- Add reproduction tests in
src/test.rs covering multi-asset batches that individually violate per-asset floors/caps.
- If gaps are found, route the batch entrypoints through the same per-asset guard helper the single-asset entrypoints use.
- Confirm atomicity is preserved (zero partial writes) when a batch is rejected.
✅ Acceptance criteria
🔒 Security notes
A gap here would let a caller bypass a configured liquidity floor or settlement cap simply by using the batch entrypoint instead of the single-asset one.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
set_min_liquidity(asset, floor)andset_max_settlement_amount(asset, amount)gate the single-assetwithdraw_liquidity/open_settlementpaths. The batch variantsprovide_liquidity_multi/withdraw_liquidity_multivalidate "no duplicate assets" per the README, but it's not documented whether each per-asset leg of the batch is checked against the same floor/cap as its single-asset counterpart.🧩 Requirements and context
withdraw_liquidity_multirequest includes a leg that would violatemin_liquidityfor that asset — assert the whole batch is rejected (atomic, per the existing batch semantics), not partially applied.max_settlement_amountcap andopen_settlement-adjacent batch behavior if applicable.src/lib.rsif either guard is currently only enforced in the single-asset path.🛠️ Suggested execution
src/test.rscovering multi-asset batches that individually violate per-asset floors/caps.✅ Acceptance criteria
🔒 Security notes
A gap here would let a caller bypass a configured liquidity floor or settlement cap simply by using the batch entrypoint instead of the single-asset one.
📋 Guidelines