Temperature Check - Should ENS governance contribute funding to the Nomic Foundation?


  • Nomic Labs, the team behind Hardhat, has become the Nomic Foundation, a non-profit organization dedicated to Ethereum. Our mission is to empower developers to decentralize the world.
  • The Nomic Foundation’s work will be focused on Ethereum’s developer platform with the objective of achieving a world-class developer experience, and generally improving Ethereum’s public goods support structures.
  • Hardhat is the de facto standard developer tool used to build Ethereum software, with more than 23000 Github repositories using it and tens of thousands of active users. Prominent teams relying on it include ENS, Uniswap, Optimism, OpenZeppelin, Aave, Balancer, Chainlink, Synthetix, and many more leading teams.
  • The new foundation will expand the Hardhat suite of tools and, most importantly, build long-term infrastructure to catalyze organic growth in the Ethereum tooling ecosystem, decreasing Ethereum’s dependence on any one organization to build and maintain core development platform components.
  • Seeking $30m in total funding from the ecosystem. Donations of $15M already secured by the Ethereum Foundation, Vitalik Buterin, Coinbase, a16z, The Graph, Polygon, Chainlink, a16z, and Kaszek Ventures.
  • We’re proposing to ENS Governance to make a contribution between $1m and $4m to the Nomic Foundation to support its mission. We’d love to hear your thoughts about what’s the right amount.

What is developer experience?

If you are already familiar with this concept feel free to skip this section, if you’d like to learn more, keep on reading.

Understanding developer experience starts with realizing that software development platforms are multi-layered technical products and that software engineers are their users. Developer experience is analogous to UX for software developers, particularly UX in professional tools that are essential for abstract tasks and have direct impacts on productivity, effectiveness, happiness, frustration, and therefore cost.

The practice of software development is a complex discipline, and developer experience is significantly different from the UX of a note-taking app. When a professional is working on an intricate problem that requires deep thinking and accessing information via a tool, or when one’s creative output is directly limited by the capabilities of their tool, then the professional will be directly restricted—or empowered—by the tools being used.

An additional aspect that may not be obvious and emphasizes the impact tooling has, is that developers frequently don’t understand what they’ve created. Writing code that doesn’t behave as expected is routine, and the process of making it work as expected (debugging) is one of the core activities of software development, which is heavily aided by development tools.

Developer experience is about the effectiveness of interactions with platforms and their tools, as well as the feelings that arise when trying to meet a specific software development objective with them.

Empowering users to create something without knowing what they’re going to be creating is a difficult challenge. The author of a tool or platform cannot optimize for a specific use case, only for the abstract needs of software development in general. In addition, the development platform that software is built on ultimately becomes part of the software itself, and very often, the software directly interacts in some way with the tools.

Since the created software is dynamic and has a limitless life of its own, it’s easy for tools and platforms to end up constraining what is created or how. Software development, in general, is a moving target that keeps evolving. Tools and platforms need to accommodate a future that is partially unknown, making achieving a solid developer experience a challenge.

Some aspects that contribute to a good developer experience include:

  • Ability to get up and running quickly as a beginner
  • Clear, thorough, and detailed documentation that’s easy to explore and facilitates learning
  • Accessible developer community as a support resource
  • Freedom and flexibility to take the preferred path towards a solution without rigid obstacles
  • Ability to easily gather relevant technical information related to code failure
  • Clear and explicit error messages that explain issues and suggest potential solutions
  • Automatic resolution of tedious automatable tasks
  • Reusable infrastructure to easily build ad-hoc solutions
  • Availability of specialized tools for domain-specific problems (local environments, programming editors, debuggers, etc)
  • Fast performance

Developers are empowered to meet their objectives with a high degree of comfort and efficiency when there are high-quality resources available, well-designed architectures with APIs that get out of the way, and insightful tooling functionalities to address domain-specific problems.

When the basic tenets of developer experience aren’t met, developers feel frustrated and suffer significantly lower productivity.

Ethereum developer experience

