pause() functionality to temporarily pause the stream

[smol-ninja]

How about we add a pause() function? It is technically similar to cancel except that there is no refund. This function can be used as a solution to Discussion: Scheduled paused periods to enable unpaid time off.

/// @notice Pauses the stream by setting ratePerSecond = 0.
///
/// @dev Emits a {PauseOpenEndedStream} event.
///
/// Requirements:
/// - `msg.sender` must be the stream's sender.
///
/// @param streamId The id of the stream to pause.
function pause(uint256 streamID) external;

Why?

By calling pause(), the sender intends to temporarily pause the stream to continue in the future. A similar behaviour can be achieved by calling cancel() followed by restartStreamAndDeposit() but the psychological barrier to distinguish between cancelling and pausing is too high. Thus I propose to implement a pause function in Open-ended.

Unpausing

To unpause, sender can call restartStream().

[andreivladbrg]

Thanks for opening this Shub.

It was part of the initial README OP: https://github.com/sablier-labs/v2-open-ended?tab=readme-ov-file#questions

The current OE design allows only canceled streams to be restarted, so we should add a new boolean value isPaused— it is one of that things that requires an implementation first and then we should take decision.

If the gas cost and the complexity (introducing a new attack vector) aren't problematic, I am in favor of adding a pause function.

[smol-ninja]

Why can't sender get a refund from an already canceled stream? I assume thats because the current design makes assumption that cancel would refund the amount to the sender so there is no amount left for refund. Is that right?

[andreivladbrg]

Yes, and with the current design, another assumption is that if a stream is canceled, the only action that can be taken is to restart the stream.

[smol-ninja]

I see. I am still of the opinion that we should allow refunding from streams even when isCanceled is true. I can't think of any scenario where it might be useful but in the core contracts, the simple implementation of refundFromStream should be just refunding the amount of whatever can be refunded despite the current state of the stream. Same goes with withdraw. I think it makes the core contract more flexible.

Do you have any thoughts on why refund should not be allowed after it has been canceled?

[andreivladbrg]

Do you have any thoughts on why refund should not be allowed after it has been canceled?

it doesn't make sense to allow refunding after cancel since we make the ERC20.transfer to refund all assets available in the cancel function

https://github.com/sablier-labs/v2-open-ended/blob/4405fdf6485723149abc2dd173e7e276e78ae021/src/SablierV2OpenEnded.sol#L524-L527

[smol-ninja]

it doesn't make sense to allow refunding after cancel since we make the ERC20.transfer to refund all assets available in the cancel function.

Agree. But if we plan to implement a pause() like function where only the stream status is changed to canceled, then in that case, a refund should be allowed i.e. refundFromStream() will not have notCanceled(streamId) modifier anymore.

[PaulRBerg]

@smol-ninja feel free to tag @sablier-labs/solidity (or the other teams) so that we all get email notifications when you open discussions or issues like this.

[smol-ninja]

Sure.

[andreivladbrg]

After thinking more about this, I came to the conclusion that we can remove the cancel function in favor of the pause one.

To achieve the same flow as the current cancel function, we can implement a refundAndPause function. Although making this change would increase the gas to achieve the same flow, I consider it to be safer this way because the complexity is not increased(less vector attacks).

In the UI we can still call it "cancel", but underneath it would call refundAndPause

wdyt? @sablier-labs/solidity @razgraf

[andreivladbrg]

If we do so, the API would be circling around these main methods:

• create
• deposit
• adjustRatePerSecond
• pause
• refund
• unpause (or restart)
• withdraw

Then, we can "juggle" between them:

• createAndDeposit
• refundAndPause
• unpauseAndDeposit
  and the batch methods, etc.

[smol-ninja]

I am highly in favour of this. This will not only simplify the protocol design but also make it very flexible to fit into several use cases and requirements of the user. Have simple functions that only do one job and then use batch functions to perform multiple actions in a single transaction.

Then after launch, we can learn from the user experience and optimize the batch functions that are frequently used by natively implementing them.

Note: We should also abstract away sender refund from other functions too such as adjustRatePerSecond.

[andreivladbrg]

I am highly in favour of this.

Thanks

This will not only simplify the protocol design but also make it very flexible to fit into several use cases and requirements of the user

Correct

Note: We should also abstract away sender refund from other functions too such as adjustRatePerSecond

I am afraid that this is not correct - there is no refund for the sender in adjustRatePerSecond

[smol-ninja]

You are absolutely right.

[PaulRBerg]

Cogent proposal @andreivladbrg. Makes complete sense.

• Separation of concerns ✅
• Fewer attack vectors ✅

As I've argued here, gas costs are less relevant for OpenEnded than they are for Lockup. So the marginal increase in gas costs brought about by this pause function shouldn't worry us.

[andreivladbrg]

Assuming that the "love" reaction of the message above is an agreement by @razgraf I created this issue and I will close this discussion

[razgraf]

Yes ser, thank you!