The authorization system is not needed anymore

[PaulRBerg]

Introduction

My understanding is that we had initially wanted an allowance system similar to ERC-20's transfer approval flow because we thought we need it for our periphery contracts. But does that assumption hold water?

Let's explore the user flow in three cases. I shall assume that Alice wishes to create one $USDC stream toward Bob. What I refer to by "periphery contract" is either a bespoke implementation or an instance of PRBProxy (the logic is the same).

1. Authorization

1. Alice authorizes the periphery contract Foo to create Sablier streams on her behalf.
2. Alice approves the Sablier contract to spend her $USDC balance (this step is still necessary because the ERC-20 contract knows nothing about the Sablier authorization flow).
3. Alice calls a function on Foo to create the stream, and Foo creates it on her behalf.

2. Standard Transfer From

1. Alice authorizes the periphery contract to spend her $USDC balance.
2. Alice calls a function on Foo to create the stream, Foo transfers the tokens from her to it, and then creates the stream on her behalf by setting the sender argument to be Alice's address.

3. EIP-2612 Permit

This only works with ERC-20 tokens compatible with EIP-2612.

1. Alice signs a transaction data blob off-chain. Notably, this step is not a transaction (unlike all others).
2. Alice calls a function on Foo to create the stream with a signature (see this as an example for how I implemented permit signatures at Hifi). Foo then creates the stream on her behalf by setting the sender argument to be Alice's address.

Conclusion

It turns out that the authorization system is the worst UX of all, because there are 3 separate transactions needed for creating the stream. EIP-2612 permit is the best, but few ERC-20 tokens support it, and the frontend implementation is non-trivial.

The only case that I can think of when the 1st method would be useful is when a DeFi protocol integrates Sablier V2 and, for some reason or another, they would also like their users to create the Sablier streams on their UI. But still, I don't see why they wouldn't go with the 2nd method described above.

Therefore, I would suggest sticking with the standard transferFrom flow and completely remove the authorization system from our contracts. It adds undue complexity, which costs time and money (remember we want to audit this). We can still keep a copy of the current logic on an archive branch, for historical purposes.

[andreivladbrg]

Today I thought about this issue and I tend to agree with you on the idea of ​​removing the authorization system. These two are mainly my concern:

1. It adds a lot of complexity to the protocol, which could create more problems in the future compared to the utility of the feature.
2. A very bad UX.

[PaulRBerg]

Locking, it's been a long time since we removed our custom made authorization system.