When it comes to Ethereum, which is primarily a software development platform to build decentralized systems, developer experience is a key strategic aspect for success. Ecosystem growth requires more developers to build more software on top of Ethereum. Developer adoption and learning speed, core contributors to this growth, are critically affected by developer experience.

The rate at which the ecosystem innovates, coming up with new creations and solving difficult problems, both at the dapp layer and EVM/Solidity/Vyper layer, is also directly affected by developer productivity.

Software development platforms aren’t new, and playbooks established by the great developer experience success stories (Rust, .Net, TypeScript, etc) prove that achieving a quality developer experience requires a specialized approach paired with a long-term, big-picture strategy. The potential impact in executing a dedicated effort for Ethereum would increase the ecosystem’s pace of innovation and growth, building a powerful compounding effect over the long term for the entire industry.

The inspiration for our vision came from our experience building Hardhat, which allowed us to see how deeply challenging it is to build sophisticated Ethereum tooling. These challenges must be alleviated to bring about organic ecosystem-led improvement of developer experience that achieves world-class quality.

Nomic Foundation

Nomic Labs has been fully dedicated to Ethereum developer experience since 2019, and we’re now pivoting to a non-profit foundation formally dedicated to Ethereum. We’re aiming to build a long-lasting organization that makes Ethereum’s public goods support structures stronger by contributing to the Ethereum Foundation’s existing efforts, and reducing the ecosystem’s reliance on any one organization for development platform components.


Given the size and innovation pace of the ecosystem, there’s no way to foresee exactly what needs developers are going to have as things scale. However, we do know what engineering foundations the ecosystem will need in order to build its own solutions.

Our overarching engineering strategy is to empower the ecosystem to build its own specialized tools. This plan is based on four strategic pillars of the stack, each of which offers an opportunity to leverage a platform to empower the ecosystem to keep building open-source infrastructure.

For each of these pillars, we will build a platform. The four ecosystem pillars and platform opportunities we’ve identified are:

  1. Solidity
  2. EVM tooling
  3. Local development environment
  4. Ethereum connector library

The projects

Slang & Rethnet

Over the long term, these are our most important projects. Targeting the Solidity and EVM tooling pillars, Slang and Rethnet will serve as core infrastructure for the ecosystem to build new tools faster, cheaper, and better. We’re essentially building the tools that would have let us build Hardhat a lot faster. We previously published a Medium post with high-level descriptions of how both projects will complement each other.


A Solidity compiler designed as a platform for tooling development, an approach also known as compiler as a service. Its top priority will be servicing tools through domain-specific APIs. Much like .Net’s Roslyn, it will feature a compilation pipeline made of distinct reusable components with standalone APIs. A completely modular design guarantees that others can build on top of it by replacing the part of functionality they need to, and reusing everything else:

  1. Parser that is only concerned with producing trees from code. Usable on its own, for example, to create third-party formatters like Prettier plugins.
  2. Semantic analysis (binding) is concerned only with building a type system and validating the produced trees. Usable on its own, to implement third-party type checking, security/threat models, and more advanced third-party linting.
  3. Code generation. By replacing just this isolated part, the compiler can compile for different targets (e.g. non-EVM L2s).
  4. Language services. These will receive an immutable representation of the above (syntax trees, bound trees, codegen settings), and will only be tasked with answering questions. Usable on its own to expose in different IDEs (same service for VSCode, IntelliJ, Vim, etc). Reusable to extend the functionality of other editor features (task runners, testing, deployment, CI, debugging).
  5. Runtime observation APIs to support Rethnet.

All of this will be reusable to create entirely new EVM programming languages, since by replacing the parser and type system, one can get an entire high-quality toolchain working from the get-go.


To provide a simulated environment where developers can build and test their Ethereum software, tools need to replicate many of the components that make up a full Ethereum node implementation. This is a significant engineering effort, which given the complexity of Ethereum, represents a barrier to entry to tooling development given the depth of knowledge that is required.

