Should we carry forward the debt after the stream has been paused?

[smol-ninja]

Context

Currently, pause() sets debt to 0. As I mentioned here, I see value in carrying the accumulated debt forward even after pausing the stream¹.

Use case

Consider the following scenario:

1. Alice (payer) and Bob (payee) have an ongoing stream with accumulated debt .
2. Alice cannot fulfll her obligation because of lack of funds. To stop further liability, they decide to pause the stream, i.e. stop further debt accumulation.
3. Alice promises Bob to pay the accumulated debt once she receives funding from investors..

I believe this situation is common. If we allow pause() to set debt to zero, the protocol won't support such scenario.

Voiding the debt

If Alice cannot fulfill her debt obligation, she can discuss with Bob to void the debt. In this case, we can introduce a "recipient-only" function called void(), as discussed here, which sets debt and ratePerSecond to 0.

Table

Functions	Access control	Actions
pause()	Sender	ratePerSecond = 0
void()	Recipient	ratePerSecond = 0 and debt = 0

Final note

This feature is not useful if there is always capital to repay the debt. But in real situations, there could be many many cases where companies want to repay the debt in the far future without voiding it at the time of pausing.

RFC @sablier-labs/solidity @maxdesalle @razgraf.

Footnotes

1. For this discussion, we will assume pause and cancel are same as decide here. ↩

[maxdesalle]

I'm maybe misunderstanding something, but couldn't we have two pause() functions? One of them that sets the debt to 0, another that carries it forward? There are also a lot of good arguments to set the debt to 0 when pausing the stream. One could think, for example, of an employee going on an unpaid leave of absence, where the employer would then simply have to pause the stream, and unpause after the employee returns to work. Accumulating debt in that scenario wouldn't make sense.

[smol-ninja]

but couldn't we have two pause() functions? One of them that sets the debt to 0

Yes, in the OP, its called void(). See this discussion.

if an employee going on an unpaid leave of absence, where the employer would then simply have to pause the stream, and unpause after the employee returns to work. Accumulating debt in that scenario wouldn't make sense

Debt only accumulates if the balance in the stream is less than streamed amount. For example, consider employer owes employee 1000 tokens but there are only 100 tokens in the stream, so debt is 900 tokens.

In your example, employer would call pause() when the unpaid leaves begin and resume() when the unpaid leaves end. Does that answer?

[maxdesalle]

Yes! Apologies, should have read more thoroughly the OP.

[PaulRBerg]

I'm in favor of this.

Just like Andrei's proposal for removing the cancel function, this discussion purports to introduce more separation of concerns and more modularity in the code base.

in real situations, there could be many many cases where companies want to repay the debt in the far future

True. In more colloquial terms: getting REKT is possible, and we should allow REKT users to rectify their contractual relationships.

RFC @sablier-labs/solidity @maxdesalle @razgraf.

There's @sablier-labs/engineers.

[andreivladbrg]

I am in favor of this, especially since I started working on the cancel -> pause change. There, it would be impossible to call refundFromStream without a bug if we don’t add this feature.

Great proposal, Shub! 👌

[smol-ninja]

Thank you.

[smol-ninja]

Closing this since we have all agreed.

• Carry forward the debt after the stream has been paused by storing it in remainingAmount #91