fix: deposit the measured unlocked amount in MorphoAllocator.run#3
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughMorphoAllocator's run function replaces its depositAmount parameter with minAmountReceived and now deposits the full measured unlocked amount via Facility.depositManager. The slippage guard enforces unlocked against max(minAmountReceived, minSharesUnlocked). Tests and event documentation are updated to reflect this behavior. ChangesMorphoAllocator deposit-amount replacement with unlocked amount
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Caller
participant MorphoAllocator
participant Facility
Caller->>MorphoAllocator: run(intentId, deallocations, minAmountReceived, minSharesUnlocked, ...)
MorphoAllocator->>MorphoAllocator: compute unlocked
MorphoAllocator->>MorphoAllocator: minUnlocked = max(minAmountReceived, minSharesUnlocked)
alt unlocked < minUnlocked
MorphoAllocator--)Caller: revert SlippageExceeded(minUnlocked, unlocked)
else
MorphoAllocator->>Facility: depositManager(unlocked)
end
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
b07ba95 to
ced4211
Compare
Problem
MorphoAllocator.rundeposits a caller-supplieddepositAmountviaFacility.depositManager, while the amount actually credited to the intent byunlockis measured on-chain (unlocked). The executor has to predict the unlocked amount off-chain when building the transaction, and any difference (unlock slippage, fund NAV movement between order creation and unlock) leaves collateral dust sitting on the intent. Cleaning that dust would otherwise require an extra sweep-deposit step in orchestration.Fix
runnow deposits the measuredunlockedamount in full, so the intent is always left with zero collateral dust.minAmountReceived, a minimum on the unlocked amount; the stricter of it andminSharesUnlockedapplies.Note for executors: a value passed in the old
depositAmountslot now acts as a floor on the unlocked amount, so it should be the slippage-adjusted minimum (or 0 to rely onminSharesUnlockedalone), not the raw predicted amount.Tests
test_run_depositsUnlockedAmount: the full unlocked amount is deposited even whenminAmountReceivedis below it.test_run_revertsWhenUnlockedBelowMinAmountReceived: the repurposed slot is enforced as a floor when it is the stricter of the two minimums.Summary by CodeRabbit