Should there be an end date to open ended streams?

[smol-ninja]

@razgraf shared the following idea in Slack:

Another thing that will be challenging will be the mental-model around end-dates and possible end-dated. E.g. let's say I pay an employee, but then they just announced they're leaving the company next month. I still wanna pay their salary, but on the 1st of next month I want that stream to stop

Currently, this behaviour can be achieved by the following (cc @andreivladbrg):

1. Sender only deposits the necessary withdrawable amount
2. Sender calls cancel after 1 month which sets rps to zero. In case sender doesn't call the cancel, the stream will continue to accumulate debt but recipient wouldn't be able to withdraw anything.

However, @razgraf pointed out that this might be a visual/cognitive blocker for users.

I have two comments on this:

• Having an end date wouldn't do justice to "open ended" name (just saying).
• With an end date, it can possibly compete Lockup Linear streams. The only difference between the two would be the flexibility for sender to deposit funds into stream anytime they want and I think OE may have an advantage over LL streams.

Other ideas to implement this feature:

1. This can be automated with tools like gelato since cancel function can be called anytime by the sender (cc @andreivladbrg)
2. We can implement execution via signatures in cancel that means sender can submit a signed data through the UI which can be used to execute cancel on their behalf but only after a specified date.

[razgraf]

Oh thank you Shub! Was just writing a discussion myself on this. Pasting here.

While the debt system allows for a stream to stop its funding requirements and simply "exist", I believe we should also provide a way for people to choose an "end date".

The use-case for payroll is: imagine you have an employee you've been paying with Sablier for 2 years, and they announce they're leaving next month. You'd want the payroll stream to work until the 1st of the next month, but then it should stop. Options:

1. You do nothing, and start accruing debt - some sort of a soft-close. There's also no way (I think) for a UI to understand that stream has been softly terminated, so it will simply keep existing in your dashboard.
2. You setup this "end date" which sets the rate-per-second to zero on a given date.

