Ok thanks Jeroen. What does PSM stand for here?
“Peg Stability Module”, a contract/module that many stablecoins implement for swapping between their stablecoin and another stablecoin. That is just an example that a Pipe could fit for though, not the only use case.
Hello @jeroen,
I hope you’re doing well. Thank you for your hard work on the ERC-4626 spec.
Reading the spec, it is difficult to see how ERC-4626 would be used to implement ragequit behavior (see moloch.daohaus.fun/features/ragequit), which involves redeeming shares for the proportional underlying assets across all the vaults, or withdrawing the two assets from an LP.
It seems that using the current spec, implementing this would require an external contract with permissions for all the entry points, enabling it to redeem all assets simultaneously. If done sequentially (not using the external contract), only one vault would be redeemable at a time, leaving the rest nonredeemable due to burning the shares.
I would appreciate if you could think on how these two cases would work, and maybe updating the spec with more specific examples.
Could you please consider how these two cases would work and possibly update the spec with more specific examples? I would greatly appreciate your thoughts on this matter.
Thank you so much for your time and help.
Is this valid for LPs too ?
I’m looking for a multi-LPs tokenized vault with weighted individual vaults, similarly to an ETF with LPs that can be community-managed to decide allocation of each individual vault, with weekly vote/epoch-based allocation wars + vote 2 earn (financed with 10% of fees & rewards generated by the LPs on DEXs) + bribes (financed by Treasury or partners).
Also I’m looking for veNFTs-based governance (EIP-5725), but with amount of burned tokens (ETF tokens from above) as voting power/metadata (must burn tokens through veNFTs minter contract, instead just locking them).
Community-managed tokenized protocol owned liquidity with vote 2 earn and burn 2 govern mechanics (philantrocratic governance/proof of burn standard).
Do you know if there’s anything like this already built ?
hi all, does anyone know:
- what vault aggregators already support ERC-7575?
- what vault aggregators are planning to support ERC-7575?
I can’t find any yet, but maybe it’s still too early.
I’d like to understand how the adoption of this is looking.
This I would know as well. As far as my search goes I think Centrifuge is going to support 7575 for RWA related functions.
I am a little confused about this EIP where a holder of shares redeems these shares in a vault not the same as the one it was minted shares from. Doesn’t it mess up the ratio conversion ?
For example, there are two 7575 vaults using same Share contract. Vault A accepts wETH as asset and Vault B accepts wBNB. An account deposits wETH in Vault A and later redeems the shares in Vault B.
1 Like
Hey guys, could you please elaborate what was the rationale behind making the ERC-7575 vaults as separate contracts instead of gathering everything under a single entrypoint?
It seems a bit overdemanding to deploy and manage new entrypoints anytime a new token is added. Wouldn’t it be more UX-friendly to have a single “vault” that understands how and allows the management of only the whitelisted tokens?
This vault may have a standardized functionality (interface) on how to covert the underlying assets to a “common reference unit” (e.g. USD) to be then used to calculate the value of shares.
Yes the implementation will need to ensure liquidity is balanced between the various vaults. This could be for example by limiting withdrawals in a vault to the deposited assets. In your example, that would mean that the account would not be able to redeem wBNB from vault B.
Each vault has their own convertToAssets method, and the implementation will need to make sure to account for the different assets. So this could be by having a separate oracle for each asset:share combination, and returning different values.
The intention of ERC-7575 was to stay as close to ERC-4626 as possible. This means most integrations for ERC-4626 will still function. I agree what you are proposing makes sense from first principles, but given the widespread adoption of ERC-4626 that already existed, we decided it made sense to stick to the current design, and have as little backwards incompatibility as possible.
1 Like
This spec is big on structure but low on substance regarding the single biggest barrier to multi-asset vault usage: share pricing.
Instead of building around the real problem (valuing multiple assets under one share), it mostly clones ERC-4626 and adds some extraneous bells and whistles that can turn into a maintenance headache.
also what’s the point of mimicking ERC-4626 if it doesn’t give you the entire reason ERC-4626 exists in the first place - the ability to easily convert shares to underlying token?