Rethnet aims to make this easier by offering a native, flexible, extensible, fast, and language-agnostic EVM local development network, distributed as a Rust library, that is designed to be the underlying core in tools that provide debugging information to developers (like Hardhat, Foundry, Remix, Truffle, DappTools, etc). It will be a Rust library made to be consumed from other languages like TypeScript, Go, Python, etc as a native dependency. It will implement the baseline of essential functionality every tool should have like Solidity console.log, stack traces, and descriptive error messages, as well as implement code coverage, gas profiling, and a step debugger. At its core, it’s an implementation of an Ethereum node with a layer of EVM runtime observation to provide development features.

Building a new Hardhat, Truffle, Remix, or DappTools using Rethnet will be a much more manageable project, and Rethnet will be completely reusable for any EVM language through adapters.


Our flagship project targets the local development environment pillar, and it’s currently at an advanced level of progress and adoption. While Slang and Rethnet mature and catalyze organic growth in the tooling space, developers still have needs to be met, positioning Hardhat as our immediate-term solution to empower developers to keep decentralizing the world.

Hardhat is an Ethereum development environment that developers use to compile, deploy, test, and debug Ethereum software. Most importantly, it’s highly flexible, extensible, and designed to empower the community to build their own solutions. This strategy has been successful, and there’s already a valuable ecosystem of reusable plugins.

Hardhat’s roadmap is focused on becoming an extensible development environment with deep integrations across components in key areas of the tooling stack:

This roadmap leads to developers being well equipped to build powerful extensions to their workflow that increase their productivity according to their exact needs, and to then share them with the ecosystem in the form of plugins.

Hardhat will also eventually migrate to using Rethnet and Slang, increasing its feature richness, speed, and stability while enabling dogfooding at scale for our brand new building blocks.

Web3.js as a frontend platform

The OG Ethereum connector library, Web3.js, is being revitalized into a high-value project. By focusing on community and ecosystem growth, supported by an extensible architecture, it can become a great source of value, much like React represents in the front-end world, but for dapps. A website hub connecting community spaces, support spaces, educational resources, extensions, and related projects, combined with an active ecodev effort (workshops, talks, contests, and incentives), will create a source of leverage for the ecosystem. This will provide better troubleshooting, faster developer training, more reusable code, and, most importantly, the possibility of extending the library. This effort is currently spearheaded by the ChainSafe team.


The Nomic Foundation aims to benefit the entire Ethereum ecosystem, which is why we’re fundraising across multiple organizations and individuals within it.

The Ethereum Foundation is leading this round of contributions with $8M, alongside contributions from Vitalik Buterin, Coinbase, Consensys, The Graph, Polygon, Chainlink, Gnosis, a16z, a_capital, and Kaszek Ventures. These donors make up $15M, and we’re aiming to raise $15M more.

Why ENS?

Generally, we think that allocating capital to the Nomic Foundation makes strategic sense for any protocol treasury that is aligned long term with the growth of Ethereum, and we’ve approached and will continue approaching several protocols.

Currently, ENS is built using Hardhat. While this is a signal of Hardhat’s value, the projects that the Nomic Foundation will deliver will create more value not just for ENS, but for the entire ecosystem. We’ll provide services to the Ethereum community that will:

  1. Continue the maintenance of critical infrastructure used to build most protocols (Hardhat).
  2. Increase developer productivity for every team in the ecosystem.
  3. Accelerate developer onboarding to Ethereum, increasing the size of the experienced engineering hiring pool and making time-to-productivity shorter for new hires.
  4. Accelerate the pace of innovation and the number of products being built.
  5. Increase market volume driven by new users and new products.

We believe this grows the market for everyone, including ENS, and we’d love to have the ENS DAO contribute between $1m and $4m in funding to this community effort.

An ecosystem-wide effort

We’re currently seeking funding from multiple DAOs. We’ll update with the corresponding links below as we create each forum thread.


Nomic Foundation Announcement


Firstly, thanks for making Hardhat a reality @zfran and friends.

