[midnight adapter] Adapter - #786
Conversation
fa42572 to
eaab822
Compare
peyha
left a comment
peyha
left a comment
There was a problem hiding this comment.
Nice 🔥 🔥 using a linked list to manage maturities is smart
If I understand correctly, the allocation workflow should be
An allocator creates a make offer for the vault
A taker takes this offer onchain
| morphoV2 calls onBuy on the adapter
| | the adapter updates its state
| | the adapter calls allocate on its parent vault
| | | the vault V2 calls allocate on the market V2 adapter
| | | | the adapter returns the corresponding ids and allocated assets
|
|
||
| // Do not cleanup the linked list if we end up at 0 growth | ||
| function withdraw(Obligation memory obligation, uint256 obligationUnits, uint256 shares) external { | ||
| require(IVaultV2(parentVault).isAllocator(msg.sender), NotAuthorized()); |
There was a problem hiding this comment.
shouldn't lenders also be able to trigger a withdraw on morpho V2 ?
| maturityData.netCredit += boughtNetCredit.toUint128(); | ||
| marketData.netCredit += boughtNetCredit.toUint128(); | ||
|
|
||
| // Insert the maturity in the list if needed |
There was a problem hiding this comment.
would a dedicated lib for this kind of logic make sense ?
| uint256 netCreditLoss = uint256(marketData.netCredit) + boughtNetCredit - currentNetCredit(marketId); | ||
| decreaseNetCredit(marketId, market.maturity, netCreditLoss); | ||
|
|
||
| IVaultV2(parentVault) |
There was a problem hiding this comment.
the vault v2 doc specifies here that "[adapters] must not re-enter (directly or indirectly) the vault" and this line is breaking this property, a few possibilities to move forward
- Adapt the vault v2 doc to take this specific case into account
- Use a new intermediary contract "Relayer" to handle the callback
onBuy/onSellbefore calling the vault (but it adds operational complexity) - Refactor this function to make it clear that
onBuyis not interacting dangerously with the vault
| IVaultV2(parentVault) | ||
| .deallocate(address(this), abi.encode(zeroedDurationsIds, -int256(uint256(maturityData.netCredit))), 0); | ||
| } |
There was a problem hiding this comment.
another way to update these caps would be to return these ids/change in allocate/deallocate to let the vault update it automatically
| /// @dev Returns the number of durations in packedDurations that are at most the time to maturity. | ||
| function durationCount(uint256 maturity) internal view returns (uint256 count) { | ||
| uint256 timeToMaturity = maturity.zeroFloorSub(block.timestamp); | ||
| while (count < durationsLength && timeToMaturity >= packedDurations.get(count)) count++; |
There was a problem hiding this comment.
could speed this up with fenwick trees or segment tree + lazy propagation. not worth it for small duration array though
2 participants
TODO
Things to decide
forceDeallocateby selling vsforceDeallocateby minting sharesgrowth = interest / ttmso any take whereinterest < ttmthe remainder goes to current assets. In the WBTC example6.3e8 * 5/100is ~ 1 year in seconds. But for others it's not as bad (for usdc 1 year 5%, everything goes to assets below $630).State creation costs increases in glamsterdam that can bias more than before towards creating fewer slots.
Note: