Unified balance

[maxdesalle]

Feature request from power user Micah

[IaroslavMazur]

Isn't that how Llamapay works - and why it's susceptible to the attack involving some of the recipients having a (concurrent) claim on the Pool funds inside withdrawing their full share before the others, leaving the others waiting for their common Sender to (maybe?) top up the Pool in the future?

[PaulRBerg]

Yes, that's how LlamaPay works, but Micah's feedback makes me wonder if the UX benefits of allowing users to top up a single stream perhaps outweigh the downsides of the first-come, first-serve model.

I wouldn’t describe this model as an 'attack'; it’s simply a peculiar UX design. It only becomes an issue when the sender fails to top up funds for all recipients—a scenario that shouldn’t occur frequently.

cc @sablier-labs/engineers for feedback — should we switch to first-come, first-serve?

[PaulRBerg]

Related: New "Top Up" button for topping up multiple streams

[smol-ninja]

My take is that the UX benefit that Micah mentioned can be addressed through the UI. If that's not possible or overly complex, then we can explore in this direction. Implementing this model would necessitate breaking changes to the protocol.

• We would need to keep a record of all stream IDs created by a specific sender to calculate the refund amount. This would involve summing up the total debt across all streams they’ve created (see below point).

• Llamapay does not support features like pause, void, or snapshots. Llamapay only tracks cumulative RPS. Whereas in our case, we will have to track cumulative RPS, cumulative snapshot debts, and the cumulative last time update to calculate the total debt of all streams created by the sender for a particular token. This will require a restructuring of our contract storage architecture. 

• This change would also affect the user experience for external depositors. Currently, topping up a stream requires the stream ID as input. Under this new model, topping up would instead require the sender's address. Depositors would essentially be adding funds to the sender’s pool rather than a specific stream ID. Though, this is a small problem.

IMO both models have their pros and cons, and I firmly believe our architecture is better than Llamapay’s. We designed this to address real-world use cases (that is why we have features like void, pause and restart) tailored to fit user requirements with payments. On the other hand, Llamapay offers a minimalistic product aimed at creating simple payment streams, how most things are in crypto. People build them and hope for people to use them without pushing for it or making changes to their needs.

Having said, if we receive multiple requests for this, then we will have no choice but to prioritise this unified pool approach over ours.

[andreivladbrg]

I agree with Shub here. IMO, this is primarily about how it is addressed in the UI, as this functionality can simply be achieved by batch calling deposit or refund. Which makes the current design superior: with a "first-come, first-serve" approach, you can't achieve stream-oriented payments features, but with a stream-oriented design, you can achieve the feature that Micah has requested.

graph TB
  subgraph Stream_Orientated[Stream Orientated]
    FCFS[First-Come, First-Serve]
  end

Loading

Idea for implementing it in the current design:

• Add a "deposit/top up to all streams" button.
• Display all the active streams.
• Calculate the percentage of one stream's rps compared to others:
  • For example, if one stream has an rps of 1000 USD per month and another has 2000 USD per month, the second stream should receive double the amount as the default value.
• If the total amount to be deposited is 6000 USD, the default values would be: 1. First stream: 2000 USD 2. Second stream: 4000 USD
  • Allow the user to modify the default values

Also, making this architectural change would be significant and could lead to technical challenges in maintaining all the features that differentiate us from LlamaPay (which Shub has mentioned)

[razgraf]

A version of what you're proposing is already implemented in the UI through our batched top-ups.

https://x.com/Sablier/status/1869727809159246093

[andreivladbrg]

correct.

i was referring more to prioritizing a "default" deposit (based on the rps) to all streams on the "Payments" page—what Micah is talking about—rather than selecting each stream and inputting an amount for each one

[razgraf]

Micah's need seems to already be addressed in the app. Currently he can:

• select all the streams he wants to top-up at once
• (optional) use the "copy link" feature (see exhibit A) to save that set of streams for later
• select the top-up feature
• click to top-up "30 days" worth of funds for every stream (see exhibit B)
• pay

Exhibit A	Exhibit B

Long time ago I imagined a more advanced iteration of this flow where he can (similar to Zapper's bundles) save one of these group of streams in a bundles list, where we can also display some quick-action buttons like

• "top up a month worth of tokens for this entire bundle"
• " ... 3 months ... " and so on

End goal is the same, it would just remove from the number of clicks he'd have to perform. If we do it, I figured it would be part of the labels sprint.

---

Regarding our current individual architecture vs. pool model, I think ours is superior since it simplifies accounting and reduces the risk for that front-running.

It only becomes an issue when the sender fails to top up funds for all recipients—a scenario that shouldn’t occur frequently.

It might be easy to fall into this case esp. for those waiting to withdraw a large chunk of funds just to have "withdraw max" fail on them because the sender thinks "Ah hey 10.000 is enough in the pool, I'll just top-up later". We can work around this, of course, but why choose the bad UX for recipients when we can simply improve it in the app for senders.

---

P.S. Maybe @maxdesalle can help us shoot a how-to video with this particular use-case in mind so we can share with interested users. A more lengthy version of this tweet.

Related: sablier-labs/docs#227