Request for range(d) airstreams

[razgraf]

A user requested the following feature for airstreams: a synchronized end time for all streams claimed from an airstream campaign.

This would involve setting a specific end time for all streams, such that all claimed streams end on the same date. It basically results in support for createWithRange alongside the current duration-driven claim function.

Some questions:

• What should the start time be set to? The claim date (meaning streams will end up with different durations) or a hard value provided by the admin at campaign creation?
• Should the end time have any connection to the airstream's expiry date?

[PaulRBerg]

Thanks for this. Feel free to use the @sablier-labs/@engineers group or tag people directly so that these discussions end up in our email inboxes.

[PaulRBerg]

Interesting proposal. I see why it can be useful for users.

What should the start time be set to?
...
(i) The claim date (meaning streams will end up with different durations) or (ii) a hard value provided by the admin at campaign creation?

The latter seems more desirable. I have a hunch that that's what 5ire wants (though they should confirm).

1. Different start times would mean different streaming rates.
2. Hard-coded start times would mean identical vesting periods even when the airstream is not claimed.

Should the end time have any connection to the airstream's expiry date?

In most cases, they would have the same value, but they should still be maintained as separate variables for flexibility purposes.

[smol-ninja]

In most cases, they would have the same value

Why would the expiry date have the same value as the end time?

One identifies whether the airstream can be claimed and other identifies the end date of a claimed stream. So, I think, in most cases, expiry date would be less than the end time (longer vesting but shorter claim window).

[PaulRBerg]

Good point. I think we need to ask users what they want.

[PaulRBerg]

Looks like they (5ire) want the start time to be the claim time:

[smol-ninja]

Wow. So that means different streaming rates for each claim.

[PaulRBerg]

Yep, though there's nothing wrong with that

[adamgall]

For what it's worth, the team at @decentdao have this exact same feature request :)

[PaulRBerg]

Another reason to implement ranged airstreams: monthly unlocks for airstreams.

[smol-ninja]

Request from Arcana for Airstreams ending on the same date:

[PaulRBerg]

Kinda obvious at this point that the next version of Lockup will include ranged airstreams

[smol-ninja]

I have started a discussion that can enable range(d) airstream

• Replace `createWithDurations` with `createWithTimestamps` in Airstreams v2-core#997

[PaulRBerg]

Just received a request for this feature from Protocol Guild, a potentially large user.

@smol-ninja could you refresh my mind on this, please? I gather that we have already implemented this feature through the following PRs:

• Allow end time of lockup streams to be in the past v2-core#982
• feat: use createWithTimestamps in claim v2-core#1024

Right?

CC @sablier-labs/frontend since this will have to be implemented in the UI, too

[smol-ninja]

Yes thats right. Here is the discussion: sablier-labs/v2-core#997. createWithTimestamps in Airstreams enables ranged streams whereas allowing end time to be in the past enables instant airdrops (without even to have 1 second stream like how we are doing it rn).

[adamgall]

The team at @decentdao has this same feature request. We would love to be able to create Airstreams in which the "start time" of each stream is the claim moment, and the end time for each stream is hardcoded at Airstream creation and the same for each of the Airstreams.

[PaulRBerg]

I suppose that you want something like this, don't you?

• First chart: user who claims on day 1
• Second chart: user who claims on day 8

[adamgall]

Yes @PaulRBerg that's what I'm looking for! It's likely relatively trivial for me to create an intermediate smart contract to support this behavior myself, using your standard Streams (not Airstreams) product.

I'll take that approach for now.

Thanks!

[PaulRBerg]

Thanks for confirming!

And glad to hear that an intermediary contract works for now. Will it be open-source? If yes, could you maybe link it here once it's done?

Thank you!

P.S. here's a relevant page from our docs: Configure Your Local Environment

[adamgall]

I've actually taken this conversation back to my team, and we have some more product requirements to work through. If I do end up needing and implementing this contract, I'll definitely share here.

[PaulRBerg]

Thanks for the update. You are welcome to ping Max on Telegram (handle: maxdesalle) if you would like to brainstorm the implementation.

[razgraf]

We've gotten another user request for drops where vesting starts at the same time for everyone.