Stream yield-bearing assets

[razgraf]

We've gotten a lot of feedback regarding streaming with yield-enhanced tokens aTokens from Aave, cTokens from Compound.

With normal, exchange-rate ERC20s (e.g. Yearn's system) this should be pretty straight forward. X goes in, X goes out - with the X_i tokens being more valuable than the X_o (they can be redeemed for more $).

With rebasing tokens this becomes an accounting problem - keeping track of balances. Unfortunately both Aave and Compound V3 use this system for their share tokens (e.g. aUSDC or cUSDCV3).

Topic 1 - Support this type of assets

While the v2-core itself will only support regular assets, wrapping these rebasing tokens in an ERC4626 vault and streaming the minted shares (ERC20 compliant, exchange-rate) will in theory add support for streaming e.g. Wrapped aUSDC.

As per this 4626 Alliance page there already are a bunch of adapters written for popular tokens. If we can get some that are already audited, that's even better!

Topic 2 - Improving UX with wrap/unwrap

While 4626 solves the compatibility problem, there's still a UX problem at hand: the wrapping and unwrapping mechanisms. Normally, a sender would have to go to etherscan or a dedicated UI to wrap their aUSDC in aUSDC4626, create a stream with the new asset, while the recipient would have to perform the inverse actions: withdraw and unwrap.

For the sender, we could introduce a new method in the target contract which does the wrapping and stream creation, similar to how the protocol periphery already handles ETH to wETH. For the recipient though, the solution isn't this straightforward.

Topic 3 - Bonus: Creating special logic for yield/interest

Some users have been asking for a different yield split (e.g. instead of the recipient getting the yield, it would be the sender who gets it). With some custom logic and state management this could be achieved using a special kind of wrapping.

Initial thoughts on this:

• a wrapper contract could store the exchange-rate upon deposit and distribute underlying funds upon withdraw based on the exchange rate at that moment
• this may cause positions in the "wrapper" contract to be non fungible (would 4626 still be good here?)

[PaulRBerg]

As discussed on the phone last week, it is not possible to implement this feature without modifying V2 Core:

https://github.com/sablier-labs/v2-core/issues/643

The only exception is the monthly-stream-creation automation via Gelato, but we have sufficient user validation that that approach is not worth pursuing:

I would prefer just a single continuous stream still though.

That is, the above could be a useful hack workaround, but if a competitor implements endless streaming I would leave for that.

[50shadesofgwei]

Some preliminary thoughts:

• Given that the problem of taking yield generated and separating its distribution across the lines of 'already streamed' vs 'yet to stream' is a pretty difficult one, could initial progress be made by attempting to split the problem into its two constituent parts? That is to say, maybe creating a 'sender interest' stream type where all generated yield goes to the creator of the stream (so the interested companies are satisfied) and a separate 'receiver interest' stream type where generated yield goes to receiver would be a more readily implementable instantiation of the idea.
  Obviously this comes at the cost of not being able to optimise for both parties at the same time, but hey progress is progress

• re @PaulRBerg's point of having a modular plugin system, from a perfect engineering perspective that's definitely the right thing to do and to the user's eye will look the cleanest and the most in-line with general DeFi composability values, etc. Saying that, if I may be excused the following assumptions:

1. Chosen sources of yield that are going to be used will likely be Pareto-distributed, meaning the number of people who chose to use aUSDC or the DSR as the backend yield plugin are going to outnumber the ones who'd prefer to use some niche curve pool by a fair bit
2. If we were to rephrase 'bespoke integrations' as 'partnership opportunities' there might be a possibility for co-marketing thing to run with
3. We could maybe even offload any future integrations' dev work onto the interested party (i.e yield protocol X wants to plug in on the backend, leave that up to them and then have a 'custom' or 'third-party' option for yield source on the frontend if a user wanted to use it). Sorta like the Uniswap hooks thing
4. Openness to writing new contracts

Maybe we could create a kind of intermediary product where when a user wants to access USDC yield on a stream, they can click a 'yield' slider and then choose from a handful of whitelisted sources (Aave, Maker, etc) and then all the function calls are handled on the backend so their USDC is deposited into the relevant contract and such. Furthermore, we could continue to use just USDC as the token that the user sees - reason being if you're getting paid in USDC its already enough of a hassle going from on chain USDC to money in a bank account without having to add another step (converting cUSDC/aUSDC back to USDC) to the mix as well.

Please let me know if what i'm suggesting here is along the lines of what is likely to be feasible, I'll be the first to admit my ignorance on how stuff is progressing behind the scenes.

[PaulRBerg]

Thanks for the detailed write-up, @50shadesofgwei. On your preliminary thoughts:

On the first point. Sorry, we were not super clear in the original posts. The intention all along was to only give the yield to the sender. This tweet might give some further clarity.

On the other points. I generally agree that we should focus on the big guns, i.e., Aave and DSR. But otherwise, I don't quite follow your proposal. Are you against that the modular system I proposed in https://github.com/sablier-labs/v2-core/issues/643? Or do you agree that that would be the right approach, though we should only build a few modules to start with?

Re yield slider - interesting idea, but that's a UI-centric feature, and we typically discuss UI features in our Canny board. That said, I agree that abstracting away the vault token conversion would be helpful.

[50shadesofgwei]

re: sell vs receiver side interest - I don't think I did enough research into the conversation before chiming in haha, but yes, I see; I can definitely see why sender-side interest streams would be a cool USP for the protocol, especially to larger projects for whom said value would be quite considerable. Unfortunately no quick-fix solutions spring to mind at the moment, although I'd happily jump in on any discussions about how to build them so please do reach out if an additional voice would be welcome. Digressing somewhat I guess the receiver-side interest streams would maybe even be a separate product entirely, not in line with the original idea but still something that could deliver value on its own merits. From a personal standpoint, if there was a such an option it's definitely something I'd use on any streams I had.

re: modularity - sorry for confusion, i'm in agreement that the optimal product is absolutely a modular system wherein backend yield sources are arbitrarily customisable; as a DeFi user myself that's the kind of composability I love to see protocols facilitate. The suggestion about hardcoding to start with is exactly as you said, it's a kind of starting point upon which a more developed/malleable product can be built on top in the future. MVP would be the big guns, and the final product would be the fully composable one (maybe with a couple other integrations in between to get some PR boosts). So yeah not two mutually exclusive products, more like the same overarching thing stretched along a time axis

Also i forgot to say but congrats on the v2 launch, great stuff

[PaulRBerg]

Thanks again for sharing your thoughts @50shadesofgwei. Also for the kind words, we are indeed proud of V2.

The receiver side is fairly easy to handle - you just ask the sender to wrap their tokens into an ERC-4626 vault, and use the Sablier contracts as the are written today.