Update on the ENS Streams: dates, rules and implementation

[nick.eth]

@prberg

Would you mind sharing a link to the code? I looked up the contract shared by Alex in the OP and that seems to be closed-ended:

Sorry, yes, you’re technically correct - but the end date was set to type(uint256).max so it’s practically speaking open-ended.

@prberg

Yessir! There are two ways to create closed-ended streams on Sablier V2:

1. Create with Range: fixed start and end times
2. Create With Durations: uses block.timestamp as the start time

With Create with Range, you could create a 2nd stream that starts immediately after the 1st stream, regardless of when the governance proposal is passed and executed. The recipient would see all these streams aggregated in the Sablier dashboard, which makes it possible to withdraw from multiple streams with one tx (and so the distinction between one-vs-many streams gets abstracted away for end users).

That seems like it would be viable, if we’re planning to review streams at least annually anyway.

[prberg]

@nick.eth

the end date was set to type(uint256).max so it’s practically speaking open-ended.

Ooh, interesting!

@nick.eth

That seems like it would be viable, if we’re planning to review streams at least annually anyway.

I will show a demo to the Metagov stewards on the community call later today.

[mdali.eth]

@nick.eth

Yes, using an allowance doesn’t reduce smart contract risk, it just reduces administrative overhead (no need to wrap tokens, etc).

To drastically reduce admin overhead we introduced AutoWrap that periodically wraps just enough tokens to keep all outgoing streams flowing and adjusts automatically when new streams are opened or closed. Similarly editing planned start and end dates anytime allows for a smooth set-and-forget mindset.

A hacker would have to exploit both the AutoWrap contracts (which are rather water tight) and the main protocol contracts to steal user funds, while this doesn’t eliminate the risk entirely it mitigates it substantially.

@prberg

Debating competing service providers is the right approach. Other DAOs should follow in the footsteps of this ENS post.

@nick.eth can you share the ideal administrative process? It would inform all streaming providers and help us refine the solutions we provide to ENS and the broader Ethereum community.

From what we know, the main drivers are minimizing governance and/or multisig transactions and having a smooth UX for both sender and recipients to control and manage the funds. It would be great to learn more about this, probably on a separate forum or channel (ie ENS Discord) to keep the proposal comments clean.

We’d happily join the call later to assist with any ideas or hands on support. Thanks again for selecting streaming as the payout option, it helps showcase crypto-native primitives that are uniquely enabled by this technology.

[AvsA]

Thanks both @prberg and @mdali.eth for the respectful and great discussions!

@prberg

With Create with Range, you could create a 2nd stream that starts immediately after the 1st stream, regardless of when the governance proposal is passed and executed

That’s interesting. I agree that having a stream start just after the other is in practically the same of a single open ended contract (of course, considering gas costs). A stream with a date far in the future which can be cancelled (and doesn’t need full upfront costs) is also the same, would that be practical?

I look forward to participating on the call today.

[nick.eth]

@mdali.eth

A hacker would have to exploit both the AutoWrap contracts (which are rather water tight) and the main protocol contracts to steal user funds, while this doesn’t eliminate the risk entirely it mitigates it substantially.

Couldn’t they just exploit the main contract, then wait for autowrap to giftwrap some more funds to steal for them?

@mdali.eth

@nick.eth can you share the ideal administrative process? It would inform all streaming providers and help us refine the solutions we provide to ENS and the broader Ethereum community.

Do you mean the administrative process for selecting a service provider? Or the process for administering the streams?

[mdali.eth]

@nick.eth

Couldn’t they just exploit the main contract, then wait for autowrap to giftwrap some more funds to steal for them?

As soon as the main contracts are exploited, every sender could simply pause AutoWrap and prevent further losses. Tokens stay in the sender wallet, they don’t need to be sent to the contracts upfront. The beautiful feature of streaming vs one-off payments is that senders can react based on circumstances and edit the value flow as needed (i.e. even if the recipient provides the wrong address for example).

@nick.eth

Do you mean the administrative process for selecting a service provider? Or the process for administering the streams?

I was referring to the ideal streaming solution (and user experience) based on the current ENS admin processes, funds management setup and features needed.

