Skip to content

Conversation

@0xMcsweeja
Copy link

@0xMcsweeja 0xMcsweeja commented Oct 3, 2025

Adapter for morpho's VaultV2

Morpho's guidance was "Ok, very clear. Then in that case you should use vault v2 with a custom adapter that takes into account the asynchronicity. You can take inspiration from the Vaultv1 adapter "

TLDR

  • VaultV2's introduce adapters which are a wrapper that allows a vault to interact with other protocols (wildcat)
  • Need special adapter because vaults allocate and deallocate need to be synchronous. Our withdraw process is asyncrhonous.
  • This adapter exposes some helpers for a curator to initiate a withdrawal and then deallocate performs the execute which claims.

code

  • WildcatMarketV2Adapter is the main file - contains the logic for vault <-> wildcat market interactions
  • various interfaces
  • some tests which still being expanded

explanation

Adapter deposits funds into wildcat markets on allocate() calls and attempts to pull funds on deallocate(). Since our withdrawals need to queue and mature, the adapter tracks pending batches to keep expiries. When attempting to deallocate we try and realise any matured expiries and if there isnt enough liquidity for the deallocation request it fails.

Contract maintains an indexed list of expiries with pending withdrawals and mutates as realised.

Tricky parts / confusions / please read dillon / laurence

  • The Vault will instantly attempt to withdraw exactly the amount that deallocate is called with. This is only important for us since we can have scenarios where partial amounts are paid and the adapter/vault must revert or deallocate the exact amount.
  • No forced de-allocation. the spec does include that force-deallocation should be included but we cant do that.
  • I've left all licensing as TODO because nfi and dont want tim clancy on my back
  • theres a magic number being used in deallocate - _realizeClaimable(8); this is just an arbitrary depth of batches to try and resolve on a deallocate call. if theres a better constant to use here LMK. can also be side-stepped with the function that allows you to input batch num though
  • I included an adaptor factory because the morpho example had one. if we don't need it we can remove
  • approvals are set to max so that the vault can deallocate and allocate at will - seems intentional by design but just double check no footgun.
  • i have not looked at the changes made for plasma deployment yet and thus dont know if any changes are needed if this goes to plasma

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants