Exploring Stream Dynamics: Sender vs. Recipient Priority

[smol-ninja]

In the current deposit and depositMultiple flow, a deposit is made against a stream ID. This makes all the streams created by a single user mutually exclusive and offers an advantage to recipients in terms of user experience.

From https://github.com/sablier-labs/private-discussions/discussions/6#discussioncomment-7304440:

When having two streams with the amount of 1000 tokens per month and the sender has deposited only 1000 tokens (instead of 2000 for both streams), at the end of the month, a "first come, first served" approach would be applied. This means that one recipient could potentially "steal" the other recipients' funds, which is, once again, very bad UX.

This flow prioritises experience for recipients over senders. If we were to prioritise the sender experience, then we can look into an alternative approach where the sender manages only one pool of money and all the streams created by him share the amount from this pool.

For example, a sender has a pool with 1000 USDC and creates 2 streams each of 500 USDC per month. At the end of the month, when recipients withdraw money from their streams, the balance in the pool reduces and gets transferred to each of these recipients. This offers a better experience for stream creators as they only have to ensure there is enough liquidity in the pool for all these streams.

The downside as pointed out by @andreivladbrg is that in case of low liquidity in the pool, it becomes a first come first serve basis for recipients.

I would like to discuss who we think are our primary users for v2-open-ended. Are they stream creators or stream recipients? And which design we should prioritise over other.

There is also a very important point made here (#7 (reply in thread)) that a change in architecture like this would break consistency between Sablier products which is true as well.

[andreivladbrg]

Thanks for writing this down.

an advantage to recipients in terms of user experience.

It's not just an advantage for recipients, it's also an advantage for the senders
Here's why: in the case of debt, the sender wants to deposit only for the first recipient. However, they are forced to deposit into a common pool, from which the second recipient might withdraw first. This puts the sender in a situation where they cannot choose the specific recipient for their deposit

This offers a better experience for stream creators as they only have to ensure there is enough liquidity in the pool for all these streams.

Can't the stream creator also ensure there is enough liquidity(onn each stream) by calling depositMultiple? Wouldn’t this result in the same experience for stream creators? Does this method affect the app's workflow, particularly in terms of the number of clicks required?

To be more specific, we will have the same number of clicks, because as we've decided, we will move the depositMultiple function to the periphery. This results in only one ERC20 transfer from the user to the periphery (one MetaMask transaction sign), followed by multiple transfers from the periphery contract to the open-ended contract.

My final point is this: the behavior of depositing in the same pool can be achieved with mutual exclusivity, using the periphery + depositMultiple. However, when you have a common pool, you can't achieve the behavior of prioritizing which recipient to deposit to first.

Waiting a response from you, have I missed something in this flow?

[IaroslavMazur]

Thanks for an interesting new perspective upon the matter, @smol-ninja!

While, in theory, it would, indeed, be easier for a sender to deposit the assets that are to be streamed into a common pool (from which all of the sender's Streams would be debiting the assets), it would only be marginally easier, with the alternative - as @andreivladbrg has rightfully pointed out - requiring just the uint256[] streamIds, uint128[] amounts information on top from the sender.

Besides, the recipient is whose UX the sender is (or, at least, should be) most interested in. So, by putting the recipient's experience first, we're, actually, pleasing the sender, as well.

On another note, here are some complications that have crossed my mind while I have briefly brainstormed the "common pool" approach:

1. There would need to be 1 pool for every asset used by a sender.
2. The pools from 1. would, potentially, need to be created and maintained (in various sets/combinations) for each sender, creating a "many to many to many to one" relation from senders to their multiple pools, to multiple Streams and, ultimately, to the respective recipients.

The upside that could, theoretically, be generated by implementing such a system wouldn't be worth all of the effort required to bring this to life, and the complexity this would add to the EOES protocol as a whole, in my opinion.

[andreivladbrg]

There would need to be 1 pool for every asset used by a sender.

good point, forgot about llamapay's factory pattern used on their contracts: https://github.com/LlamaPay/llamapay/blob/master/contracts/LlamaPayFactory.sol

many to many to many to one" relation from senders to their multiple pools,

this can be achieved with the llamapay's model, which would require a streaming contract for each asset

[smol-ninja]

I just finished reading the llamapay code and I now think our approach of using uint256[] streamIds, uint128[] amounts is better. It would still be only 1 click to make deposits into multiple streams for senders while our design offers a better experience to stream recipients in terms of peace of mind and stream stability.

I agree with the point that having a common pool leads to a poor experience for recipients who are slow at claiming.

Two other points where we (can) have a better design:

1. Llamapay does not offer to create a stream with startTime in the future.
2. Changing rps requires cancelling and starting a new stream that changes the stream ID since $streamId = f(from, to ,rps)$

I am happy to close this discussion.