Voiding streams with negative debt for improved accounting

[PaulRBerg]

Context

Michael Lewellen from OpenZeppelin is interested in beta testing our OpenEnded product. I met him in person in London, and presented our plans to him.

During our conversation about their needs, I came up with this idea.

Idea

Add a new function called void with the following requirements:

• Can only be called by the recipient
• Can only be called when the debt exceeds zero

And the following behavior:

• Sets the debt to zero
• Stops the stream from accruing debt in the future

Benefits

Implementing this feature would improve the accounting experience since it would enable recipients to signal to their accountants that "hey, we are no longer observing stream X, please ignore it".

Furthermore, this would provide Sablier with a competitive advantage over LlamaPay, which to my knowledge doesn't implement such a feature.

CC @sablier-labs/solidity and @razgraf

[razgraf]

Should we also consider having this for the sender?

Debt is a "tool" to track promised future income, so it's not locked/guaranteed, meaning senders can choose to skip it anyway. Voiding could cleanup dashboards on their side if they forget to officially close some payment stream.

Or is this contrary to what a sender can do? E.g. you either (as a sender) ask the recipient to void debt or you have to pay it up

[PaulRBerg]

super

[smol-ninja]

cancel and restartStream do not set debt to zero. It sets rps to 0.

[andreivladbrg]

cancel and restartStream do not set debt to zero. It sets rps to 0.

yes, and it implicitly sets the debt to zero, since in the cancel function no transfer will be made to the sender due to the debt

[smol-ninja]

So when they restart the stream, debt begins with zero?

[andreivladbrg]

yes, the debt is a dynamic amount calculated based on the balance(state variable) and dynamic streamed amount

[andreivladbrg]

Add a new function called void with the following requirements:
Can only be called by the recipient
Can only be called when the debt exceeds zero
And the following behavior:
Sets the debt to zero
Stops the stream from accruing debt in the future

the debt is a consequence of the sender not depositing enough tokens, if the recipient calls this function means that he will simply won't care about the streamed tokens in the past

is this what we really want to achieve?

Implementing this feature would improve the accounting experience since it would enable recipients to signal to their accountants that "hey, we are no longer observing stream X, please ignore it".

does it mean that it will also "abandon" the accounted amount as a loss?

[PaulRBerg]

is this what we really want to achieve?

Yes. It's perfectly possible for creditors to wish to forgive someone's debt.

They might have a private arrangement in which they changed wallets, changed chains, exchanged fiat instead of crypto, etc. They can then call the void function to signal to their accountants that the open-ended stream is no longer active.

does it mean that it will also "abandon" the accounted amount as a loss?

We as a protocol don't know and shouldn't care about that.

[smol-ninja]

Recipient being able to call void sounds like a good user experience.

But because it resets the "debt" which might be of any scale, shouldn't it be a decision made by both the parties? If recipient calls the void without informing the sender, this may not improve the accounting experience for the sender.

• Step 1: Recipient signals the sender through a transaction.
• Step 2: Sender confirms adds his confirmation through another transaction.
• Step 3: Debt sets to 0.

[PaulRBerg]

Requiring inputs from both parties sounds like a chore that would add friction without much benefit to either party.

• The sender may refuse to cooperate OR may not care enough about the recipient's accounting needs OR may be just lazy. Meanwhile, the recipient's accountants are at their wits' end, drowned in unclosed streams that keep accruing stale debt.
• If a sender sees a voided stream which they desperately wanted to repay, they can just look at the debt at the time of voiding, and make a one-time payment to the recipient.
• Consider the front-end development costs - it's extra effort that we should rather invest in other, more critical features.

[PaulRBerg]

Closing as it seems like we have consensus.

Opened an issue for todo tracking: #61

[smol-ninja]

Me and @andreivladbrg were discussing today about this during our post audit call. We realized that the logic of 'void' is same as 'cancel'.

We will basically have two functions with different access controls doing the same thing.

What do you think if we just combine void and cancel into one function and call it pause?

What pause does is that it sets rps to zero, sets isCanceled to True and reset the debt. The only downside of this is psychological barrier to distinguish between the two but that can be solved with the UI experience.

Thoughts?

[razgraf]

I think at this point it would be nice to have a state-machine (even a very rough one) where we can see what a stream can do.

You're right to assume users will have a hard time distinguishing between cancel and actual pause, as until now we've been treading cancel as a "bad thing" (red=danger), and this pause-cancel shouldn't have the same visual treatment.

[PaulRBerg]

I still think that it would be helpful to have two functions because of the UX issues you mentioned, and this other reason:

When the recipient is the caller, the debt must be positive. Just like in Lockup, a recipient should NOT be allowed to cancel an ongoing open-ended stream.

In general in Solidity, I prefer thin over monolithic functions.

And agree with @razgraf, if you could create a state machine using Mermaid or XState and throw it in a "Show and Tell" discussion, that would be helpful. As an example, see my walkthrough of the Stream Status.

[smol-ninja]

Click here to see open ended state machine diagram.