@AvsA

I look forward to participating on the call today.

Looking forward to it too!

[prberg]

@AvsA

I agree that having a stream start just after the other is in practically the same of a single open ended contract (of course, considering gas costs)

Glad to hear

If the streams are due to be reviewed once per year, the gas costs should be negligible. Certainly less than relying on a bot to fund a stream every week.

@AvsA

A stream with a date far in the future which can be cancelled (and doesn’t need full upfront costs) is also the same, would that be practical?

It is possible to set the start time to a date far in the future but the stream has to be pre-funded.

This is another great feature request - noted it down!

[SLE]

Hey everyone, Lindsey here from Hedgey.

I’ve been following the conversation this past week and now that the discussion is including various approaches to creating the streams I thought I’d introduce ourselves at Hedgey for anyone who doesn’t know us, as well as share info on our streaming solution and how it might be helpful for what ENS is trying to do here.

As a caveat, I’m a huge fan of SuperFluid and think that the approach they have or the OG ENS stream contracts both seem to be great approaches based on the needs/concerns shared by @AvsA and @nick.eth, but want to share what we do as well if only to add to the discussion.

For background, Hedgey creates onchain token streaming/vesting products and over the last two years has worked with Arbitrum, Celo, Gitcoin, Shapeshift, Bankless DAO and 40+ other onchain orgs to help them streamline onchain token distributions.

Our contracts are audited by Consensys Diligence and most recently are being used by Arbitrum to distribute 45m ARB to Arbitrum STIP grant recipients over the next 3 months, with appx. $12m in ARB being paid out so far this month.

A few notes on Hedgey streams related to the conversation:

Hedgey streams are prefunded. The tokens will be held in an escrow contract and claimable by the recipient at the predefined rate.

Streams can be future dated. If the DAO wants to issue 12 month streams, back to back, they can do so.

Streams can be created in bulk. You can issue every recipient’s stream for this program in a single transaction.

These Hedgey streams would be non-transferable by the recipient. We do this to make sure revocable, unvested payment streams aren’t transferred or sold.

Public Dashboards for the DAO w/ ENS name support. Every stream would be aggregated into an ENS public dashboard where the DAO can view and track every stream in real time. We show ENS names for recipients by default and have done so for a while now. See our Arbitrum Public Dashboard.

Great UIs for stream recipients. Every recipient will be able to track and claim tokens from Hedgey’s platform by connecting their wallet.

The DAO can optionally assign a multisig to manage streams. If the DAO wanted to assign a multisig as admin, the multisig could act on the DAOs behalf during special circumstances such as canceling streams and clawing back unvested tokens from canceled streams.

The admin address can optionally be allowed to redirect streams. If turned on, the DAO (or admin) could transfer a stream on behalf of the recipient without losing both unvested and vested but unclaimed tokens. This would be useful if a recipient loses access to their wallet over the duration of the stream.

Accounting integrations with Entendre and can easily integrate with any preferred partner of the DAO or recipients.

I know that I’ve come into this discussion after the meta-gov call, but I’d be happy to participate in any future calls or conversations if helpful for making the decision. Although we haven’t worked with ENS directly yet, we have been able to meet a bunch of the DAO contributors over the last year+ and are huge fans of how the DAO operates and would love to be useful to the crew here with what we build. Regardless of the outcome here, really love the program you’re putting together and think it’ll be huge for ENS. Thanks for the consideration

[AvsA]

@lcfr.eth this is not a handout, nor a grant for past work. This funds for services to be executed for ENS DAO, which will be paid while the DAO believes the service is being done.

[accessor.eth]

I would like to suggest an outline for mid stream provider reviews.

[accessor.eth]

I was kind of under the impression that these stream proposals were supposed to be be geared towards providing a service directly to the DAO rather than an open door for think tanking innovation as a product that serves end users directly.

It was expecting to see dedicated in-house forum for the DAO, a special outreach team that finds solutions for companies who want use ENS but not know where to start, sub-working groups or even event coordination teams. Seems I interpreted wrong congrats to all the winners

[accessor.eth]

is there any opinion about using this as a template?