Batch stream for only one asset

[andreivladbrg]

I started working on the group stream functionality and while implementing I realised that if we are going to allow multiple assets it would be very inefficient because we would have to make the erc-20 transfer twice for each of the struct's (params) grossDepositAmount variable. Also at the UI level the user must approve each one.

user --> periphery --> core

If we are going to limit the create multiple function to have only one asset it will be much more efficient because it will be possible to make only one erc-20 transfer towards the periphery contract.

The function looks like this:
https://github.com/sablierhq/v2-periphery/blob/5aaaf8fff5ac896e108212d66794838cceaf3c5f/src/interfaces/IBatchStream.sol#L34-L38

What do you think? Should we allow multiple assets? Or should we implement both of these functions?

[PaulRBerg]

Thanks for opening this discussion, @andreivladbrg. It is indeed a point worth clarifying in advance.

If memory serves me well, @razgraf and I discussed about this issue at Fab Lab sometime in 2022, and we convened to allow only single-asset creation for the batch stream function. We suspect that in practice, this is how this feature will be needed by users in the majority of cases.

But even if multiple-asset batching will eventually be in high demand, we have to also consider where we stand today, and take our bandwidth into consideration. That is, we should start small and build our way up from simple feature, and then iterate based on the feedback we get from users. We can afford to do this in the periphery contracts because they are stateless.

[razgraf]

As @PaulRBerg said, the periphery can be evergrowing (not to say that we should update it often, but it's definitely possible).

The group feature is engineered at this point in the app to allow for single asset batches. Why:

• We presume most users will stream the same token for payments of salaries or distribution of DAO assets
• Users will be required to allow a single asset (improved UX)
• The complexity of the system is kept at a minimum (checks for balances or for the integrity of assets don't have to be done N times, but once for the single asset)

The gas/efficiency considerations are another huge argument, so thanks for bringing it up @andreivladbrg.

Therefore, I think it's agreed we should focus on the single-token batching for now. We can revert to this discussion if feedback on this gets overwhelming post launch.

[PaulRBerg]

Locking based on the fact that we agreed to support create multiple only for single assets for the time being.