I can not really comment about the amount requested in this fundraising round, but I do appreciate the text you posted here and that this is an ecosystem wide push by Hardhat.

The only thought I wish to share is that ENS should consider supporting the whole stack for web3. Hardhat is a clear component of that (albeit there are competing frameworks), but I would like to see that the DAO also contributes to all parts of the stack.

Referencing recent ‘drama’ in the JavaScript communities with the faker.js and colors.js libraries. Let us support all projects that are needed to support web3.

One more time, thanks for Hardhat :pray:

I’m strongly in favour of funding Nomic’s new nonprofit; this is exactly the sort of project I think the ENS DAO should be funding with registration proceeds, and I think this is a good time to set a norm that credible, high impact projects with concrete roadmaps get sizeable grants (in proportion to the project and the available treasury of the ENS DAO). I’d be disappointed if we didn’t agree on a grant of some kind for Nomic - it would leave me wondering what we would fund if not this.


I would love for ENS to support better user experience for devs. The easier it is to build the more will be built.

Adding my voice in support for Nomic Labs.

Thank you for your post.


Really cool initiative, and thanks for sharing! As a solidity developer myself, I definitely understand the pain points around gas profiling, debugging, and dev tooling, so look forward to seeing these new tools in action.

While I agree that ENS DAO should at some point make large grants to promising projects, I think it’s still too early to be considering grants over, say, $100k. I think “temp checks” like this should ultimately come from the Public Goods WG, who ensure it aligns with some well-defined grant-giving strategy. I also think the DAO should come to some rough consensus on a yearly budget, to balance Public Goods funding against the wants/needs of the other WGs.

Hi, @zfran

Thank you for posting this and also turning up to the Public goods WG meeting a few weeks ago and answering our questions.

Our Public Good (PG) stewards @AvsA @ricmoo @sumdesh @ceresstation discussed your proposal and here is our joint response (others can make comments if more needs to be added).

Even though we acknowledge the importance of the hardhat project and many stewards are supportive of providing some degree of financial support, we do not feel that our DAO is ready to make such a large grant in a lump sum at this time.

Our recommendation as PG stewards is to encourage the Nomic Foundation team to share more information on the questions raised and re-apply in 6 months possibly in a smaller amount.

Why the 6 months wait?

Unlike other DAOs you requested funding from, the ENS DAO is less than six months old and we are right in the middle of passing the first DAO working group budget proposals. One of the objectives of PG for the next term is to define the grants process including answering questions like what public goods we should prioritize funding. We are not at the stage to assess whether granting such a lump sum to projects outside of the ENS ecosystem should be the highest priority over other ENS ecosystem projects.

Given that you have already secured 15 million USD from other projects, we appreciate it if you can accommodate the request to fit in our timeline rather than meeting your immediate funding goal.

Why a smaller amount?

Even though we have over 1 billion USD worth of ENS treasury, we have the smallest market cap among other orgs you requested funding.

