“The Interceptor” looks like a great product that enhances user safety - but service provider proposals should be for organisations building ENS ecosystem components. The Public Goods working group provides funding for wider ecosystem projects, but the service provider streams are targeted specifically at building new core infrastructure for ENS.
service provider proposals should be for organisations building ENS ecosystem components. The Public Goods working group provides funding for wider ecosystem projects, but the service provider streams are targeted specifically at building new core infrastructure for ENS.
@nick.eth The rules don’t say that, and in fact they make provision for teams focused on areas beyond the direct ENS ecosystem.
9.3 says: “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.”
Because of this, I plan on applying for the streaming funding for my Ethereum Follow Protocol team, which is mostly not building tools directly for the ENS ecosystem narrowly understood, but something that certainly complements and enhances the value of ENS.
Of course, what actually gets funding or not will be up to the voting.
Hey Nick, thank you for your interest in The Interceptor! We feel that our project would be useful for ENS. While we do a lot of work for Ethereum public goods (eg, the eth_multicall), we feel that the ENS integration work that we are planning to do is less fitting for that category (but maybe I am wrong?). The ENS integrations require custom ENS specific stuff, eg, when you are renewing an ENS domain (this is where we have identified that most ENS related scams happen) we want to show users customized ENS views. We feel that if people are more informed on what they are doing on ENS, the more likely they are also to use ENS.
Could we please keep this thread only for nominations and move discussion about the candidates on a separate meta-thread please?
The rules explicitly say “projects to improve the ENS system”. What that means is left purposely a bit vague to see what delegatea interpret of that phrase. The rules also allow meta-gov some room on reasonably denying candidates that are too out of scope.
Thanks Alex, I’ve moved this to its own thread.
Alex cites the relevant part of the proposal to this. I certainly see the point of the streams at being aimed at teams building core ENS infrastructure and tooling. As such, I don’t think projects like The Interceptor, Ethereum Follow Protocol, or Tokenscript are in-scope. I personally won’t be voting for anything that isn’t 100% focused on ENS, rather than just using ENS as a component.
@avsa, how much curation do you expect Meta-Gov to perform on this list before voting? Should every proposal that meets a basic quality bar be included, or should it be limited to proposals that the Meta-Gov WG think are productive?
The stream provider rules explicitly start with:
“Objective: To support service providers contributing to the advancement and sustainability of the Ethereum Name Service (ENS).”
It is clearly NOT meant to be a general grant for Ethereum projects, but rather specifically about advancing ENS.
But now of course, that is open to interpretation. What does it mean to “improve ENS”? Does having a better usability on Ethereum wallets benefit ENS? Does having a decentralized social media benefit? Does that answer change if we are talking about supporting an upcoming project or something established that already serves millions of users in different integrations in many social media apps?
I have my own answers. The way I will be judging them will be mostly “If a meteor strikes the next ENS Labs team retreat, will these projects be able to keep the ball rolling?”. But of course that is my take and not a hard rule written anywhere. I have the opinion that we should allow delegates to judge if these projects help “improve the ENS system” (and make that question clear on the snapshot vote). And it should fall on these projects to prove to the delegates that they are not only good projects that deserve funding, but that doing so will “contribute to the advancement and sustainability of ENS”.
In this sense, I think it would be better if Meta-gov’s used its curation power to remove only projects that are most likely not be functional. Projects that nobody ever heard of the team, that have no working website, that never had any relationship with the ENS community, that are just promises, etc.
We believe that the DAO (Meta-Gov) should set out clear rules and eligibility guidelines for the streams. In the beginning during ENS Small Grants launch, there were many long & painful discussions about projects that used to qualify for both Public Goods as well as the Ecosystem WG; DAO eventually put the foot down and set out clear rules that sorted the issue out once and for all. It wasn’t ideal but it has worked well. Ambiguity only leads to more unrelated projects trying to extract value out of popularity-based voting systems.
One tangible solution could be to simply check if the project makes dedicated
write calls to ENS contracts. We have generally observed that a project is unlikely to be ENS-dedicated if it doesn’t at least make dedicated
write calls to ENS contracts, as opposed to only
view calls (e.g. integrations).
Just our two cents!
I am looking to secure endorsement to nominate tallyxyz.eth to the service provider stream.
Tally is a frontend for decentralized organizations and we’re happy to have supported ENS for a while now. We recently became aware of this fantastic opportunity to self-nominate as a service provider and we’re keen to expand our engagement with ENS!
We will submit our nomination by EOD tomorrow, just in time
Thanks all—we are looking forward to the possibility of contributing to the ENS community and ecosystem!
I’ve been triaging service provider nominations for the upcoming vote, and have identified issues with several proposals. I’m raising them here so that applicants have an opportunity to fix them before the submission period closes.
@viniciusbedum @hodl.esf.eth @bobjiang Your proposals do not yet have the required 10k nomination votes. If they don’t reach 10k by the time the application window closes, they cannot be included in the vote.
@encirca @russell You need to post a link to an endorsement vote on Snapshot as specified in the rules. Even if you are “self-endorsing”, this is necessary in order to prove that you control the wallet concerned, and in order to adhere to the rules defined for the stream process.
I’d also like to invite applicants to update their applications with a one-paragraph summary of their project and proposal, to be added to the text of the Snapshot vote for streaming provider selection along with a link to your full proposal. If you don’t provide one, I will attempt to write one to the best of my abilities.
Note that fixing any issues identified here does not guarantee inclusion in the final ballot, as Metagov WG stewards reserve the right to curate the list of applicants, as per the rules.
It reads: " If your main address or your point of contact address has at least 10k delegated or owned ENS then write “self-endorsement”. You have completed the requirement." in the rules here Service Provider Stream Nomination Thread
Hey @nick.eth thanks for the update.
The snapshot space is currently experiencing some issues on the admin side, that are being worked on. We opened a support ticket.
In the process outlined the language was:
If your main address or your point of contact address has at least 10k delegated or owned ENS then write “self-endorsement”. You have completed the requirement. OR…
Post a link to a social media post or a thread in this forum or a signed ethereum message with an endorsement from a delegate with at least 10k delegated ENS. OR…
Go to nominations.ens.eth 22 snapshot and create a new proposal with title “Nominate example.eth to Service Provider Stream” and options being “For / Against / Abstain”. That proposal must have at least 10k votes by December 1st for your nomination to be valid.
The way we read that was that either of the three ways was fine. Let me know if this is not the case.
Happy to go the Snapshot route once it is fully operational again.
My mistake on the nomination requirement.
@avsa I think this needs revising, as without a vote or a signed message, we have no way to verify that the applicant is actually the owner of the account that has sufficient votes.
It’s a bit confusing to me, it does say 100%. How short am I?
Our forum posts have a “verified” badge with the vote count. While this is not as hard cryptographic proof as a signed message, I would consider that enough proof for the nomination threshold. Would you agree?
@hodl.esf.eth yes, if you have 10K “for” on your nomination then you’ve crossed the threshold.
On a side note to everyone: we are aware of issues with the nominations.ens.eth space. I have set up an alternate snapshot space at ens-streams.eth in which anyone with at least 0.1 ENS can post (snapshot required me to have some sort of minimum requirement). Please notice that this is just a way to facilitate the proof of ownership of these tokens, any other snapshot, or verified social media or even a signed message should do the same.
I see your point there. Also good idea with the paragraph summaries. Will get after that asap.
Let me know if snapshot is better and we’ll go that route. Whatever works best.
There’s no actual proof that a forum account owns the account that they are claiming to be associated with; it’s operating mostly on the honor system so far.
Any of the methods provided in the doc will suffice for this instance. We can iron out the best practices for next time.
Was able to post proposal in new Snapshot.
Looking for support for ENS anti-abuse project. Please provide support and/or comments in the new ens-streams snapshot here:
I have recreated your endorsement link with the correct title. Here you go:
Ah I see. I thought we had a verification to have the badge…
Tried posting to snapshot, getting an error (proposal limit)