How to handle cancellations triggered by recipients

[PaulRBerg]

Problem Situation

The cancel function in v2-core can be called by either the sender or the recipient:

https://github.com/sablierhq/v2-core/blob/3883400911f5ec3a65f7a06deb0320e1835dd5c4/src/SablierV2LockupLinear.sol#L293

On cancellation, funds are auto-transferred to the sender and the recipient. In a non-proxy world, this wasn't an issue since the sender of the stream would receive the tokens in their typical wallet. But with a proxy, this is problematic because the funds would remain in the proxy itself. This is a con of the proxy approach I omitted when I wrote #11.

Solutions

1. Allow only the sender to cancel.
2. Implement a page in the UI that lets senders see their claimable balance from the proxy, nothing that we might have to do this at any rate. This is similar to providing a wrap/ unwrap UI for WETH, because there can be many causes for having funds locked in the proxy, e.g. bugs in proxy targets or rounding errors.
3. Write a special-purpose target contract that will be called via deployAndExecute in the BUI. This target would install a special plugin, which would implement the ISablierV2LockupSender interface, auto-transferring the senderAmount to the proxy owner.

My Thoughts

The first option is the easiest, but I am uncomfortable taking the cancel functionality away from recipients. This is in the category of permissionless "escape hatches" that can help prevent accidental losses of funds.

The second option would demand more development cycles from the frontend team, but it would provide our users with a utility that would be super useful to PRBProxy owners.

The third option would be the most elegant, but it would demand more effort from the contracts team. In the UI, little would change; they'd just have to call deployAndExecute instead of deploy. The plugin would run autonomously every time a recipient cancels a stream, and the funds would be auto-transferred to the proxy owner.

Your Thoughts

WDYT?

[razgraf]

Feedback

1. Not sure I understand the first option: cancel would return the funds to the recipient (probably EOA) and to the sender (a proxy), no matter who calls it.

2. The second option would imply bad UX. The proxy would now act as not just an intermediary (almost unseen to the user) but as an escrow/middleware-wallet sort of thing. We should try to make everything "zappy" i.e. not too many steps required for any action in Sablier.

(Note: I understand that errors may cause the proxy to retain funds, but this is a bug not a feature we should rely on.)

3. The third option is interesting, could maybe plug into our callback architecture? Although I cannot quantify how complex of a job this could be.

[PaulRBerg]

cancel would return the funds to the recipient (probably EOA) and to the sender (a proxy), no matter who calls it.

Yes, but we would call the core function cancel through a mirrored cancel function in the proxy target, which would forward the tokens back to the proxy owner.

This would only continue to be a problem for third-party UI integrations (if they go with the proxy approach, which they might not do).

as an escrow/middleware-wallet sort of thing.

Well, that's exactly what it is. Blame Ethereum for lacking support for transaction composing (Fuel offers native support for this in a neat way, with scripts).

As I said in the OP, there are many possible ways in which the proxy can end up having funds locked in it, so we should consider offering a simple UI for claiming these tokens.

but this is a bug not a feature we should rely on

Agree. But errors will continue to happen nonetheless.

Anyway - I agree that this UI for claiming need not be a priority. I'm just flagging this, so you know about the problem situation.

maybe plug into our callback architecture

That's exactly my proposal, to rely on the cancellation hooks.

I cannot quantify how complex of a job this could be.

Quite simple from your end; more work to do from our side.

[PaulRBerg]

Closing, we resolved this via #27 and #38.