[The data is based on https://coinmarketcap.com/ as of Mar 4th 10:36 GMT]

This is because we have the smallest circulating supply (20%) and selling off a significant chunk of ENS tokens from the treasury in a lump sum will likely cause a more serious market impact than other projects. We definitely need planning from the Meta governance working group on token supply management before making any decisions on lump sum releases especially when there are other projects that resulted in issues where grantee swapped large project tokens caused controversy.

This means any immediate DAO spending has to come from our current non-ENS token DAO treasury
which we have about 10 M USD worth of ETH/USDC but is going to be less due to $2M proposal to pay tax and a yet to be decided amount to cover the operation and development of TNL as well as various DAO work group initiatives.

For this reason, our current treasury spending is still modest compared to other organisations.
Our entire ENS DAO budget for the first six months is less than USD 500k (Public good = 100k, Community = 155k, ecosystem = $164, meta = $44) and your requested amount of 1-4 million is out of proportion compared to other budgeting proposals. We fear that giving such a large amount to a single project may mean fewer opportunities for other projects and initiatives.

What questions would we like to be shared?

We are still in the process of establishing a funding process including the list of questions but we would like to see the following questions answered specific to your proposal.

  • What are the mechanisms for accountability of the team to funders and the community? What are the metrics for “success”?
  • How did you decide the funding amount for each DAO (Yarn 500k, Compound & Uniswap 5M, Sushi 500k-1m)?
  • Do you consider any locking/streaming mechanism if we decide to grant in ENS token rather than ETH (to prevent downward pressure of selling off project tokens at lump sum)?

Thank you for bringing this proposal to our community. Your proposal definitely gives us lots of data points to help shape how ENS public goods should be formed. Requesting to re-submit may look like a rejection but it’s quite an opposite. We would love to work with you to define what’s the best way to help public goods funding like your project.


Thanks for the detailed response @matoken.eth

  1. I’d like to highlight that this isn’t a grant for Hardhat, but a grant to bootstrap an Ethereum-dedicated engineering organization. We’ll build infrastructure with more potential for impact than what Hardhat has achieved, on top of also expanding Hardhat.

  2. Timeline. We’ve been working on the transition to a non-profit foundation for close to a year. Due to this being a nonstandard path, there’s been a lot of legal work that included entity governance, IP matters, DAO funding viability, closing funding deals with companies, etc. It’s been a lot of work that’s taken a lot of time and most importantly, has been a huge distraction from building. We have a big need to wrap up the process and get back to what we do best, which is servicing the Ethereum community, rather than continue with an eternal fundraising process. While I understand your concern, I’d love to find a way to simplify the process and avoid a 6-month delay.

  3. Size relative to ENS mkt cap. We think ENS having a significant revenue stream that is independent of the token treasury and token price puts it in a strong position to make a grant like this, and the criteria should be different than for a DAO that’s entirely contributing out of token emission.

  4. Price impact. If we get ENS tokens, we’d be very careful about selling. I’ll replicate here what I said on the Uniswap forum:

    We’ll engage an OTC desk specializing in lower liquidity pairs to execute the sale, which will distribute the impact across many liquidity pools, over time, rather than a one-off market sell order in a single liquidity pool. The length of the period for the execution will depend on the OTC desk’s assessment of liquidity at the time of the sale, but I assume it’d be many relatively small chunks over the course of a few weeks.

    We think this is something that can be managed, and we’d never execute a lump sum sale like in the cases you’ve referenced. It’s against our future interests to behave in such way that would lead to community stress, discomfort, and published articles about the sale. From our conversations with the ENS community, the intention was for the grant to come from the ETH and USDC holdings to avoid price impact entirely.

  5. Metrics and accountability. The ecosystem will be the judge of our success, and it’ll likely be very visible. If our new and existing products show significant usage, like it’s the case right now, then most people will know and it’ll be a clear signal of success. In the case of the infrastructure building blocks, the number of tools with wide adoption relying on our infrastructure will be the main metric to watch. It’s our intention to facilitate the tracking of these things for the community to have even easier visibility.

  6. Locking/streaming. Holding a large amount of any token is too much of a risk since it’s operational capital that will be used “soon”, and a significant drawdown could mean whole years being cut from our operating runway. A streaming grant would be equivalent to holding the tokens, in terms of financial risk. Like I said before in item 4, we don’t intend to execute a large lump sum sale, and selling over time would minimize and likely make the price impact insignificant. If there’s a way to make it work, using the USDC/ETH treasury instead would be ideal.

  7. Amounts across DAOs. The main driving force behind deciding the amounts for the different DAOs has been the community themselves. Each figure was suggested by community members when we shared how much we wanted to raise in total and how much others were contributing.

1 Like

We are aware of the importance of your organisation beyond a single project (hardhat). Our response is mentioned against spending a significant part of the funding to one single external organisation before ENS DAO establish public goods funding criteria.

During the meeting, you have compared the raise similar to investment raise. For the venture round, it is important to finish all the rounds at the same time as it will impact your company valuation and close the cap table, etc. However, this is a grant request and I don’t think it causes any delay in your legal work.

I think it will take less of your overall time engaging with us if you just wait for another 6 months. If you try to rush it now, it will probably require more back and forth due to the lack of process and structure on our side. You can totally ignore our feedback and go straight to snapshot voting (and you may win which is probably the simplest) but that would certainly hurt the relationship between the Nomic foundation and the ENS PG working group.

As I mentioned, we have the smallest market cap (20 times smaller than that of Uniswap) so you may have either taken the snapshot when ENS token price was 5x more than the current price or used a diluted market cap instead.

It is correct that our revenue stream is independent of our ENS token treasury. However, I already stated that our current 10M ETH/USDC treasury is even less than your secured 15M grants.

If we agree on not selling ENS tokens, then it doubly justifies our feedback that giving 10%-40% of our entire ETH/USDC treasury as a grant to a single external project outside of ENS ecosystem is not rational. This is against our constitution III where it states that ENS treasury is to be used first of all to ensure the long-term viability of ENS and to fund continuing development and improvement of the ENS system and use of public funding for non-ENS related projects are secondary in terms of priority.

Even though the proven track record is a key factor to predict the future success, I think it is reasonable for any grant program to request progress reports and unlock the grant over a set period of time rather than giving out at the lump sum.

Again we haven’t established such matrics or the process yet and that’s another reason we ask you to wait for another six months.

I think we can ignore this now that we agree on not counting on ENS token treasury.

We are happy to arrange another meeting to discuss what’s the best way for both the Nomic foundation and the PG working group if you wish.

Lastly, I would like to stress that your grant proposal is more likely to be used as a standard for other grant proposals. If we allow your proposal as currently proposed (out of proportion amount in the lump sum with no feedback loop), it will set a precedent for all other projects to follow the same path and that would hurt the effort our PG stewards are working on right now.


I want to push back on this; our liquid treasury is about $20MM ($10MM USDC + $10MM ETH); 5% to one project would definitely not imperil our ability to support ENS’s viability; it’s about equivalent to our income for the month of February.

1 Like

It is debatable whether we should include unearned income as liquid treasury considering your dashboard itself subtracted the amount from the entire balance.

All of my point still stands even if we have double the treasury. Giving five percent of our entire treasury to non ENS purpose before we even decide the overall annual budget seems wrong order to me.

1 Like

Did ENS DAO fund any project so far? If not, 5% of the treasury as the DAO as a first investment seems like a big jump.

I see how dxDAO, a DAO that funds decentralized projects, does that. Since (legal) contracts are not part of the DAO world, due diligence is difficult, and if you give someone 5 million you probably don’t do it all at once - they developed a set of tools and methodologies to handle that.

There are plenty of questions in giving out grants. Legal, procedural or technical questions. I would rather take the “small steps” approach so that the DAO could develop its way to do such things without getting burned.


I apologize for not being clear enough. I was providing context for why this has taken a while to put together, which is the reason for our desire to avoid adding an additional 6 months to the timeline, as it has been a huge distraction from building. No implication of additional legal work.

Again, I apologize for not being clear enough. “Size relative to ENS mkt cap” was me describing the topic that you raised in your initial post, as a title to the paragraph that followed as my actual answer to your points. We didn’t size the ask based on mkt cap, but you framed the size of the ask in the context of every project’s mkt cap, so that’s how I described it. We sized based on discussions with community members. In this case it was @nick.eth who suggested a $1m-$4m figure.

I mentioned the significant revenue stream to point out that part of the capital we assumed ENS was going to be able to contribute would come from this source. I believe, however, that it’s not fair to compare a stable treasury with substantial revenue coming into it (Nick mentioned 5% MoM growth) that exists next to the additional support of a large token treasury, against our fixed treasury meant for 4yrs of operations of a non-profit without revenue, and no tokens. While I understand how these specific figures being similar could initially seem like something is off here, I think there are additional inputs worth considering to put these numbers in context. We were asking for 1 month of ENS revenue to help fund 4 years of Nomic operations.

I understand this grant is not intended to benefit only ENS, but at the same time I don’t think it’s fair to say it’s an irrational request. I think ENS’ long-term viability is directly linked to Ethereum’s long-term viability, and we’re making substantial contributions to Ethereum’s long-term viability. When it comes to the constitution, that section you quoted also includes: Funds that are not reasonably required to achieve this goal may be used to fund other public goods within web3 as ENS governance sees fit.

As @nick.eth pointed out, $1m equals to the February income into the USDC&ETH treasury, and the total liquid treasury is currently around $100m in size. Based on this I thought that considering a $1m grant was reasonable.

It’d be 5% of the stable treasury that is denominated in ETH and USDC, but if we look at the whole liquid treasury (ENS+ETH+USDC) then it’s only %1, and corresponds to just the February income, meaning that the DAO would recover fairly quickly. It doesn’t look like a grant of this size would prevent the DAO from funding anything it needs to for the foreseeable future.

Just to reiterate, I don’t think Nomic’s ask is unreasonable, and when they first reached out to me I encouraged them to make the request. I would very much like to see ENS giving big grants to worthwhile projects, and Nomic is pretty much the definition of such a case.

I understand the PG WG feels it’s too early to start on grants like this, and respect that; I understand the desire to have a framework in place, and the concern about setting a precedent with a large first grant.

At the same time, “no” is also a precedent, and I’m much more concerned about a situation where the bar for a public good to get a large ENS grant is impossibly high than I am that we give grants that are a little too large or mistargeted as we get started; we can learn from our experiences either way, but I think it will be much harder to be effective if we set a norm of being very restrictive initially.

I’d strongly encourage the PG WG to commit to a date for having a grants process and guidelines in place, and for it to explicitly consider cases like Nomic’s in the process. And I’d strongly encourage Nomic to come back when that framework is in place and repeat their ask. I am, and still will be, strongly in support of a grant for this important piece of Ethereum infrastructure.

A range between $1m - $4m is a pretty significant range in terms of whether everything in that range is reasonable.

Maybe @zfran can confirm a specific number for a grant, if it was to be requested in a proposal today.


If it is indeed the February income of the DAO, then it’s more than 8% of the annual income of the DAO (one month out of 12). This is for a grant of 1M, but since you also mentioned the number 4M in your request, it would make it almost a third (4 months out of 12) of the annual income of the DAO.

How is any of those figures not much?

This DAO is in its first baby steps of giving any grants. In my opinion, there should be a road beginning with smaller grants to various projects, so that the contributors and the community will have the time to develop the tools and the philosophy a DAO needs to assess bigger grants later on.

1 Like

Do we have other competing demands on that money? If we consistently spend significantly less than our income, the DAO treasury will continue to grow. While a reserve is good, continued growth would, in my mind, demonstrate that we’re not putting the income to good use for the ecosystem.

1 Like

We aren’t even an year old; just making it to six months.


We don’t have competing demands on that money because no one is brave enough to make them at this stage.

But if we do approve it you’ll have plenty of competing demands soon enough. I’m not a fortune teller, but I do know human nature :smiley:

You’re right. What I’m saying is that we have many pieces missing at this point to give grants of this amount.

We need experience. Why not begin with a few smaller grants first? Get burned (and we will) on small amounts. Develop the mechanisms needed to assess grants (like EF or dxDAO got) before jumping into the deep water.

I agree with that, but as I said, I’d personally start by focusing on smaller grants.

1 Like

We meant for the thread to serve as the discussion place for the amount, and I think the lower end at $1m is what we’d request today.

It will be highly unusual to say the least to grant a sizeable chunk to a proposal with no competitors while proposals that require 5% of the amount requested here are facing quite a bit of competition in their brackets. Logic dictates that competitive arenas be served first. It is also not particularly savoury that this proposal feels like it came at the back of strong lobbying. There is almost unilateral opposition to it so far. I’ll be surprised to see this go to vote. It feels like an all-in trade