Why is the recipient allowed to cancel a stream?

[PaulRBerg]

I've recently spoken with Fjord, who are looking to integrate Sablier to provide users with an automated, on-chain vesting service.

The topic of recipient cancellations was brought up during the call. They will create the streams from a contract, which has to be able to respond to cancellations, and so they will have to implement the onStreamCanceled hook.

Then they asked: "would it be possible to allow only the sender to cancel"? I said no and explained that we implemented the protocol this way to give maximum flexibility to recipients, e.g., maybe they wish to deny a payment.

But is this feature really that useful for recipients? Recipients could simply not withdraw from those streams that they are not interested in. Also, we could add a feature at the UI level for hiding specific streams and/ or tokens.

It seems to me that this ability of the recipient to cancel does more harm than good.

WDYT @andreivladbrg, @razgraf, @IaroslavMazur?

[andreivladbrg]

we implemented the protocol this way to give maximum flexibility to recipients

This was indeed the rationale. Initially, it seemed to be the correct way to design the protocol, which I no longer believe to be the best choice, given that it:

• Objectively complicates things for the sender.
• Adds additional complexity to the cancel function.

But is this feature really that useful for recipients?

Don't think so.

Recipients could simply not withdraw from those streams that they are not interested in.

This is not fully correct because we decided to allow the sender to call withdraw, meaning they can withdraw to recipients' addresses. Anyway, for me, this(recipients wanting to deny payments) is a weak point because anyone can, at any point, transfer any token to any address, so you might "wake up" with unwanted tokens in your wallet.

It seems to me that this ability of the recipient to cancel does more harm than good

Agree

[andreivladbrg]

I have to add another advantage of removing the recipients' ability to cancel: it would allow the elimination of the proxy plugin and archive. This is because the issue of funds getting temporary stuck in the sender’s proxy contract would no longer occur.

[PaulRBerg]

Thanks for your thoughtful reply, @andreivladbrg.

This is not fully correct because we decided to allow the sender to call withdraw, meaning they can withdraw to recipients' addresses

Correct

Anyway, for me, this .. is a weak point because anyone can, at any point, transfer any token to any address, so you might "wake up" with unwanted tokens in your wallet.

Very correct

it would allow the elimination of the proxy plugin and archive

OMG OMG you're right. Major benefit.

[PaulRBerg]

It's pretty clear to me that we should go ahead and remove the recipient's ability to cancel. I will try to include this in the audits.

WDYT @razgraf?

[razgraf]

A bit tired to think this through right now, but it does seem like removing this ability wouldn't harm the usability in any obvious way. The advantages (esp. reduced complexity by way to removing the plugins as @andreivladbrg said) are pretty great!

On the other hand, cancellation gave the recipient freedom to say no, esp. for taxable value - although, even if one comes into the unwanted ownership of a stream, they can simply write it off like a scam token or asset not to be redeemed.

Will think of this some more, but I tentatively agree with removing it.

[PaulRBerg]

Thanks @razgraf.

esp. for taxable value

Yeah but as @andreivladbrg has correctly pointed out, it is impossible to prevent taxable events. Anyone can airdrop ERC-20 tokens onto you. As a Polygon user since 2021, I know this too well.

[IaroslavMazur]

Not being able to refuse being streamed certain tokens (or from a certain sender) and having to deal with the legal accounting of each of the streams that has been opened with you as the recipient are the only disadvantages of removing the recipient-cancel functionality that I see, as well.

However, even with the ability to cancel a stream when you're the recipient, you're still "limited" to only being able to "refuse" getting streamed the token amount that's still left to be streamed (at the moment when you perform the cancelling). Whatever has already been streamed up until that point is already "yours" (good luck explaining to the public that you haven't agreed to receive those tokens 😆).

An extreme case would be "simulating" (with a short-enough stream length) a direct transfer of the respective tokens to your address, leading to you not having enough time to spot and cancel the new stream before it's Depleted.

So, allowing recipients to cancel their streams only addresses these concerns partially, anyway.

[PaulRBerg]

Whatever has already been streamed up until that point is already "yours" (good luck explaining to the public that you haven't agreed to receive those tokens

very good point

[PaulRBerg]

Just realized another reason why it didn't make sense to allow the recipient to cancel:

The recipient can transfer the NFT to a burn address.

Cc @andreivladbrg.

[andreivladbrg]

The recipient can transfer the NFT to a burn address.

Not sure what does it mean. address(0) ?

Transfers to address(0) are not allowed: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/e50c24f5839db17f46991478384bfda14acfb830/contracts/token/ERC721/ERC721.sol#L335

[PaulRBerg]

The point is that the recipient can withdraw everything streamed and then get rid of the NFT, which is equivalent to canceling.

address(0) is not the only address that can be used as a burn address. Many people use address(1), but any randomly generated address could be used for that purpose.

[andreivladbrg]

which is equivalent to canceling.

It is not equivalent to canceling, as the streaming will continue even after the NFT is transferred, regardless of whether the new owner is address(1). In this case, the funds will be lost: neither the sender (if they do not cancel) nor the recipient will receive the funds from the upcoming streaming.

[PaulRBerg]

From the recipient's point of view, it is equivalent to canceling.

But you made a good point - the sender may not notice the transfer, and this may cause trouble.

[PaulRBerg]

Closing as we have implemented this proposal in #710