UX difficulties with unwanted debt

[razgraf]

Requesting some feedback on the following problems (+ the potential solutions). The main issue is with "socially unwanted debt" (meaning correct technically, but weird for UX).

Scenario

Alice works as a contractor for 3 months, gets paid USDC 1000/month. Bob, the employer, opens the streams, funds it, 3 months pass and on day 2 of the new month Bob remembers the stream: no money is lost, as he only funded it with USDC 3000 but now there's USDC 60 in bad debt as he pauses it.

Context

In order to "stop" a stream, one can:

• as a sender, pause it (debt is tracked)
• as a recipient, void it (debt is cleared)

Problem 1 - Debt dust

In organizations taking care of payroll, senders may forget to stop streams when someone is fired or a contractor finishes their commitment. Even if they do, it invites "dust" to accrue as unwanted debt.

In our scenario, Bob could pause the stream and go to Alice and ask her to send a void transaction. Realistically, this set of actions relies on a non-trivial coordination cost. While technically correct, the debt doesn't really fit with the "social contract", therefore causing bad UX for any accounting or portfolio tracking. The question here is:

How do we deal with the unwanted debt dust?

Problem 2 - Debt-loaded restarts

PRB edit: see the conversation below. This is not a problem because in Flow, there can be multiple streams between two users.

Extending the initial scenario, say:

> Bob needs Alice again for 2 months of work. He wants to start a stream of USDC 1000/month. The system tells him he needs to pay USDC 60, but that's unwanted debt so why would he?

How can Bob start his new agreement with Alice without the unwanted debt?

---

Note 1

The example of USDC 60 can be extended to cases of USDC 999..99 for someone who simply forgets to close the stream.

Note 2

To put it another way, I can't pay exactly 3000$ at 1000$/month.

• I will either pay less - I go there at 2990$ paid and pause the stream
• Or pay more - I go there at 3010$ (10$ in debt) and pause the stream - now I have debt, hence the problem above

@sablier-labs/everybody

[razgraf]

Partial Solution (in app) - Incentivize withdraw + void

On the recipient side, we would add a toggle for chaining a void action after withdraw. This makes sure that when Alice gets her last assets, she also "removes the stream from accounting" (voids it).

