Update on the ENS Streams: dates, rules and implementation

[5pence.eth]

I’ll add my thoughts on the timing:

@vegayp

plus 15 day isn’t really enough time to prepare a proper submission, knowing that it’s the end of the year and a lot of teams were probably caught by surprise by this.

I do not agree that delayng the date would make the proceess more open or more fair. The submission requirements aren’t too daunting, and if a potential group doesn’t already have a general sense of their structure and goals, then they likely aren’t the right candidate for this round.

@accessor.eth

I believe that is too much going on at the same time

I agree with the sentiment that it will add complication to run these concurrently, and I initially agreed we should separate them.
After deliberating, I don’t think the alternatives are better when we net out the outcomes.
For instance, the perfect scenario would be to run the stream provider selection right before the elections, but that’s not really an option here. We can’t move stream provider forward, and we can’t push back the steward elections without an even bigger undertaking in a very short period of time.
Moving the stream provider selection to a later date could be an option, but it doesn’t really solve any of the issues other than spreading out the activity instead of having a surge.

All things considered I think it would be fine to have them concurrent. Any new stewards will be helped by the outgoing stewards. We tend to be pretty cooperative.

Also important is that there are small efficiency benefits for the delegates to have the voting and research batched.

[accessor.eth]

@5pence.eth

Also important is that there are small efficiency benefits for the delegates to have the voting and research batched.

This is also valid. Could be the most streamline process ever! Maybe I should be a smidge more OP.

[nick.eth]

@prberg

• Simplicity. No wrapper tokens. On Sablier, you stream the actual ENS tokens. Neither the DAO nor the grant recipients would end up with multiple token balances.
• Stress-free UX. Sablier streams are autonomous and cannot be liquidated. Whereas Superfluid streams require monitoring - if the ENS were to use Superfluid, the DAO would have to monitor and top up the wrapper token balance, otherwise a fee would be charged by a liquidation bot and the streams would have to be re-created.

Just to make sure I understand what you’re saying here - if we intend to stream USDC, we can give the Sablier contract a USDC allowance, and start an indefinite stream, meaning the funds will accrue to the recipient as long as the stream remains open and the DAO wallet has sufficient USDC?

If so, that’s a very good UX; the lack of that is why I created a custom stream contract for the ENS Labs stream.

[mdali.eth]

Hello there, we are excited that ENS has chosen streaming for these payouts! We have been monitoring this forum from the sidelines without stepping in to ensure transparent and unbiased decision making by the ENS community.

We are honored to have been working with ENS before (streaming these scholarships), and we’d love to continue supporting the team and community hands on.

We’d like to add further context to Paul’s post (Sablier’s Co-founder, a competing protocol) for fair play and posterity. We’d also like to keep the subject of the conversation focused on benefiting the ENS community and not triggering a ping pong of technology comparison, for how possible.

Benefits of using Superfluid:

• Amount of funds at risk. Superfluid has been intentionally designed to leave funds in the user wallets minimizing TVL on smart contracts and the overall funds at risk, unlike Sablier it doesn’t require all funds to be locked in a smart contract in order to be streamed. Opting for Superfluid would allow ENS to have all funds in a wallet (or Safe) with exposure to the protocol equal to at most one week worth of the streaming amount, at all time. We can expand further on this if needed.
• Security. Superfluid has been live since March 2021, with over $100M streamed to date. After the exploit of Feb 2022 the protocol has been further audited and bug bounty programs have been running since. The latest audit was just completed with Trail of Bits, among the top auditors in the industry. As will be highlighted by the audit report, our testing standards are some of the highest in the industry. In ToB’s words: “The test suite of Superfluid is considered very thorough. There are unit tests, integration tests, fuzzing tests, invariant tests (using both Foundry and Echidna), and tests using the Certora Prover.” While Sablier V1 has been live for a similar timeframe, Sablier V2 has been on mainnet for just a few weeks.
• Flexibility. Superfluid streams can be scheduled, edited, paused, restarted and extended at will based on the circumstances, you would be able to halt ongoing streams, extend them or schedule a future end date for them. This can be automated via a smooth UI.
• Composability. Recipients can seamlessly redirect Superfluid streams to another wallet, DeFi, or can swap to other assets on other chains within our Dashboard UI in a few simple clicks. There is no need to claim as assets are immediately available and spendable in the recipient wallet.
• Wrap vs deposit. The liquidity for Superfluid streams is a user’s “wrapper token” balance. By wrapping more tokens, you can extend all of your streams in a single transaction. This increases security, as funds can be added to the contracts a bit at a time, rather than all upfront.

On the advantages of Superfluid over the ENS contract directly:

• Simple UI. You’ll be able to start and manage streams from our smooth Dashboard, or Safe app, having full control over your spending. Recipients can visit a public link to see their stream status, on mobile too. A public explorer is also available for third party auditability by community members.
• Bulk streams. Set bulk streams as needed, minimizing the number of transactions (up to 200 new streams per transaction), even from a simple CSV file.
• Efficient. Streams require gas only to be started or edited, they keep running without incurring in gas fees. No new contract deployment required.
• Composability. Recipients can redirect the stream as they are receiving it, allowing them to compound in real-time via DeFi, or forwarding them as they please. A grantee could pay their team directly by chaining their streams, something which wouldn’t be possible with alternative solutions.
• NFTs. All Superfluid streams are also NFTs.

