Enabling closed-ended streams

[PaulRBerg]

Context

We are promoting Sablier V3 as a platform for open-ended streaming, but what if we could also enable closed-ended streaming?

Idea

Imagine streams that:

1. Have a start time
2. Have an end time
3. Are constantly monitored by the VM (just like open-ended streams)
4. If the sender runs out of money, the stream is closed
5. If the end time is reached, the stream is removed from the graph

As you can see, they are not identical to V2 streams. These closed-ended streams would not require the total amount to be deposited upfront.

Complementary Behavior

These closed-ended would be complementary to the standard open-ended streams. They would co-exist.

Implementation

I see two options for implementing this:

1. Enshrine a closed-ended streaming functionality in the VM (new or altered opcodes)
2. Application layer that schedules a stream cancelation at a specific time in the future

I favor the second option because the first would slow down the performance of the client (and there already are concerns of unbounded computational growth).

Building a scheduler app should be pretty easy. We just need to persuade an automation platform like Gelato to deploy on the Sablier chain. As far as I know, this is how Superfluid has enabled closed-ended streams for their protocol (with Gelato).

RFC

I don't consider this a high-priority feature because Sablier V2 addresses the same need. Some users may want closed-ended streams without upfront deposits, but they should be in the minority.

We can launch the chain without it and monitor demand along the way.

Cc @IaroslavMazur, @razgraf.

[IaroslavMazur]

Initially, I really liked the idea for how the proposed feature seemed to offer some extra customization to the Streamers, further increasing the usability of SabVM and differentiating it from what the rest of Sablier products have got to offer so far (V1, V2 and the in-progress EOES).

However, the more I brainstormed it, the more skepticism and criticism I've got for it.

First of all, the result targeted by the proposed feature can totally be achieved with the current framework of SabVM Streams. All that's required to do is deposit just enough assets into a Stream to keep it running until the time you'd otherwise put inside the proposed endTime field.

Secondly, Senders need to decide how much to deposit into their Streams, anyways. Moreover, they'll, likely, need to make this decision dozens of times throughout the lifespan of their Streams. And each of this decisions, practically, determines the new expiry date for the Stream, as running out of funds is more important of a clause (than the endTime) for us to check when determining whether the Stream has to be closed.
So, with the intersection of the Stream's balance and the endTime, in terms of their affect on the Stream's effective expiry date, I see introducing the endTime parameter to the equation as adding extra burden for the Senders to carry (mentally) wrt their Streams.

Lastly (and I might be mislead by my personal experiences here), Streams are, likely, primarily thought of in terms of the value they're streaming, with their total duration/end time being of a secondary nature, directly determined by the former.

[PaulRBerg]

Thanks for your feedback.

the result targeted by the proposed feature can totally be achieved with the current framework of SabVM Streams. All that's required to do is deposit just enough assets into a Stream to keep it running until the time you'd otherwise put inside the proposed endTime field.

This is the 2nd bullet point underneath the "Implementation" section in the OP. And as I've said there, I'm in favor of it. So, I am confused by your being skeptical of this feature.

I see introducing the endTime parameter to the equation as adding extra burden for the Senders to carry (mentally) wrt their Streams

It is possible to abstract away the underlying complexity at the application layer.

The app could set up a dedicated contract (e.g. a Safe multisig wholly controlled by the user) for managing the closed-ended streams.

Streams are, likely, primarily thought of in terms of the value they're streaming, with their total duration/end time being of a secondary nature, directly determined by the former

This is a matter of form, not of substance. But, at any rate:

• Open-ended streams are like that.
• Closed-ended streams are NOT like that.

[IaroslavMazur]

the result targeted by the proposed feature can totally be achieved with the current framework of SabVM Streams. All that's required to do is deposit just enough assets into a Stream to keep it running until the time you'd otherwise put inside the proposed endTime field.

This is the 2nd bullet point underneath the "Implementation" section in the OP. And as I've said there, I'm in favor of it. So, I am confused by your being skeptical of this feature.

If, by that application-layer idea, you meant some sort of a tool that would let you input your desired expiry date for a certain Stream - and would help you deposit into the Stream exactly as much as it'd be needed to keep that specific Streaming running until your preferred expiry date, then, yes, it sounds reasonable and a nice & useful automation for the SabVM Streamers.

---

I see introducing the endTime parameter to the equation as adding extra burden for the Senders to carry (mentally) wrt their Streams

It is possible to abstract away the underlying complexity at the application layer.

The app could set up a dedicated contract (e.g. a Safe multisig wholly controlled by the user) for managing the closed-ended streams.

This seems to confirm my hypothesis about your application-layer idea from above. 👀

[razgraf]

This is an interesting feature. Initially I would've said we should leave it to the application layer to implement it, but I'm starting to think it's a good way to cleanup streams from the graph. It would probably require some "flavor" of termini?

At any rate, would probably be good to start small and not focus on this for the first-first version.

[PaulRBerg]

Good point about the clean-up.

But, as you said, it would still be better to relegate it to the application layer in the spirit of quick iteration and go-to-market.

[IaroslavMazur]

Given that we're intending to clean up the illiquid Streams of the insolvent users, anyways, the only way in which having an endTime configured for each Stream would help is that the Streams would now be able to end/close automatically, w/o the Sender being required to close them manually.

However, all in all, this sounds like more of an advantage for the Senders than us, because it's not like if we only offer open-ended Streams, they will run forever: the Senders will eventually close them manually (everything in life is finite).

@razgraf, @PaulRBerg, am I missing anything here?

[PaulRBerg]

the Streams would now be able to end/close automatically, w/o the Sender being required to close them manually.

Exactly.

this sounds like more of an advantage for the Senders than us

Exactly. We're discussing a feature

am I missing anything here?

No.