Integrate With Compound & cStreams

[apbendi]

• Convert Dai tribute to cDai held by GuildBank
• Convert grants to cStreams

[mds1]

Given that Sablier does not support aTokens, do we want to switch back to rDAI?

[apbendi]

So, rDai is also listed in the Sablier UI but my gut tells me it would have similar issues.

Sorry for the tag out of the blue @PaulRBerg, but I'm curious, does rDai have the same issue as aDai in terms of dynamic balances? Unlike aTokens, rTokens don't update dynamically, but they do update balances when triggered by certain actions.

Regarding what we can do with Endaoment, I think we have a few choices:

1. One would be to integrate Aave such that the GuildBank holds aDai, earning interest for itself, then converts that aDai to Dai to fund the stream.
2. Another would be to integrate with Compound and hold cDai, which we can stream with cStreams from Sablier and either:
   a. Redirect stream interest back to the Endaoment
   b. Redirect stream interest to the grantee
   c. Do some kind of split— possibly configurable?
3. Somehow support both, possibly configurable, or possibly by holding aDai then converting to cDai so we can still get interest while streaming (boy, this is getting complicated!)

I think option 1 would be the easiest because the math is really easy for aTokens. Open to other ideas.

[mds1]

Thinking about this more, I think you're right @apbendi—rDAI would also have issues.

Here's my understanding of how Sablier would work with rDAI, given that it seems all Sablier streams are managed by a single contract, and that contract holds all funds that are being streamed.

Brief rDAI refresher:

• 1 rDAI = 1 DAI
• With rDAI, you assign a "hat" to an address. A hat is just a rule defining what addresses interest should go to, and in what percentages interest should be split between those addresses.
• Each address can only have 1 hat. If I use rTrees that will let me assign a hat to my address which points all my rDAI interest to rTrees. If I then use High Priests they will have me assigned a new hat, and rTrees no longer gets my interest. This is what they call the "hat yanking problem". There's a few workarounds to this (v2 should have a better solution)
• Interest is not actually received by recipients until someone calls rDAI.payInterest(owner) (anyone can call this on behalf of interest owner)

So, if all rDAI being streamed is held in Sablier's contract at 0xA4fc358455Febe425536fd1878bE67FfDBDEC59a, then we need to properly set its hat. In theory, every time someone starts or cancels an rDAI stream, the Sablier contract can assign itself a new hat that allocates its interest proportionally to stream amounts of all recipients (this is one solution to the hat yanking problem). Alternatively, it could set its hat each time to enable functionality similar to cStreams. However, right now it seems Sablier does not support setting its own hat, so by default all interest earned while streaming rDAI would go to Sablier itself (this is a hatID of zero, which is the default)

That interest would be earned by the Sablier contract once anyone calls rDAI.payInterest(0xA4fc358455Febe425536fd1878bE67FfDBDEC59a). But since (from a quick glance) there is no way for Sablier to recover arbitrary tokens sent to the contract, accrued interest would be stuck.

So, I'm pretty sure rDAI is not supported either unfortunately

[mds1]

In terms of endaoment:

One would be to integrate Aave such that the GuildBank holds aDai, earning interest for itself, then converts that aDai to Dai to fund the stream.

I agree this option is the easiest to implement. The one thing I don't like is that no one is earning interest during the stream, which seems a bit wasteful. Also, depending on gas costs, interest rates, and stream amount/duration, there is a chance that going from Dai > aDAI > Dai costs more in gas than you'd earn in interest.

Another would be to integrate with Compound and hold cDai, which we can stream with cStreams from Sablier

I prefer this option and think it's a bit cleaner to implement. cTokens have nice helper functions that make it easy to convert balances between Dai and cDAI, so we can denominate everything in Dai on the frontend but stream cDAI. And the compounding streams Sablier function you mentioned would effectively provide the rDAI functionality we need (its more limiting, but sufficient for our use case).

[apbendi]

Amazing research on the rDai Sablier situation. Everything you've said makes sense and seems right to me.

Also, depending on gas costs, interest rates, and stream amount/duration, there is a chance that going from Dai > aDAI > Dai costs more in gas than you'd earn in interest.

Ooof true. Good point.

And the compounding streams Sablier function you mentioned would effectively provide the rDAI functionality we need (its more limiting, but sufficient for our use case).

Alright, going to take a stab at it. Will update this issue to track that change so we maintain context of this conversation.

[PaulRBerg]

Hey guys, please pardon my belated reply.

@mds1, that was a fantastic breakdown of the issues Sablier v1 has with rDai. I just talked with my co-founder now and we're going to remove aDai and rDAi from our UI. Thanks so much for your reporting, really.

Related to what would be the best solution for Endaoment, I'd definitely go with cTokens, as we have native support for Compound and you can easily split the interest between the payer and the recipient. In this case, you can even go a step further and split in n-ways, since the payer is the DAO contract itself (I guess that's the point with DAOs, no?).

---

As a side note, I find this issue of dynamical balances rather interesting. Funnily enough, we're also going to use them in Sablier v2. I wonder whether there's room for an EIP or some kind of community initiative on ethresear.ch to agree on a standard for how ERC20 balances should be handled. Without one, there's certainly going to be a helluva lot of money stuck in contracts, over the long haul.