This would only be good for paused streams (we wouldn't want Alice to void a good stream upon her first withdrawal), meaning we're left with the next edge-case:

Alice withdraws her last funds, but Bob hasn't paused the stream yet. Debt is still accruing.

Partial Solution (on-chain) - Dummy "signal"

Accounting is usually more important for the sender (they're more likely to use their account to manage more engagements). Therefore, we could implement an on-chain "signal" to simply mark a stream as "sender-voided".

This would come under the shape of a dummy method that only emits an Event signalling a certain streamId is not of interest any more.

I realize this could be done using our backend too.. but the advantages of implementing it on-chain are:

• everyone can pick it up using an event listener and use subgraphs to pick it up ourselves
• we can more easily filter those streams out, include or exclude them from aggregated accounting etc. (important for portfolio tracking)

Solution (on-chain) - End stream

We discussed this in #40

[andreivladbrg]

This would come under the shape of a dummy method that only emits an Event signalling a certain streamId is not of interest any more.

As we discussed f2f, an alternative to this could be a pauseWithReason function that includes an extra string parameter. This param would be emitted in the PauseFlowStream event, allowing the app to categorize the type of pause.

[smol-ninja]

Nice idea but how does it solve the dust problem identified in this discussion?

And, the reasons could be arbitrary strings so how do we plan to create categories out of those reasons?

[andreivladbrg]

Nice idea but how does it solve the dust problem identified in this discussion?

On-chain, the “dust” would still remain, but the issue could be addressed at the app level (sablier) by passing specific information about the type of pause. For example:

• In the case Razvan provided, a $3010 stream with $10 in debt, the sender might want to pause it and forget about it. This means the accounting in the app will not consider it. For this example, the app could pass a “forget” string or any category that Razvan and Mircea decide on.
• Another example would be when someone wants to temporarily pause the stream but keep the debt for a future restart, this would require a different category. (the debt would still be accounted)

---

Another thing we discussed about was if we can introduce an end time.
We will see if this is actually feasible without breaking other things in practice after Paul’s review.

[andreivladbrg]

Indeed, there is a tricky situation caused by the nature of flow, particularly because of these aspects:

• no start/end times
• a dynamic balance rather than a specific deposit amount

Currently, I don’t think there is any elegant way to address the unwanted dust problem.

The on-chain solution that I can think of would involve implementing a system like Gelato to automate pausing.

Whether it is on-chain or off-chain (backend - the automated pausing), this would not be feasible. Any stream created without an initial deposit becomes insolvent after one second, and with an automated system that pauses in case of debt, it would be paused immediately. It is difficult to create a scenario that would cover each type of flow stream created—whether it will incur debt after a couple of seconds, after months, or whether the debt is intentional or not.

So, IMO, the best solution would be to add a param in the event that the sender triggers to ask the recipient to "withdraw + void" if there is any unwanted debt.

Also, for your exact scenario, if the sender needs to pay a contractor for exact 3 months with an exact amount which he deposits at start, it would be achieved by lockup contract.

How can Bob start his new agreement with Alice without the unwanted debt?

If anyone wishes to have a "fresh" start, he can start a new stream at any moment of time.

[razgraf]

Agree it's difficult to cover each edge-case, especially since flow is a bit more nuanced in terms of on-chain enforced agreements vs. off-chain social agreements. But I felt like this contractor/payroll example covers a lot of our intended usage, therefore the UX will affect a large percentage of users.

for your exact scenario

Good point, should've made it clearer. Let's say they want to deposit 1000$ at the start of each month, so they want flow not lockup.

If anyone wishes to have a "fresh" start, he can start a new stream at any moment of time.

Sorry, was under the impression that there can only be one stream between a sender and a recipient. If this isn't the case any more (I remember some conversations on the topic) that's great and you're right - multiple edges means he can start a new stream and forget about the old one (rendering Problem 2 unnecessary).

[andreivladbrg]

Let's say they want to deposit 1000$ at the start of each month

Ok, so in that case, the accumulation of debt is a good thing, and the automation of pausing would not work, right?

If this isn't the case any more (I remember some conversations on the topic)

That was never the case. The point I was trying to make was that each node connection (sender -> recipient) is possible to be handled with only one ID, given the flexibility of the flow (but never said that there can't be more than one ID). I assumed this way (only one ID) would be easier to manage at the app level.

[smol-ninja]

I think @razgraf is focussing on what if sender wants to pause a stream at a known future date and don't want to accumulate any dust (+/-). He also does not want to create another stream but just want to use the same (for accounting purposes).

[razgraf]

The second point isn't very important as creating new streams should actually be cleaner, so Andrei was on point there. Was a misconception on my end. Thank you for explaining @andreivladbrg.

But yes, for the first you're spot on @smol-ninja. It's about finding ways to limit the "dust" to

1. improve accounting and cognitive load
2. make our lives simpler when trying to compute for example an incoming balance or outgoing balance of a user (those dusty or un-paused forgotten streams would mess up the math)

[smol-ninja]

IIUC, another way to ask "How do we deal with the unwanted debt dust?" is "How can senders pause the stream at a specified time without accumulating any dust?"

I want to propose an on-chain scheduler. Here's a detailed breakdown of how this could be implemented:

1. When a sender creates a stream, optionally they can provide a signed data via the frontend.
2. The signed data includes:
   a. A time range during which the transaction can be executed on-chain.
   b. The type of transaction (pause).
   c. An incentive (a specified token amount) to cover the gas fees.
3. The frontend accepts this signed data, stores it in our database and makes this public via an API. Display this info on the UI, indicating when the stream will be paused.
4. Once the current time falls within the specified range, anyone (including us) can execute the signed transaction and receive the incentive.
5. The incentive ensures that the tx is executed as soon as possible, minimizing any on-chain dust.

Incentives will be donated to another contract from which executors would receive incentives. These would be a very small amount. The executor would receive 150% of the gas cost and the remaining can be refunded to the sender in the same tx.

QnA

Q. What if the signed data is sent on-chain before the time range?
A. It would fail.

Q. What if the sender decides to cancel the scheduled tx?
A. He can do so by executing another tx (similar to how NFT orders are cancelled on Opensea).

Q. What if at the time of tx, gas cost is higher than incentive provided?
A. That's the risk involved. So senders are encouraged to provide more incentive amounts since it will be refunded back to them if the gas is low.

Final note

This may look complicated in writing but it's very less complicated to implement. It's how gasless transactions work. It's how opensea orders work and Cowswap amm works. We will add a function in Flow contract which will accept or reject the signed data and pause the stream. We will be offering a gasless way to pause a stream. In the future, we can extend it to make Sablier as a whole gasless for users.

Wdyt (of course if you think that I correctly understood your problem)?

[smol-ninja]

flowchart LR;
    sender((Sender));
    executor((Executor));
    donationPool[Incentive Pool];
    db[(Public Information)];
    tx[[Miner]];

    sender -- signed data ----> db;
    sender -- deposit incentive ----> donationPool;
    db -- signed data --->executor;
    executor -- tx(signed data, nonce, msg.value) --> tx;

Loading

flowchart LR;
    sender((Sender));
    executor((Executor));
    donationPool[Incentive Pool];
    tx[[Miner]];

    tx -- verify(signed data) + pause --> stream;
    tx -- call --> donationPool
    donationPool -- transfer incentive --> executor
    donationPool -- refund --> sender

Loading

I can write a quick and dirty implementation for Flow to showcase how it works in practice (without incentive pool). We can even turn it into a paid service.

[smol-ninja]

Had a look at Gelato's relay service. And its same as what I have been proposing. It wouldn't have nonce issue but would require us to implement relay requirements such as trusted forwarder, msgSender() etc.

I think we should do it. It would be a 10x improvement in the user experience. cc'ing @PaulRBerg @andreivladbrg for feedback.

[IaroslavMazur]

This solution would, indeed, target and minimize the problem of debt dust. It won't fully resolve it, though.

In theory, the debt dust could be prevented if the pausing tx is executed (on the sender's behalf) at the very moment (i.e. the same block) when the funds inside the Flow Stream have just dried up.

However, unless

1. there are precisely enough funds deposited inside the Stream to be streaming up until the exact timestamp (which can only be estimated - and not calculated - beforehand) of the block containing the Stream pausing tx and
2. the tx pausing the Stream is, actually, included in that block and
3. the sender has, actually, properly configured the system (as @razgraf has correctly pointed out here),

the Stream will, inevitably and unfortunately, still produce some debt dust.

[smol-ninja]

Thanks @IaroslavMazur for your comment. I agree with you that it would only "minimize" the dust problem.

In theory, the debt dust could be prevented if the pausing tx is executed (on the sender's behalf) at the very moment (i.e. the same block) when the funds inside the Flow Stream have just dried up.

Since Flow doesn't require upfront deposit, if, at a moment, funds inside the stream have dried up, it may not necessarily mean that the stream is expected to be paused; may be sender will make deposit at a later time.

So the only situation, that I can think of, in which the dust problem can be solved is the following:

1. Sender specifies a timestamp when the stream is expected to be paused (#40)
2. The sender repays the debt in full upto that timestamp
3. Now by specifying the timestamp, sender agrees to pay the streamed amount upto that point and the stream has been paused, implies there should not be any dust left.

[IaroslavMazur]

if, at a moment, funds inside the stream have dried up, it may not necessarily mean that the stream is expected to be paused; may be sender will make deposit at a later time

Indeed. But "debt" is still "debt", no matter whether it's intended to be repaid - or not :)

---

The sender repays the debt in full upto that timestamp

You must mean that the sender is "committing" (in a soft manner) to be streaming to the recipient up to that point, without, actually, coming up with all of the funds upfront (although this wouldn't make sense for Flow, this is what I thought when I first read the above)

---

the stream has been paused, implies there should not be any dust left

This'd mean that there can be 2 kinds of "pauses" (reminding me of the "pause with reason" idea you've been discussing):

1. the pause with the debt that keeps accumulating and which the sender soft-promises to pay back and
2. the pause which is, actually, the end-of-deal for the sender - which signals no debt being accrued after the pausing point

The above, however, would have implications spanning more than just the calculation (or not) of the debt accruing after the pausing point, as, e.g.:

• the sender can change their mind and not provide enough tokens to stream them up to the pausing point (even though they've soft-promised they'd do);
• in the proposed design, the above situation will still lead (and rightly so) to the accumulation of debt, pre-pausing-timestamp;
• this problem could only be addressed by
  • forcing the sender to pre-deposit the whole amount (up to the pausing time) into the Stream and
  • locking the funds into the Stream, such that they are guaranteed to be streamed down by the pausing time
  • ** welcome back, LockUp ** 😅

---

All this has lead me to question whether the added benefits are worth the potential downsides of trying to address the unwanted debt situation 🤔

[razgraf]

Sorry for taking longer to respond here.

On @smol-ninja's Gelato-style suggestion, my general thoughts are:

• while it's a cool system to build/integrate, I'm wary of relying heavily on 3rd party dependencies for important features
• we'd have to start offering different services based on where Gelato is also deployed
• account abstraction is incoming so integrating tightly with Gelato's signature scheme would become deprecated quickly (although haven't made up my mind here yet, so should we move this into a separate conversation to weigh in on all the pros/cons for a general integration?)
• it will still cause debt dust-and-more if the user forgets to set this up (no way to retroactively mark the debt as not-important-for-accounting)

Regarding @andreivladbrg's pauseWithReason idea: it's a much more elegant version of my "dummy signal event" idea. Shub is completely right that it wouldn't be a 100% perfect solution as people could still pass unintelligible reasons, but for our purposes it would help a lot in figuring our the semantics of a paused stream. Alternatively we could define a clone method (e.g. pauseWithReasonUninterested .. don't mind the name for now) for a nicer API.

You mention the "debt dust problem" and while this doesn't solve it, it provides for a nicer way of explaining that debt in the user interface.

At the same time, we re-discussed the possibility of implementing #40 such that:

1. If the sender expects to be closing the stream, they define the end date (can happen at any time >= create time)
2. If the sender forgets and debt dust accrues that they don't want to consider in their visual accounting in the UI, they pauseWithReason

---

I would be interested to hear your take on the above @smol-ninja, sorry again for the delay.

[smol-ninja]

No need to be sorry. Good things take time.

we'd have to start offering different services based on where Gelato is also deployed

Good point that our services would heavily rely on the supported networks by Gelato, and the launch of account abstraction would deprecate it. Regardless, my first suggestion was to build our own gas-less architecture to schedule on-chain transactions through signed messages (similar to Cowswap and UniswapX) for the general Sablier ecosystem rather than integrating Gelato. I will do more research later on this thought and will start a separate discussion for it. So I agree to drop the Gelato idea for this discussion.

pauseWithReason and pauseWithReasonUninterested

Sounds like nice ideas to me. I thought about it, and I am also in favour of this for our first release, and then we can see how it works in practice. I suppose you would query the paused reason from graph to avoid storing it in our database? Can we use calldata to store reason instead of emitting it? Can you query calldata from the graph? If user enters long reasons, events would be cost significant compared to calldata.

You mention the "debt dust problem," and while this doesn't solve it, it provides a nicer way of explaining that debt in the user interface.

Agree from the UX point of view.

At the same time, we re-discussed the possibility of implementing #40 such that

We can think about adding an end time. But I think it would be a big change (tagging @andreivladbrg). Off the top of my head, since Flow is designed to be very flexible (you can take any action at any time), including an end time would mean dealing with the following situations:

1. Can a user change the end time once set?
2. Can a stream be resumed after the end time has passed? If yes, then should we call it "pause time"?
3. What happens if the user pauses a stream prior to the end time? Does it increase the end time as well?

Among all the above, I am more in favour of including end time as pause time. But for the first release, your solution of reason string sounds like a good idea too.

[razgraf]

Thank you for looking into this! Curious to see what the research yields for our custom gas-less system.

I suppose you would query the paused reason from graph to avoid storing it in our database?

Exactly! As mentioned here there are some advantages to the reason/signal being passed on-chain, one of which is us being able to fit it in our system more efficiently, the other that everyone else can also pick it up (as opposed to our centralized DB).

Can we use calldata to store reason instead of emitting it?

At least with The Graph I remember decoding input data at some point. Will have to check more with Envio but I can't really seem to find any hints towards input-data objects in the parameters I'm given access to. So we might have to do it in an event to ensure compatibility.

If user enters long reasons, events would be cost significant compared to calldata.

Fair point but could we either restrict the length of the string or simply leave it up to the user? If the user wants to pay to pass a 32 char string on-chain, it's their gas.

But I think it would be a big change

Absolutely, and the situations you've hinted at are spot-on.

If you guys figure out a neat way of addressing these, would love to have the end-time back in discussion for one of the first releases if not the first. As you can see, it would provide some elegant finality to our system's semantics, which in the meantime can be partially fulfilled with pauseWithReason.

[andreivladbrg]

We can think about adding an end time. But I think it would be a big change

yes, it would definitely be a big change

1. Can a user change the end time once set?
2. Can a stream be resumed after the end time has passed? If yes, then should we call it "pause time"?

without starting to actually implement it, it’s hard to think in advance of each detail. but how i see this atm, this “set end time” action would be a one-time per stream action. i.e. once set you cannot undo it or change the end time so that the attack vectors don’t increase too much.

3. What happens if the user pauses a stream prior to the end time? Does it increase the end time as well?

for the version above, it would simply not accumulate debt as the rps would be 0

---

i like the idea of releasing the first version without an end time and experimenting with pauseWithReason. based on the feedback we receive, we will introduce it or not

created the issue #201

[PaulRBerg]

I haven't yet found a moment to review this discussion, but it is worth mentioning that in the future, the debt will be renamed to uncovered debt.

[andreivladbrg]

Thanks for mentioning. As far as the calculation logic doesn't change, the renaming does not affect the discussion here.

[PaulRBerg]

Calculations won't change but what debt means will change so this was worth clarifying.

[PaulRBerg]

Ok, I have finally caught up with this thread. Thanks all for your contributions. Some thoughts:

• The Gelato-like scheduler system is overkill ❌
• The pauseWithReason proposal makes sense and I see why you have landed on it ✌️
• However, I would like to suggest a better and simpler solution ✅

Here it is:

• Allow senders to void the stream and clear the debt
• Introduce a pauseAndVoid function (or use the abstract batch function)

The reason why we have allowed only the recipient to void a stream is due to a social contract. Given how problematic this social contract turned out to be (unwanted debt), it should be fine to allow senders to clear their debt via the void function.

Note

The pauseWithReason effectively achieves the same outcome as pauseAndVoid, but in a roundabout fashion. In both cases, the sender is no longer interested in repaying the debt. But in the former case, the sender needs to jump through multiple hoops.

If you (@sablier-labs/engineers) agree with this rationale, and you find no mistake in it, we should close #201 and open another issue to refactor void to make it callable by the sender.

[PaulRBerg]

Does anyone have any further criticism/ refutation here or can we consider my proposal valid and move on to implementation?

It'd be very nice to get Flow shipped by Q4 :)

[smol-ninja]

Lets create the issue. No more criticism from my side. I've realized the sender can grief recipient by not funding an insolvent stream. So my rationale, that allowing the sender to void the stream will give them an option to not fulfill the debt and simply voiding, is not correct. Thus imo the UX advantage outweighs the cons (which are none).

[razgraf]

Let's do it!

[smol-ninja]

Now that we wont have pauseWithReason, how do we categorise a stream as Ended? Should we include Void status?

[PaulRBerg]

@smol-ninja here:

#216 (comment)

[andreivladbrg]

since we’ve reached a consensus, i’m going to close this as per issue #215