cancelAndCreate functions

[PaulRBerg]

A frequent feature request we frequently receive from users is the ability to "edit" or "top up" an ongoing stream. Oftentimes, users don't know exactly what they want when they make this feature request - some people mean to change the payment rate per second while keeping the deposit amount intact, while others refer to the ability to edit certain lockup-specific properties like the total amount, end time, etc. It is the latter use case that I will target with this discussion.

There are multiple ways to implement this functionality. One way is to add an edit function that literally updates the properties of an going stream struct. However, this would be difficult to implement, and it would introduce new security assumptions in the protocol, which seem unnecessary in light of the other alternatives.

Another way is to add a cancelAndCreate function in a PRBProxy-backed target contract. Note that this has to be PRBProxy because the msg.sender would have to be PRBProxy itself, otherwise the stream couldn't be cancelled.

Yet another way would be to implement a cancelAndCreate function (or functions) in the core contracts themselves, which would simply call the cancel and the create function(s) one after each other.

Finally, we could also just abstract this at the frontend level, though this would mean having the user sign two transactions (pre Account Abstraction, at least).

[maxdesalle]

I think it's pretty clear that this should be done at the contract level, and not at the interface level. If someone wants to programmatically interact with the contracts and needs this feature, it would be very unfortunate that they would have to add friction in their script just because we only support it at the interface level.

Because of that, the best option is probably one of these two:

Another way is to add a cancelAndCreate function in a PRBProxy-backed target contract. Note that this has to be PRBProxy because the msg.sender would have to be PRBProxy itself, otherwise the stream couldn't be cancelled.

Yet another way would be to implement a cancelAndCreate function (or functions) in the core contracts themselves, which would simply call the cancel and the create function(s) one after each other.

I don't know enough about the contracts themselves and Solidity in order to judge what the best solution is here.

[PaulRBerg]

Thanks for sharing your thoughts, Max. I agree that this should be done at the contract level. I will have a think and decide what option to go with shortly.

[razgraf]

On the contract level argument, it has to be a separate contract. A periphery not a core. We need to engineer this such that linear contracts can be converted to pro contracts and back. Not to mention the fact that this can also serve as a "zap" migrate function in case we upgrade to a v2.1 at any point.

[PaulRBerg]

What steps does one need to take ...

Rearchitect the entire Sablier protocol to be PRBProxy-centric.

It might helpful to jump on a call to discuss this topic.

My StackExchange post about DSProxy is also a good reading material.

[PaulRBerg]

I'm sure we can find a way to do it without the need for a proxy 👍

Yes - by creating a custom permissions system that has to be manually tested and does the exact same thing as the proxy in a more isolated and error-prone way.

We should jump on a call.

[razgraf]

Or, implement a transferSendership method :D this way, in a zap, the periphery can become the sender, cancel and create.

[PaulRBerg]

This wouldn't work because the sender would have to sign two txs: one for transferSendership, and another one for the periphery function, which means we're back to square one. Why not call cancel and create directly?

Accsss control in Ethereum is a mess, because Ethereum doesn't offer account abstraction (unlike Fuel, which does).

The only tenable and scalable way to offer "zap-like" functionality is to use a proxy pattern, and PRBProxy is the best of the lot in terms of features and security.

[razgraf]

Yeah true...

[PaulRBerg]

Locking, as we have landed on a soft agreement to use the proxy approach.

The cancelAndCreate functions won't be implemented in v2-core anymore.