Update on the ENS Streams: dates, rules and implementation

[AvsA]

I am very happy that the DAO has overwhelmingly voter in favor of creating alternate Streams for service providers. Next steps are in the hands of Metagov governance but I am here to offer my full support.

Dates:

I originally believed that ideally the selection should happen concurrently with the Election of DAO stewards. That’s a moment in which a lot of attention is being given to the DAO and its candidates and it seems they should go together. But that is also in a couple of weeks and I don’t believe there’s enough time to put the process together, and expect service providers to prepare a well thought budget plan. I still hope we should still plan to have the stream commence no later than February but that would still mean an election in January which might not be great. That should be in the hands of MetaGovernance (both the current and the next group).

Rules.

Nick and Catherine have criticized the wording of the voted snapshot on not being specific enough.
I have responded to that by opening a draft of the full rules for the working group, below. These are not final rules but a draft that I had previously shared with some interested parties and wrote using their feedback:

---

Rules for ENS Service Provider Streams

1. Objective

To support service providers contributing to the advancement and sustainability of the Ethereum Name Service (ENS).

2. Application and Selection Process

2.1 Eligibility and Submission

• Participants must have expertise in blockchain and ENS-related development.

• Submissions must be made on the ENS Forum and include a detailed proposal with objectives, milestones, timelines, and financial requirements.

• For increased transparency and accountability the main receiving address must be an ethereum contract or secure wallet that is directly controlled by the entity and must have its primary ENS name set.

• A Service Provider candidate must alert on their submission any potential conflict of interest or already existing financial relationship to the DAO other related entities. This includes (but is not limited to): a team member is also a Steward or Steward candidate (since Stewards are supposed to oversee Providers); a team member who already receives financial compensation for work related to ENS from another entity already being compensated by the DAO (ENS Labs, Karpatkey, other service providers or service provider candidates) and others. The Meta-Governance Working Group may, at their sole discretion, elect to impose conditions for the participation of the team in the case it is selected.

2.2 Calendar and Deadlines

• The application period will open concurrently with the 2023 steward election application window and the vote should happen in the same week as the election for the 2024 steward term.

• The meta-governance working group can, at their sole discretion, postpone the selection and submission deadlines for both this and the next selection cycles, to avoid scheduling conflicts with other governance events, major holidays or conferences. The first election must happen no earlier than february of 2024 and the next ones must happen before may of each year. Any need to postpone it further requires a social vote.

2.3 Proposal Requirements

• The meta-governance working group will release and may amend requirements and a prescribed format for applications.

3. Funding Rules and Budget Allocation

3.1 Stipulations on Service Fees

• Fees are to be proposed in increments of $200,000 USD per annum, with a cap of $1 million annually.

• Service providers must commit to operating for at least one year.

• A service provider who intends to cease operation after a specific date or deliverable must specify this in their application.

3.2 Voting Procedure

• The meta-governance working group will, at their sole discretion, curate proposal submissions and determine which will proceed to a vote. They will not unreasonably deny a vote on a valid proposal.

• The meta-governance working group will post a snapshot vote at the end of the application period.

• The snapshot vote will use approval voting, and include every service provider who submitted a valid application for consideration.

• Proposals must secure a minimum of 1 million ENS in approvals.

• A None of the Above option will also exist. Candidates with less approval than the NOTA should be disqualified.

3.3 Project Selection

Selection of winning proposals uses the following process:

• Sort proposals in descending order by the number of votes they received. For each proposal:

• If the proposal has fewer than 1 million votes, halt and do not consider any further proposals.

• If the proposal’s requested budget exceeds the remaining budget, skip the proposal and proceed to the next one.

• Otherwise, add the proposal to the set of selected proposals, and deduct its requested budget from the remaining budget.

4. Implementation

(see discussion below)

5. Reassessment and Termination and Notice Period

5.1 Reassessment and Renewal

• After a period of 12-15 months, a new vote must be taken place to reassess the stream. The process will be identical to the one outlined in 3.3 and current Service Providers must apply again, to show their commitment to continue providing service and have the opportunity to reassess their desired budget.
• The exact scheduling of the vote and application process falls to meta-governance working group can, at their sole discretion, under the condition that the new providers must start no later than 18 months after the beginning of the old stream, to guarantee that there will be no interruption of service.

5.1 Early Termination procedure

If a Service Provider becomes unresponsive or is deemed unfit by its oversight committee, and attempts to solve the issue privately have failed, then it may initiate the termination process as follows:

1. Raise the issue on a Working Group call and give a minimum 1 week period for the provider to respond publicly
2. If the issue is still unresolved, initiate a snapshot vote to remove the Service Provider, with a minimum of 5 days.
3. If the above vote passes, then an Executable proposal will be made to terminate the stream.

6. Output and Licensing

6.1 Open Source Requirement

• All outputs will be licensed under MIT

7. Amendments and Formality

7.1 Rule Modifications

• Changes to these rules can only be made by a simple majority vote of the ENS DAO with a Social proposal. The social proposal shall only be initiated after a minimum discussion period on the governance forum of five days.

8. Implementation and Oversight

8.1 Responsibility for Implementation

• The Meta-Governance Working Group will be responsible for overseeing the application process, funding distribution, and adherence to these rules.

8.2 Accountability

• Each provider should provide quarterly reports to the DAO, outlining the progress and impact of the funded projects.

9. Working Group Oversight

9.1 Designation of Working Groups

• Each approved service provider stream will be assigned to a specific working group which will act as the main point of contact and oversee the service stream.

9.2 Primary Oversight Responsibilities

• The Ecosystem Working Group will generally serve as the primary overseer. They are tasked with the following:

• Monitoring the progress of the service provider in relation to the goals set out in the proposal.

• Facilitating communication between the service provider and the ENS DAO.

• Initiating the termination procedure if the Service provider becomes unresponsive, insolvent, or encounters any major legal or ethical issue that makes the Working Group consider them unfit.

9.3 Delegation to Other Working Groups

• The Ecosystem Working Group may delegate oversight responsibility to the Public Goods or Meta-Governance Working Groups if the nature of the service is more aligned with their mandate.

10. Working Group Interactions and Boundaries

10.1 Inter-Working Group Collaboration

• Collaboration between the overseeing working group and the service provider should be regular and documented, ensuring transparency and accountability.

11. Financial Oversight and Budget Queries

11.1 Meta-Governance Group Role

• The Meta-Governance Working Group holds responsibility for questions regarding the overall stream and budget allocations. This includes:

• Approval of budget allocations for the service streams.

• Reassessment of budget allocations based on performance reviews and community feedback.

• Addressing any financial discrepancies or concerns raised by the overseeing working groups or community.

12. Communication and Reporting

12.1 Regular Updates

• Regular updates (at minimum once a month) will be communicated by the service provider to the assigned working group and summarized to the community through forums, community calls, or governance meetings.

12.2 Transparency and Access to Information

• All discussions, decisions, and relevant documentation will be made publicly accessible, maintaining the principles of transparency and accountability inherent to the ENS DAO.

---

IMPLEMENTATION

Finally how would the stream happen? I propose these options:

1) Use ENS Labs implementation: Ens labs has their own stream, which has been live since EP14.

Pros: It’s a very simple contract with less than 40 functional lines of code (ignoring ERC20 code and comments) and has been working for for over a year without issues. It doesn’t require almost any setup like moving funds or wrapping tokens: the current implementation simply has an approval to spend an unlimited amount of USDC from the ENS main wallet.

Cons: It’s a very simple contract. It doesn’t allow for multiple streams to different parties, it doesn’t even has a setting to adjust a stream rate. In fact the only way to stop the stream is to remove the approval at the USDC level in the DAO wallet. We would have to deploy multiple contracts for every provider every year – even recurring providers would have to either require us to redeploy new streaming contracts or give them unlimited approval on USDC which would add more risks.

2) Use Superfluid.finance

Pros: Superfluid also has been around for many years. It has been audited and battle tested with X millions of dollars for N years. The process would be: the DAO would have to wrap the USDC into a super-token wrapper (ideally we would only wrap enough to cover 18 months of stream so we have margin) and then approve different amounts of streams to the receivers. That would all happen in a single transaction. Superfluid allows the contract later to simply deposit (wrap) more tokens to extend the whole stream or adjust any particular stream (including adding more).

Because superfluid is a standard, it means streams can be divided and sent forward. This is useful in two ways: a provider can, instead of unwrapping their USDC, decide simply to give part of their stream directly to developers, further increasing transparency on the system. Another option would be the DAO to approve the full stream not to providers directly but to a wallet controlled by the working group, which could then create substreams to providers. This would allow them to take actions much more swiftly if needed or make new stream adjustments without a new executable vote (which can be a double edged sword). Superfluid has also a robust ecosystem of apps being built on this modularity, including streaming DCA exchanges like Ricochet and Aqueduct.

