Flash loans as a potential deterrent for vesting users

[PaulRBerg]

During my work on adding support for ERC-3156 flash loans in the SablierV2Lockup contracts (see #277), I thought about the following scenario.

Imagine you have just launched your token and you have a governance system in place, which allows token holders to vote on proposals. Imagine that you hear about Sablier and you are interested to set up streams for your team and your investors.

Now, someone tells you that the Sablier V2 contract admin has the ability to turn on flash loans for any token being streamed via the Sablier V2 protocol.

How would you react to this?

The rational answer should be that you don't care - your governance system is presumably flash-loan resistant, lest the system is guaranteed to break in the future, e.g. when creating a lending market on Aave for your token.

However, people can sometimes be irrational, and their knee-jerk reaction might be to eschew using Sablier just because of the possibility of flash loans being turned on. One doesn't have to assume that the contract admin is malicious - assuming that the admin key can be compromised suffices in this context.

Therefore, I wish to re-consider the flash loanability idea and/ or implementation. As much as I am on board with the revenue-generating benefits of flash loans, I wonder if this will not end up losing us users, and thus earning less broker and protocol fees in the long-term.

One potential workaround is to limit the flash loans to a stablecoin allowlist - we would hard-code the addresses of USDC, DAI, etc., in the contract constructor. This is not obviously not great, since it would add additional complexity in contracts that are otherwise already complex, and it would also limit the protocol to a few asset addresses that might change in the future, but the idea makes sense.

I would be very curious to hear your thoughts on this concern - @razgraf, @maxdesalle, and @andreivladbrg.

[maxdesalle]

Very good point! Would definitely understand how some users wouldn't be OK with the flash-loan ability the protocol has regarding their token.

IMO, it would be unfortunate to completely remove it as it's a clear revenue stream, and no one will complain about it (on the contrary) if we do it for stablecoins only. Problem is we can't just tell people "trust us, we will only ever allow flash loans for stablecoins", so we will have to hard code it in the contracts as you said, I guess.

[PaulRBerg]

Thanks for your input, Max.

we can't just tell people "trust us, we will only ever allow flash loans for stablecoins",

Precisely.

[razgraf]

Interesting case but I don't see it as a reason to remove loans entirely.

1. With a good decision process, it will not be a deterrent. Enabling FLs will be done only after a formal vote/temp-check. We could engineer this as a weighted vote (off-chain) where streamers of that particular token have a multiplier, such that their governance has a bigger voice. At any rate, this is something new asset managers have to consider with any DeFi app with loans. What about performing an FL through Uniswap / open Aave markets. Do they limit access? Is it our job to do this?
2. FLs are useful for stables and very popular assets. Not sure what the usage is on other protocols for low-mcap assets. I speculate this is a case of asymmetry between assets, where having FLs for stables is great, while having it for other assets is just not worth it yet. Therefore, the impact of loans on exotic assets is low, even on the off-chance that they are enabled against that asset manager's (e.g. DAO) wish.
3. The trust aspect is a reality of any project with admin rights before decentralized governance. It's a temporary safety feature, not a bug. Even so, using it for bad things is a double-edged sword. If Sablier intentionally does something to hurt a project, why would anyone else trust Sablier after that?

---

Possible solution for these "trust assumptions"

A time-lock contract can be designated the "manager" for the flash-loan mapping. This contract will lock the ability to change the list to anything other than USDC/DAI/3CRV for a period of 2-3 years. This gives us time to properly understand the economic risks while also earning fees on stables.

[PaulRBerg]

Thanks for your feedback.

Replies

1. There are actually two points here so I will reply to each one separately.
   1.1 We can't have any "good" decision process (formal votes, temp checks, etc.) until we decentralize the governance system, which we don't expect to do soon.
   1.2 Indeed, the flash loanability of an ERC-20 asset is inevitable in DeFi. However, I was specifically referring to the fact that for some users Sablier may be their "entrypoint" in DeFi - that is, the Sablier smart contracts are the first external contracts those tokens are sitting in (as they are vested). This is a more sensitive scenario and might lead some users to irrational behaviour.
2. I don't follow your reasoning here, unfortunately. That the "impact on exotic assets is low" is a moot point (assuming you meant there will not be much demand for flash loaning those asset) - the trouble is the flash loanability of the asset itself, the possibility that it can be flash loaned, which might be a deterrent in and of itself.
3. This is perhaps our strongest argument in favor of keeping flash loans. We have no financial incentive to enable flash loans against the user's wish, since they would pull the tokens out of Sablier - in fact, we will make it clear in the docs that flash loans are available only for stablecoins in the early stages of the protocol.

A time-lock contract can be designated the "manager" for the flash-loan mapping.

Nice idea but implementing and test-proofing this would take a long time and we don't have that time now, unfortunately.

My Thoughts

Drawing on the points above, I am of the opinion that we should just stick with the flash loans as they are implemented in #277. There are so many upgradeable protocols out there - by comparison, Sablier V2 is harmless, with or without the possibility of flash loans.

[andreivladbrg]

Same here I don't see why we would completely remove flash loans because of some potentials "knee-jerk reaction", we should focus on the "The rational answer".

This contract will lock the ability to change the list to anything other than USDC/DAI/3CRV for a period of 2-3 years.

I like this idea, but 2-3 years would be a little too much IMO, 1 year should be fine.

Random idea

Going to say at first that is quite complex.

In the actual implementation of the flashLoan we check if the amount parameter is greater than the ERC20 balance of the asset parameter in our contract, but what if we limit the amount to be less than a getWithdrawableAmountAllStreamIdsForAnAsset method which returns the maximum value that can be withdrawn by all recipients. Ofc this would be necessary for the non stablecoins/WETH/WBTC assets.

[PaulRBerg]

Agree that we should dwell on the rational case. In case it wasn't obvious - I'm opening these discussions with the goal of teasing apart the subject matter as much as possible.

Interesting idea, but the problem is that we don't have a reverse mapping between users or assets and stream ids, so we can't do this (see related discussion here). In simpler terms, what I mean is that we don't know all the streams that have been created with a given asset, or by a given user - to be able to do this, we would have to add a new storage mapping, or two (See Are there well-solved and simple storage patterns for Solidity?).

[andreivladbrg]

I think there are multiple solutions for how to implement a getWithdrawableAmountAllStreamIdsForAnAsset method. IMO, the most elegant one would be to implement a factory pattern, each Sablier instance representing a token. Though I am aware that this solution would require a big refactor, so most likely we would not do this.

[PaulRBerg]

Locking since we have landed on a soft agreement to keep flash loans.