Function that creates multiple streams with only one ERC-20 transfer

[PaulRBerg]

We've recently received this feature request from a user:

@smol-ninja answered promptly and correctly:

But the user made a good point.

Having a createMultiple function that performs only one ERC-20 would bring huge benefits.

1. Lower the gas cost for all users.
2. Make it possible to create more than ~60 streams with a single CSV file upload.

I know we're already close to the maximum size allowed for contracts, but maybe there's a way to make this happen somehow?

cc @sablier-labs/solidity

[PaulRBerg]

Can I get your thoughts on this @sablier-labs/solidity, specifically if you think the contract size allows this feature to be implemented?

It's extremely important feature because it would significantly increase the number of streams that can be created in one go.

[smol-ninja]

How many additional streams can this feature support?

I conducted some tests to evaluate this. Here's what I did:

1. Copied the BatchLockup.createWithDurationsLL logic into SablierLockup and called it createWithDurationsLLMultiple
2. Moved the token transfer logic from the private _create function to createWithDurationsLLMultiple, making sure a single transfer of tokens
3. Created 100 streams using createWithDurationsLLMultiple as well as current createWithDurationsLL and batch functions (which includes 100 transfers)

Gas Benchmarks

1. createWithDurationsLLMultiple with single transfer: 11.8M gas
2. batch function (100 transfers): 11.9M gas (0.7% higher than above)
3. Periphery’s BatchLockup.createWithDurationsLL (100 transfers): 12.4M gas (5% higher than a single transfer)

The periphery’s batch function incurs the highest cost because it calculates the total transfer amount by summing up the values from each batch entry. This same check was performed in createWithDurationsLLMultiple, and that is why the gas reduction is only 5%. If we decide to skip this check and trust that the UI or users will input the correct total amount, we can improve gas efficiency slightly more, potentially reducing it to 7-10%.

Based on these results, my guess is it would increase the stream capacity by 7-10.

---

How much gas can be saved

~5%, and if we do not perform the transfer amount check then probably ~10%.

---

Why does the UI only allow 60 streams?

it’s possible to create approximately 150 streams in a single transaction based on gas benchmark.

---

Contract size

If we modify createWithDurationsLL to accept an array (similar to the batch lockup implementation) instead of a single stream input, this change can fit within the current contract size. For a single stream, the array would only contain one entry, and so the gas cost should remain comparable.

[PaulRBerg]

Great sleuthing, thanks for looking into this, Shub!!

Boy was I wrong on the magnitude on this one! Only 5-10% 😂

It looks like the lion's share of gas is consumed by the Sablier storage logic, not by the ERC-20 transfer.

Given that the potential benefits are so small, I don't think it would be worth it to implement this. Especially since having separate ERC-20 transfers makes accounting and inspection on Etherscan easier.

my guess is it would increase the stream capacity by 7-10

LOL

Why does the UI only allow 60 streams?

Good question: https://github.com/sablier-labs/v2-interfaces/issues/1271

[smol-ninja]

Boy was I wrong on the magnitude on this one! Only 5-10% 😂

Haha. Even I was shocked to see that. A simple ERC20 transfer consumes 31k gas so by that logic, 100 transfers should consume 3.1M gas.

When I disabled ERC20 transfer completely in the Lockup contract, it consumed 11.8M gas to create 100 streams with no token transfer compared to 12.4M with 100 transfers. So in this context, it costed ~0.5M gas to make 100 transfers (~5k per transfer). Thats 4 streams worth of gas.