Cons: it is a more complex contract which has a bigger attack surface. Although it has been audited, increasing the exposure of any major contract can lead to new bugs being discovered and exploited.

Conflict of interest alert: I (Avsa) am a seed investor in Superfluid. I am an investor in them because I am a fan of streams as a concept and have been a user of superfluid for a while and not the opposite. Also, I am invested in ENS by much much more than superfluid

3) Other providers: Sablier, Llama, Sushi Furo, Ajira Pay

There is a healthy ecosystem of Streaming providers to choose from. I have not experienced most of them. I had tried out Sablier for a year but stopped using it because it lacked some important features (like the ability to extend a stream by adding more funds at a later date) which I really needed. As far as I know Sablier is focused mostly on token vesting and doesn’t have the “re-stream” capability that allows multiple streams to be daisy chained.

As mentioned I have a conflict of interest with Superfluid so I think I should not be the person to make that decision, other than personally endorsing them.

[nick.eth]

@AvsA

Next steps are in the hands of Metagov governance but I am here to offer my full support.

The vote doesn’t require the metagov WG to do anything specifically. Since this is your initiative, I think it is your responsibility to put forward next steps until this is codified in a way that can be implemented independently.

The proposed rules look good to me; here’s a few minor comments:

@AvsA

• After a period of 12-15 months, a new vote must be taken place to reassess the stream. The process will be identical to the one outlined in 3.3 and current Service Providers must apply again, to show their commitment to continue providing service and have the opportunity to reassess their desired budget.

@AvsA

The exact scheduling of the vote and application process falls to meta-governance working group can, at their sole discretion, under the condition that the new providers must start no later than 18 months after the beginning of the old stream, to guarantee that there will be no interruption of service.

Can you rewrite this for clarity?

@AvsA

If a Service Provider becomes unresponsive or is deemed unfit by its oversight committee, and attempts to solve the issue privately have failed, then it may initiate the termination process as follows:

This seems to imply that the service provider themselves has to terminate their stream.

@AvsA

If the issue is still unresolved, initiate a snapshot vote to remove the Service Provider, with a minimum of 5 days.

This should probably omit “with a minimum of 5 days” and say something like “in accordance with the rules for social votes”.

However, we’ve generally moved away from having social votes followed by executable ones when it’s a simple yes/no question; is there a particular reason to have two votes here?

@AvsA

Each provider should provide quarterly reports to the DAO, outlining the progress and impact of the funded projects.

The rules should state when these reports are due, and any consequences if they’re not posted.

[AvsA]

@nick.eth

The vote doesn’t require the metagov WG to do anything specifically. Since this is your initiative, I think it is your responsibility to put forward next steps until this is codified in a way that can be implemented independently.

Of course! Didn’t want to push the responsibility, but rather was avoiding overstepping my boundaries. I’ll be happy to keep the lead on this.

[NameSys]

Thank you for the detailed proposal. This work is highly appreciated among ENS developers!

@AvsA

A Service Provider candidate must alert on their submission any potential conflict of interest or already existing financial relationship to the DAO other related entities. This includes (but is not limited to): a team member is also a Steward or Steward candidate (since Stewards are supposed to oversee Providers); a team member who already receives financial compensation for work related to ENS from another entity already being compensated by the DAO (ENS Labs, Karpatkey, other service providers or service provider candidates) and others. The Meta-Governance Working Group may, at their sole discretion, elect to impose conditions for the participation of the team in the case it is selected.

@AvsA

Fees are to be proposed in increments of $200,000 USD per annum, with a cap of $1 million annually.

May we suggest that the proposed fees be in increments of $100,000 instead of $200,000? NameSys is interested in this stream but we prefer to stay small both in human and financial resources. We are mindful of organisational bloat and other geopolitical factors are also at play. $100,000 is essentially our self-imposed cap. Perhaps there are other small teams or individuals around who’d prefer finer granulation for xyz reasons.

[AvsA]

@NameSys

May we suggest that the proposed fees be in increments of $100,000 instead of $200,000?

It’s ok to do smaller increments, but the question is: if you need $100,000 do you think your goal cannot be met by a grant by another working group?

[NameSys]

There are no fixed funding programs in Ecosystem WG that offer amounts larger than $10,000 USD in practice. Considering the current draft, there is still a no man’s land between $10k and $200k. Systematic grants have been of the order $10k historically and small grants much smaller than that of course

[vegayp]

Maybe this was discussed in MetaGov already, but the post that is currently on the forum still mentions both elections happening at the same time.

