Consider scraping off the ability of the sender to withdraw on behalf of the recipient

[PaulRBerg]

Problem

One of the findings reported by Cantina during their 1st review of the code base has come back to bite us.

During my call with NFTFI.com yesterday to discuss a Sablier V2 integration, it became apparent that allowing the sender to withdraw makes the integration difficult.

NFTFI has an escrow smart contract where people lock up their NFTs after making a borrow against them. Unfortunately, this contract cannot react to incoming ERC-20 deposits, and it can neither detect increases in ERC-20 balances over time. Consequently, the funds would be forever lost if a sender performs a withdrawal while the NFT sits in this escrow.

It is likely that NFTFI is not the only NFT platform that cannot react to/ account for sender withdrawals.

Solution

Scrape off the ability of the sender to withdraw on behalf of the recipient.

Of course, doing so would mean that funds are forever lost if the sender has accidentally started a stream to an address that cannot interact with Sablier, such as an exchange address. There are two ways to go about this problem:

1. We just accept it and make the warning more prominent in the create stream form (although this would also pose problems for integrations)
2. We implement a permissioned relayer module whereby the Sablier multisig can allow particular accounts to withdraw on behalf of any Sablier user

Side note: it might be worth it to perform some data crunching to see how many sender-initiated withdrawals there have been in V1 and V2.

[maxdesalle]

We just accept it and make the warning more prominent in the create stream form (although this would also pose problems for integrations)

I think this is an acceptable tradeoff. Worth noting that for traditional transactions, the sender cannot withdraw either. Once the money is gone, the money is gone. People in crypto have grown accustomed to that, I think, so it's not a problem.

We implement a permissioned relayer module whereby the Sablier multisig can allow particular accounts to withdraw on behalf of any Sablier user

This is a bad idea, in my opinion. Just the possibility of being able to do so via a multisig would get a lot of our users to lose trust in our protocol. Full immutability matters, and a system is only as decentralized as its most centralized component.

[PaulRBerg]

And the more I think about it, the more important the automation aspect seems to be.

We're putting quite a bit of strain on recipients to have to use our UI to claim manually - there may be use cases where automatic withdrawals are a better fit.

[PaulRBerg]

But anyway this particular discussion is about disabling sender withdrawals.

I will follow up in #155

[maxdesalle]

After re-reading the whole conversation here, I changed my mind! I'm in soft agreement with the relayer idea.

[razgraf]

Could you explain in more details how would this work?

You mean the example with regular vs enterprise users? Hmm, while I don't like this solution - probably separate contracts: one with no default relayers (for the public) and one with default relayers and more control to "managers". Just an idea.

[PaulRBerg]

I changed my mind! I'm in soft agreement with the relayer idea.

Awesome

probably separate contracts: one with no default relayers (for the public) and one with default relayers and more control to "managers"

Yeah this would be fairly complicated.

[razgraf]

Following our conversation in the thread above:

While I would definitely not downplay the trust implications any controlled system would bring, I can understand that for some the majority of users this can be a good feature and potentially a backup in case of human errors (e.g. sending to an exchange wallet).

Can we, by any chance, include something like a managed flag, where the stream recipient has the ability to opt-in/opt-out of this default relayer support (or even all operator support it that's easier)? I'm thinking this way, if we have someone that really wants full control over their stream, they can just opt-out of any pre-configured 3rd party management.

[maxdesalle]

Can we, by any chance, include something like a managed flag, where the stream recipient has the ability to opt-in/opt-out of this default relayer support (or even all operator support it that's easier)? I'm thinking this way, if we have someone that really wants full control over their stream, they can just opt-out of any pre-configured 3rd party management.

This is the right approach! Great idea.

[PaulRBerg]

While I would definitely not downplay the trust implications any controlled system would bring

I would downplay them in the short and the medium-term.

Rollup risk > smart contract protocol risk

Our little feature pales in comparison with the fact that the Arbitrum and Optimism multisig can rug-pull all users.

I can understand that for some the majority of users, this can be a good feature and potentially a backup in case of human errors

Awesome

Can we, by any chance, include something like a managed flag

Good idea. I would just let users specify a global disabledRelayers mapping, which is by default set to false, but can be manually set to true.

[PaulRBerg]

Feedback provided by Jorge from Unlockd:

With our V2 we don't need to disable withdrawals. Our new features solve this without any changes required but it's a bit long to explain here. Will send a voicenote in a bit

Refer to #684 (comment) for more context on what Jorge said in the voice note.

[PaulRBerg]

Closing as per the rationale given here.