search

donoso-eth / spool-foundry

3 stars 1 forks source link

High Level Suggestions #4

Open markcarey opened 1 year ago

markcarey commented 1 year ago

First of all, this is awesome. 👍 Good work @donoso-eth !

Here are several high-level suggestions. They come from my experience building Airlift Finance, a hackathon project (finalist at Unicode 2021). Airlift is based on the Vault / Strategy setup of Beefy.Finance. Reading about SuperPool, it reminded me of this experience. Based on that, here are few things that come to mind:

  1. I think using the term "Pool" is confusing in this context. In the Aave example, Aave is where the "pool" is. And when I see PoolV1 as dev who has worked with Aave contracts, I automatically think of Aave V1. With Beefy and Yearn, and others, the term Vault is used. DefFi users know what a "vault" is. As such I think the term Super Vaults is both more accurate and better in terms of education and marketing for both devs and "suppliers".
  2. I think Strategies should be non-Super!! Meaning, strategies should not know anything about SuperFluid, and thus never upgrade or downgrade tokens. Upgrade/Downgrades should happen in the Pool/Vault code instead. The Strategy should be concerned with accepting deposits, deploying the deposits into the strategy, and processing withdrawals to back to the Pool/Vault. This means that even a developer who knows nothing about Superfluid can write a strategy. Which makes it easier to attract more developers and thus more strategies. And it keeps things cleaner: all Superfluid stuff happens in the Pool/Vault, and Strategies are interfaces to non-super DeFi protocols.
  3. The previous suggestion begs the question: does it make a sense to take a step further? What if Super Vaults adopted the same "standard" or Interface as Beefy or Yearn, etc.? Would it is be possible to suddenly plug in all the pre-existing yearn/beefy Strategies into any new Super Vault? This seems possible, but perhaps diving deeper would reveal obstacles. But I would argue that it is the holy grail here. Rather than have to re-write Strategies that effectively exist already, if Super Pool/Vaults could adopt an existing strategy interface, a broad array of Strategies could be available very quickly. Side benefits could be the re-use of existing (open-source) code that may have been already audited or at least has some Lindy effect.

The above three suggestions are high-level, more in thinking of how we might maximize both developers and users, rather than any deeper technical suggestions. I will continue to dive deeper into the contracts and perhaps provide some lower level questions / feedback...

Overall, this is really cool.... 👍

donoso-eth commented 1 year ago

Hey @markcarey, thank you very much. Your suggestions are incredibly valuable, I will take some time to reflect on them. Thank you very much!!

markcarey commented 1 year ago

FWIW: https://docs.beefy.finance/developer-documentation/beefy-vault-v6 https://andrecronje.gitbook.io/yearn-finance/developers/yvaults-documentation/vault-interfaces

markcarey commented 1 year ago

...and it turns out there is an ERC standard for vaults, which I just learned about:

ERC-4626 is a standard to optimize and unify the technical parameters of yield-bearing vaults. It provides a standard API for tokenized yield-bearing vaults that represent shares of a single underlying ERC-20 token. ERC-4626 also outlines an optional extension for tokenized vaults utilizing ERC-20, offering basic functionality for depositing, withdrawing tokens and reading balances.

https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/

saflamini commented 1 year ago

Hey @markcarey this is fantastic feedback. I need to reflect on them for a bit also.

also tagging @kobuta23 here for visibilty

saflamini commented 1 year ago

More feedback from @seroxdesign

I’d argue for streaming into lending positions as a good use case.

For example, a larger DAO wants to borrow 1.2 million USDC, over 1 year. The APR is 10%. Smaller lenders could stream into the position until the stream rate covers 100k USDC a month.

This would allow lenders to make good APRs with smaller investments, and borrowers to ensure a constant flow of cash that isn’t reliant on one lender.

Not sure if this is relevant, the idea just instantly made me think of borrow/lending

markcarey commented 1 year ago

I keep thinking about this.... I am starting to wonder if it makes sense to take the idea of a standardized-vault/strategy setup a step further. What if new vaults weren't created at all? What if any pre-existing ERC4626 vault was automatically supported? In this scenario the only SF contracts would be deployed as DCA connectors to vaults from Beefy, Yearn, Idle, etc. Incoming streams are accepted, Gelato tasks do their thing periodically to downgrade superTokens and deposit to Yearn/Beefy vaults. The SF connector holds the vault tokens and does the magic to calculate the shares, and issues shares accordingly based on deposits/streams. The end result means I can stream DCA into one of many (Lindy-ish) vaults from multiple well-known DeFi projects. The amount of contract code to write and maintain is vastly reduced (and much of it seems to be already written!).

I would definitely use such a service and pay a fee to do so. And I bet DAOs would too, as way investing treasury funds.

donoso-eth commented 1 year ago

@markcarey Hey, I am now flying to Denver; last week was preparation for denver and this week will be very busy. We could have a call around the 10th. I think it would be great so we van walkthrough the current constraints and what can be changed!

markcarey commented 1 year ago

Sounds good. Enjoy ETHDenver!

Seroxdesign commented 1 year ago

I keep thinking about this.... I am starting to wonder if it makes sense to take the idea of a standardized-vault/strategy setup a step further. What if new vaults weren't created at all? What if any pre-existing ERC4626 vault was automatically supported? In this scenario the only SF contracts would be deployed as DCA connectors to vaults from Beefy, Yearn, Idle, etc. Incoming streams are accepted, Gelato tasks do their thing periodically to downgrade superTokens and deposit to Yearn/Beefy vaults. The SF connector holds the vault tokens and does the magic to calculate the shares, and issues shares accordingly based on deposits/streams. The end result means I can stream DCA into one of many (Lindy-ish) vaults from multiple well-known DeFi projects. The amount of contract code to write and maintain is vastly reduced (and much of it seems to be already written!).

I would definitely use such a service and pay a fee to do so. And I bet DAOs would too, as way investing treasury funds.

This sounds excellent, I'm sure there's an appetite for it I worked on a DAO that's doing on-chain lending/borrowing and it feels like a great way to minimize risk of defaults, since if a borrower defaults all that would need to happen is have the stream(s) shut down.

donoso-eth commented 1 year ago

@saflamini @markcarey @Seroxdesign , next week we could continue the conversation, as mentioned, I think would be really good to have a meeting. Are you free on Tuesday/Wednesday late afternoon CET times so Sam can connect too?