@AvsA

I originally believed that ideally the selection should happen concurrently with the Election of DAO stewards. That’s a moment in which a lot of attention is being given to the DAO and its candidates and it seems they should go together. But that is also in a couple of weeks and I don’t believe there’s enough time to put the process together, and expect service providers to prepare a well thought budget plan. I still hope we should still plan to have the stream commence no later than February but that would still mean an election in January which might not be great. That should be in the hands of MetaGovernance (both the current and the next group).

Based on previously situations I strongly disagree with having those two votes at the same time, while the intention is positive, for a first time process, it would be better to have it alone, 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 would suggest keep this all submissions open during december, and after the new or recurrent metagov cohort is elected this is vote is put up, also:

• It will be extremely nice, if we take the time to give space for the candidates to expose their cases, and educate the community on who they are voting for, let’s not fall into the social agreed lied that the forum is enough to inform the community haha.

I agree for the rest of this idea, thank You Alex for putting all this together.

[AvsA]

@vegayp

Based on previously situations I strongly disagree with having those two votes at the same time, while the intention is positive, for a first time process, it would be better to have it alone, 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.

All the teams that I talked said they would have it sooner rather than later. I think the process is rather straightforward and should not require lots of work, it’s just a description of projects on the forum, you don’t need to do much.

But if we think that by the closing date there aren’t enough quality submissions we could consider postponing it.

[vegayp]

Sorry to insist on this Alex, even more reasons for my to push back.

@AvsA

All the teams that I talked said they would have it sooner rather than later.

This is an open call, not a tailored proposal. An open DAO proposal, unless intended, should never be based on how it would be favorable for people who can benefit from it in advance, because unintendenly, we are providing an advantage over others who haven’t talk to you (for example).

Nevertheless, I don’t understand why there’s a hurry to push forward an amazing idea like this. Nothing good comes from hurrying a governance process unless it benefits the result, and I don’t see it how this would be the case.

[prberg]

Chiming in to share my thoughts on the payment solution to use for these $ENS streams. As founder of Sablier, I am obviously biased, so take my response with a grain of salt.

The advantages of using Sablier over Superfluid are the following:

• Peace of mind. Sablier has been on mainnet since 2019, and it has never been hacked while processing hundreds of millions in TVL (see our DeFiLlama page).
• Security-first. We have an OCD about smart contract testing and security. See some praise here, here, and here. Also, see our audits here (our lead auditor was Zach Obront).
• 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.

Then, the advantages of using Sablier over the simple ENS contract:

• Batteries-included: Using Sablier gives you access to our end-to-end platform, including our user interface and our Safe integration.
• Gas efficiency: Creating a Sablier stream means calling a function in a pre-existing contract deployed by us. You don’t deploy different contracts for each grant recipient.
• Multiple streams. It is possible to create up to 100 streams in bulk using Sablier V2.
• Transferability. Sablier V2 streams are represented as NFTs, which means that recipients have the ability to transfer them (e.g. to a new cold storage device).

Similar comparisons apply to the other competitor products mentioned.

If you decide to use Sablier, we would be happy to review the governance proposal code. You can ping me personally on Telegram, or reach out to our team on Discord.

Thank you for your consideration and support. Regardless of the final decision, I am glad to see the concept of money streaming becoming more popular.

@AvsA

Superfluid also has been around for many years. It has been audited and battle tested with X millions of dollars for N years.

It is worth noting that Superfluid was hacked in Feb 2022. Hackers stole $13M worth of user funds.

Sablier has never been hacked.

@AvsA

I have not experienced most of them. I had tried out Sablier for a year but stopped using it because it lacked some important features

I think you would appreciate some of the features we implemented this year, such as non-linear streaming and hourglass NFTs

@AvsA

it lacked some important features (like the ability to extend a stream by adding more funds at a later date)

This is the only con with Sablier, but it seems to me that all the ENS amounts will be known in advance, and the DAO obviously has enough ENS to fund the streams upfront.

[accessor.eth]

I agree with @vegayp . I believe that is too much going on at the same time. Depending on the outcome of the election, there may or may not be the same stewards in position. This is sort of a lot to throw on people, in the event that there are 3, 4 or 5 + new stewards. This we do not know. This is a big project with large amounts of funds being distributed. If new stewards are breaking in, then we shouldn’t expect seasoned folks to direct teach and execute.

[accessor.eth]

Should the Steward Election and ENS Stream vote happen at the same time?

• Yes
• No
• Unsure

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