# Keynote: Nomic Foundation’s vision for Ethereum’s tooling ecosystem

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 17:39
- Watch: https://streameth.org/watch/yt-1YyDB4bwJ2k
- YouTube: https://www.youtube.com/watch?v=1YyDB4bwJ2k

## Description

Nomic Foundation is the nonprofit behind Hardhat. Nomic’s co-founder and CTO will walk you through Nomic’s long-term vision for a community-driven developer tooling ecosystem for Ethereum.

## Transcript

So, hi everyone. Thanks for being here. I'm Patricio Palladino. I'm one of the co-founders and the CTO of Nomic Foundation. Nomic is a non-profit dedicated to improve the Ethereum development platforms for builders like you. At Nomic, what we do is creating open-source infrastructure and tooling for Ethereum. And our most well-known tool is Hardhat. And we've been building Hardhat for quite some time. We started it in 2018, so almost 7 years ago. And it grew from being a side project to being a collection of different tools that includes not just Hardhat, the task runner and the framework, also a network simulator. It includes things like a a deployment solution and better support for Solidity in VS Code and different editors. Creating these things exposed us to almost the entirety of the infrastructure landscape of Ethereum, and we got to learn about its limitations. And I want to share a few learnings that we got so far. The first learning is that building tooling for Ethereum is challenging. It's actually pretty challenging. And this is not something exclusive to Hardhat. If you were to to build any kind of tool or infrastructure in Ethereum, most probably you'll find yourself with unmet needs, and you'll you will have to either create your own solutions or or your own workarounds or hacks. To see some examples, if we were to create a Solidity formatter, which is just a tool that takes your Solidity source code and reprints it reprints it in a nice format, the first thing that you would need is a parser, a library or a tool that takes that text, process it in a in a way that it will allow you to then pretty print it easily. And yeah, you will find some parsers for Solidity out there, but all of them will have their set of limitations. They may either parse and somewhat approximation of Solidity, that it's not clear which which particular version they are parsing, or they may be parsing a single version while your tool wants to process every version of Solidity, or they may be tied to a single programming language like I want my tool to be built in Rust, but the parser that I want to use is built in JavaScript and I can do it and I I I don't know, find a workaround or hack it together. And this leads to clearly less than ideal solutions. To see some more examples, if we were to build a linter, a Solidity linter, we would have all those same problems and more. What if we wanted a type aware rule that I don't know, forbids that you use a certain type as storage of your context. Well, you'll definitely definitely not find a a library that exposes a Solidity type system for you to build this rule simply. So, what would you do? Well, you either build a part of that, probably in a quick and dirty fashion, or maybe come up with a half-baked solution that is just a bunch of heuristics, maybe a regular expression or something like that. If you were to build a Solidity editor, things would be way, way worse. And trust me, we've been there. We built one. And you pretty much have to re-implement a good chunk of Solidity's code analysis. But those examples that I named are just three out of a ton of different tools and infra infra pieces that any any realistic or mature development platform has. There are more examples that I listed here, but to be honest, these are just some examples that came to my mind and that would fit in a single slide. In a In a mature platform, in a real world, well, it's not that Ethereum is not real world. It's just less mature. In a mature platform, there are tons and tons of tools and there are constantly new tools being created. But in Ethereum, if you were to create any one of these tools, I assure you that your experience won't be smooth. It will be simple It will be similar to the things that I mentioned. You will find yourself unmet limitations and you would have to come up with your own solutions. And to make things a bit worse, some of these tools you would want them to exist in different languages. Maybe you want a connector language in JavaScript, in TypeScript, in Python, in Java. And that just adds some kind of multiplication to the problem making it larger. Then another learning that we have is that Ethereum is a moving platform. And what do I mean by this? Well, for once, Ethereum is constantly evolving. It evolves through hard forks, but also through layer twos. And there's tons and tons of changes coming coming up now that are due to new layer twos popping up every day. Also, the tooling and libraries change. We went from using web3.js at one point, then to a new version of web 3.js that was completely different, then ethers, then BM, and I'm sure that things will still change. Finally, another thing that also changed is the developer needs themselves. They build different kinds of applications. At one point, we were all building stable coins, then NFTs, then DAOs, then different things, and those different things have different needs and different levels of complexity and size. Not to say that anything about multi-chain, that is now completely changing the needs of developers. Just a few years ago, things were way simpler for an Ethereum developer. Now they have to deal with multiple chains at the same time. And things just get harder. Now, to be honest, this is not something unique to Ethereum. It happens everywhere. Every every software development platform that is alive and continues to evolve goes through constant change and renewal. It happens to know, this happens to every every single language. What is unique to Ethereum is the speed of change and the fact that every tool is built based on hacks and workarounds as I described. And when you combine those two things, things changing quickly and things being unreliable, you get a ton of fragility in the platform itself. And finally, the other thing that I or learning that I want to to mention is that, as I mentioned before, at Nomic, we don't work just for Hard Hat. We work for the entirety of the Ethereum development platform. We want to improve it all. And if and at one point we realized that we can't just do it through Hard Hat and we can't just do it by being direct providers of final solutions or develop our solutions. Why? Because we have limit limited bandwidth. We can only focus on so many things. Our team is has a limited set of people. Hopefully, it will increase, but it will still be limited. And we just can't fix everything. Also, if we were to be direct providers of every single solution, we could become a an ecosystem dependency, a core ecosystem dependency. And that's not something that we want to be. Um at the same time, doing that would or could potentially make us gain a a ton of influence on the platform. And that's not not aligned with the values of Nomik. Finally, if we were to build every solution ourselves, we would be making a ton of decisions cuz we won't build any any any of the many technical approaches for every single tool, but we would have to pick one or at most two. And that would lead to less technical exploration, less approaches to every single problem. And that could inhibit part of the potential of the platform. It's better to have diversity of ideas, a diversity of technical solutions. And that then every every every developer, every project will pick whatever fits best for them. So, instead, at Nomik, our long-term vision is to build the core pieces of infrastructure that would enable the ecosystem itself to build its own tooling and do it efficiently. And at the same time, doing it from a nonprofit and independent nonprofit that it has clear Ethereum aligned incentives. Which are these pieces of infrastructure? They are two. One is called Slang and the other one EDR for Ethereum development runtime. Slang It's a Solidity compiler as a set of APIs focused on tooling. What does it mean? Well, if we go back to the examples that I mentioned and we wanted to create a formatter and this is actually doable now, you could use Slang's formatter. Sorry, not formatter, Slang's parser. That that parser will be ready to be consumed from many languages, is ready to be consumed from many languages, and it's easy to use, supports many languages of Solidity, and it's actually being used by a beta version of of Prettier Solidity right now, and it improved how a Prettier Solidity can format format different versions of Solidity. For a linter, similar thing, you get Slang, it's a library, you get to use this a different set of APIs that Slang proposes exposes, but same thing, you just have the the building blocks available for you. By design, Slang is focused on tools because tools tend to have a different set of constraints that than just a traditional compiler. For example, they may need to deal with different versions of the language uh while a traditional compiler just deals with one. In a tool, you want a single tool to be able to handle then almost or all the entire history of the language, while a compiler can just focus on its a normal compiler can just focus on a single one. Same with things like error recovery, you may want your formatter to to be more permissive in the presence of or forgiving in the presence of errors, and similar constraints like that that make having a tooling-oriented compiler a great piece of infrastructure for tool developers. And it's published as a library, so you can use it either from Rust or TypeScript. And it's also targeting WASM, so you can even import it from other other places. Now, EDR, it's a portable library, also written in Rust. It it implements an Ethereum simulator, including some layer twos. That means that it simulates the network. It it's already in production. It powers Hardhat, too, the current version of Hardhat. And when we released it, we saw performance improvements in massive performance improvements, actually, in some Hardhat projects. Some of them just without changing any single line of code, just by updating their dependencies, starting running 10 times faster. And at the same time, EDR will simulate that will simulate optimism or off-stack chain soon, and it will include a Solidity test runner. It's Again, this is a library. This is not just built for Hardhat. Anyone can install it, and it can be used for any kind of tool that needs to run simulator simulations or do any kind of runtime analysis. Finally, Slang and EDR are sister projects. What does that mean? That they are designed to work together. And by that And that's because the combination of both will allow us to do way more advanced things than what we can do with each of them in isolation. Right now, we have a a compiler Solidity built by one team. We have our own runtimes. It's hard to collaborate deeply enough to build things like, I don't know, picture Chrome Chrome development tools. They are the bugger, you can change variables in real time, you can rewrite parts of the code, keep running. Those kind of things are possible. We can build them in Ethereum, but they do require a ton of deep collaboration and integration between the compiler and the runtime. And that's the the kind of thing that we are going after at Nomik. We want EDR and Slang to mature to be libraries that everyone can use. They will provide the basis for anyone to grab those tools, grab those libraries, and build the next generation of Ethereum tooling with them. And that's it. If you want to learn more about Nomik, uh you can scan the QR code. I guess it's on your left. Um that one has information about the different presentations that we are giving at Nomik that we are giving at Devcon. One of them, yesterday I already gave it. It's about Hard Hat 3, the upcoming version of Hard Hat. It's not ready for production yet, but there is an internal alpha and lots of information in that presentation. It's recorded, so you can watch it. Today, I think at 5:00 or 6:00 p.m., there's a presentation by one of our team members that's going to explain how EDR can simulate different tail choose different networks. And tomorrow at 12:00 or 12:30, there is a presentation about Slang and how you can use it to analyze your Solidity code with some pretty cool APIs. Finally, if you want to work with us, you enjoy the the kind of thing that we do, you can scan the other QR code and learn more about show show offerings for positions at Nomik. And that's it. Thank you. Patricio, thank you so much. And for everyone, it's still open for giveaways, so just QR this code. We do have one question here for you. So, can EDR be used for things like simulation with altered storage state, storage of rights in tenderly terms? Yes. Sorry about that. That's the whole answer. Yes. It can. We have another question here. Will we advance testing features like symbolic debugging be integrated or will it be possible to connect in advance nodes like build better sandbox inside of hardhat nodes? Uh well, I don't have I don't think I have an answer for the first uh part of the question. Uh we'll have to analyze it. I can't promise on any timeline right now. Uh the second one I think should be possible. Yes. Uh if not, just reach out through GitHub and we we can analyze it. We do have another question here. Automatic test generation, is that something that the Nomik Foundation is interested in adding? Uh wait. I can't read it. Is it So, then we do can EDR use be used for Oh, okay. Cool. Thank you. Uh do I say something like Uh it's not our I'll reread it just in case. Automatic test generation, is that something that the foundation is interested in adding? It's not our current focus. I think there's a ton of development going on, super interesting on AI, but that's not the focus of our organization. If there is a way to integrate those things cheaply, we will, but Hardhat itself it's a super flexible platform. You can build your own plugins. So, if you want to experiment with this and create your own automatic generation plugin, automatic text generation plugin. Should be super straightforward. Go try it out and tell us how it went. Yeah. Perfect. Patrice, you thank you so much for your presentation. Thanks everyone for your questions. We'll be back in 15 minutes.