We’d like to hear your questions, concerns and ideas and help guide you towards the solution that fits this proposal best. Please reach out to me on Telegram and Twitter/X DMs, we’d be happy to help.

@nick.eth

[…] if we intend to stream USDC, we can give the Sablier contract a USDC allowance, and start an indefinite stream, meaning the funds will accrue to the recipient as long as the stream remains open and the DAO wallet has sufficient USDC?

My understanding is that this is not possible using Sablier, while it comes out of the box with Superfluid streams (open ended), including a simple yet comprehensive UI for both sender and recipient to view and manage the streams.

The ongoing scholarship streams can be seen here.

[AvsA]

Thank you @prberg and @mdali.eth for the input on the technical details of the fund. It’s important to have these inputs before comitting to such large amounts. I don’t think such technical decision should be put to a DAO vote, but rather we could appoint a technical committee for that. As I mentioned, I should excuse myself from such committees since I am biased.

But here are the requirements, in my opinion, for the stream:

• Solid audited code and long time on the market: I think both companies have a solid reputation and are equally qualified
• Capability of having a single continuous renovated stream: The purpose of the stream is to be continuous. If the program is successful, which I am sure it will, we want the streams to continue uninterrupted, without skipping a block. We need to be able to extend the renovation date, change the stream quantities and include more or less stream receivers in a single block
• Simple and safe opt in for the DAO: Ideally we want a way for the DAO to reduce its exposure to the smart contract risks. I thought initially that we would need to put over 5M in a stream to ensure it would work for at least a year and a half (considering the new election might not be in an exact year), which was something I felt uncomfortable. But if it’s possible, as Nick is proposing, to simply set a USDC allowance for a very simple contract, and then put smaller amounts on the stream every other week, that is much preferable.
• Little upkeep: as mentioned, we don’t want the DAO to be monitoring the streams all the time. The DAO is built to only make very specific actions, under a high vote, so it cannot do quick responses or constant upkeep. We need something that once we set, it will be taken care for either automatically or by a bot run by the providers.

Paul, could you clarify if Sablier does all of that currently?

[prberg]

Thanks for the color @AvsA and @nick.eth.

I couldn’t tell from the OP that you’re looking for an open-ended streaming solution, but that is clear now. In this case, the solution is to use Superfluid or LlamaPay, as both the simple ENS contract and Sablier are closed-ended (for now). However, it might be still worth considering Sablier for those applicants that are looking for a one-time grant with a specific stop date.

@AvsA

I thought initially that we would need to put over 5M in a stream to ensure it would work for at least a year and a half
…
if it’s possible, as Nick is proposing, to simply set a USDC allowance for a very simple contract, and then put smaller amounts on the stream every other week, that is much preferable

Isn’t this just trading smart contract risk for allowance risk and bot private key theft risk?

As I understand it, the weekly funding wouldn’t come from the DAO treasury (since you also want little upkeep).

@nick.eth

if we intend to stream USDC, we can give the Sablier contract a USDC allowance, and start an indefinite stream, meaning the funds will accrue to the recipient as long as the stream remains open and the DAO wallet has sufficient USDC?

Unfortunately, we don’t support this functionality at the moment. However, we will have something in the near future.

@nick.eth

the lack of that is why I created a custom stream contract for the ENS Labs stream.

If you have features requests like this in the future, feel free to recommend them to us, and we will turn them into end-to-end products for you and the rest of the Ethereum community.

@mdali.eth

We’d like to add further context to Paul’s post … for fair play and posterity.

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

@mdali.eth

While Sablier V1 has been live for a similar timeframe … Sablier V2 has been on mainnet for just a few weeks

V1 was launched in December 2019 (so not so similar timeframes), and V2 in July 2023 (so it’s been live for almost 5 months). V2 is also one of the most highly-praised Solidity code bases (just search “Sablier V2” on X).

Anyway. As you say, the goal of this post is to benefit the ENS community. This is a genuinely interesting conversation and I want to thank @AvsA again for popularizing money streaming.

[nick.eth]

@prberg

I couldn’t tell from the OP that you’re looking for an open-ended streaming solution, but that is clear now. In this case, the solution is to use Superfluid or LlamaPay, as both the simple ENS contract and Sablier are closed-ended (for now).

If by “open-ended” you mean “has no stop date”, the simple ENS contract is open-ended.

@prberg

Isn’t this just trading smart contract risk for allowance risk and bot private key theft risk?

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

@prberg

Unfortunately, we don’t support this functionality at the moment. However, we will have something in the near future.

Would it be possible instead to instantiate a new stream that starts at the block after the previous stream ends, so it has the same effect?

[prberg]

@nick.eth

If by “open-ended” you mean “has no stop date”, the simple ENS contract is open-ended.

Yes, that’s what I mean.

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:

@nick.eth

it just reduces administrative overhead (no need to wrap tokens, etc).

This feedback is super helpful, thanks for confirming.

@nick.eth

Would it be possible instead to instantiate a new stream that starts at the block after the previous stream ends, so it has the same effect?

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).

[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?