This end date could be editable (so you can extend it ... maybe only before it's reached).

---

The advantage of having a clear "close" (through a close-stream action, as well as a "set end date in the future" action) is that it lessens the burden of having to time your cancellation, as well as the cognitive load of accrued debt.

---

On the OP:

Having an end date wouldn't do justice to "open ended" name (just saying).

Yes, but we can rebrand or still keep open-ended as a core feature, while offering this end-date as an advanced setting. It provides flexibility.

With an end date, it can possibly compete Lockup Linear streams.

I agree. But is that a bad thing?

This can be automated with tools like gelato

Yup. Although having it inside the core means one less dependency and less coordination cost with an external tool (who pays for the gas, what happens if the tx is not included in a block etc.).

[smol-ninja]

But is that a bad thing?

Not at all.

I am in favour of this proposal of having an optional end date for open-ended streams. It will make core contracts more flexible and open for experimentation with new use cases that we have not anticipated yet.

[smol-ninja]

In the current open ended design, with no definition of end date, streams are always cancelable. By having an end date, do you think we would need them to be non-cancelable as well?

[razgraf]

That's a good question - it would give us an extra-feature but I'm not sure non-cancelability as a principle works when there are no guarantees about the resources a stream runs on.

[smol-ninja]

Peteris asked to have an end date: https://github.com/sablier-labs/v2-open-ended/discussions/67. This also brings another question: Should there be a start date to open-ended streams?

[andreivladbrg]

great suggestion, i like "insolvency time"

[smol-ninja]

It can be confused for an actual, literal end time whereby the stream would stop accumulating debt

Thats what end time is supposed to be. End time is a time when the stream stops accumulating debt. I do agree with your point that it can create confusion.

Among your ideas, I like the ones that contain "terminate" as it, technically speaking, terminates the stream. @andreivladbrg as per ChatGPT, insolvency time is the time when a person can no longer pay his debt i.e. in this context, it would not be appropriate as sender can still pay the debt. It is more appropriate when sender / recipient makes the stream void because they can no longer pay each other. If you agree, I am happy to call it "termination time".

[PaulRBerg]

See my latest comment below. depletion time has grown on me, and I think it's clearer than termination time.

[PaulRBerg]

End time is a time when the stream stops accumulating debt

Isn't it more than that? An actual end time would either stop accumulating debt or stop making payments despite there being a deposit left.

[smol-ninja]

What do you mean by "stop making payments"? Does it mean the recipient won't be able to withdraw the already streamed amount? Or does it mean that the stream will stop streaming assets to the recipient?

If it's the latter that you meant, then the way debt stops accruing is by setting ratePerSecond to zero. This also implies that stream stops streaming assets to recipients. That has been my understanding of the end time so far.

PS: I replied on the comment below.

[smol-ninja]

Should we implement the optional end date to open-ended-streams in the first release? We had Peteris asked about it specifically.

[andreivladbrg]

OK, thank you, got it.

[smol-ninja]

Good points.

didn't he say that is not mandatory?

I think it was dicey. I remember him mentioning that OZ would have a contract with them where the payment would be for 1 year. So imo, most of the open-ended streams will still have a "softly agreed" end time instead of running forever. it is also useful to keep track of which streams will end at what time in the future which I suppose they all will.

Should all streams have an end date? Isn't that contradictory to the concept of an 'open-ended' contract?

To your argument, I totally agree that it is contradictory to the name itself. But maybe we should change the name to convey it in a better way 😅. Like payroll/pay, you mentioned that it was payroll originally but we changed it because of some legal issues.

By including an optional end time, it might also confuse users with lockup but the main advantage of OE over Lockup is that it does not require upfront capital.

[andreivladbrg]

Like payroll/pay, you mentioned that it was payroll originally but we changed it because of some legal issues.

@PaulRBerg is it still the case?

[PaulRBerg]

Yeah, we can't go with Payroll. At one point, a blockchain analytics company had thought that Sablier was an employer of all of our Sablier V1.0 users. Recall that in V1.0, we had a contract called Payrol.sol.

[smol-ninja]

Thats very funny of them to assume that.

[PaulRBerg]

I've caught up on all messages in this thread. My thoughts:

There seem to be two ideas floating around: (i) implementing an actual end time and (ii) adding an informational getter that predicts the Unix timestamp when the sender's balance will be depleted to zero.

Regarding the 2nd idea, I think we all agree that the getter would be helpful. Naming-wise, I propose we go with depletion time because it is the one that most accurately reflects what's going on, and it's sufficiently distinct from anything resembling end time (by comparison, termination time is semantically closer to that).

Now, onto the 1st idea. I'm sympathetic to it, although I'm inclined to implement if off-contract via a Gelato integration. Two reasons:

1. Adds complexity.
   • Recall that any additional bit of logic in a smart contract increases the complexity and the attack surface in a non-linear way.
   • The risk of a Gelato bot failing to execute a tx seems less important than a smart contract bug.
2. We wouldn't have to change the name.

However, for the sake of brainstorming, let's suppose we will proceed with implementing this idea. I do see the benefit of an easier and more tight-knit front-end implementation.

What would the new name of the contract be? Here are some suggestions:

• Continuous
• Flow
• FlexFlow
• Everflow
• Progressive
• TopUp

---

P.S. I am against a signature-based implementation (as suggested by @smol-ninja in the OP). It seems like the most complicated of the bunch: the complexity would increase both in the smart contracts and in the UI.

[PaulRBerg]

Related discussion about changing the name: #83

[PaulRBerg]

I disagree that it adds complexity (please let me know if I failed to understand the complexity surface).

Yeah, you may be right that it wouldn't add that much complexity. But let's just prioritize go-to-market and launch without endTime - if and when users continue requesting this feature, we will implement it in a future release. Or we will integrate with Gelato.

[smol-ninja]

Agree with you.

[smol-ninja]

Can you please confirm if you agree with the below comment? I will create an issue then, especially about getDepletionTimestamp.

[PaulRBerg]

Done ser

[smol-ninja]

Have we all agreed to the following?

• Include getDepletionTimestamp function to get time when the stream starts to accumulate debt.
• Do not include endTime i.e. a timestamp when the stream's ratePerSecond starts returning 0. Instead recommend using gelato to call pause() or cancel() on the stream at endTime

If not, could you please respond to my last comment?

@sablier-labs/solidity @razgraf.

[PaulRBerg]

can you please allow ~72 hours until I can catch up with the entire thread here

[smol-ninja]

Sure. I'd also advise you to read https://github.com/sablier-labs/v2-open-ended/discussions/87#discussioncomment-9493787 regarding endTime.

[PaulRBerg]

I agree with your proposed approach.

[smol-ninja]

Issue:

• Implement getDepletionTime() #89

[smol-ninja]

Arguments in favour of having an end date (for future release): UX difficulties with unwanted debt #197.