What's next for Solidity & Argot | Jacob Czepluch (Berlin Ethereum Day, June 2026)

Hello everyone. I'm Jacob. Today I'm going to talk a little bit about um what's next for Solidity and a little bit about AGO, which is the collective building Solidity and a bunch of other tools. Perfect. Okay.

So, I wrote my first smart contract in 2015, which has been a while. And back then there was absolutely no tooling or anything to uh to help you out. So it was uh pretty raw. This is a the snippet from my bachelor thesis about Ethereum. Um and yeah, some of it looks pretty similar, but also a lot has changed.

Um and yeah, after that I did a bunch of uh stuff. Uh and I'm now doing defil for the solidity language. Okay. So, where are we currently with the language in uh 2026 and a little bit about the pain points that uh people are still facing with Solidity. So, Solidity has been in production for 11 years.

Um and the latest release we have is 0835 from April. um which introduced um a couple of interesting things. One of them being an experimental flag that now has an SSA CFG pipeline which uh my colleague Moritz will speak much more about right after my talk. Um it's maintained by the AGO Collective which is a spinout of the Ethereum Foundation. Um we've been um independent since uh 200 yeah 25 so about a year.

Um and yeah I'm also going to talk a little bit about what that means and what Argo is. But first off, uh we also fairly recently had our developer survey and the biggest pain point people uh keep on facing is the stack too deep error. Um I'm not going to go too much into what it is. I'm sure uh Morids will explain that further. Uh but basically people have been running into this for years and years and um the more experience the developers have it seems they run into it more and more frequently which makes sense.

Um but we are fixing this um and yeah as I said we will talk in depth in the talk after this one about how we are doing that and what else we are improving with the SSA cfg. So yeah, don't uh don't uh run away after my talk. Um please stick around. Um and yeah, the the other thing is that I said we've been building Solidity for 11 years, which um has its uh pros and cons. Um but there's been a lot of patching in the in the in the code base.

um started out as a as as one thing and might not have been designed or uh no one really knew where smart contracts would be going and there's also been a bunch of research and improvements happening in the general programming landscape, programming language landscape. So we are also working on let's call it a reimplementation of solidity that kind of uh take some of the things we've learned over the years and try to make uh a language that is up to date with the current uh programming languages landscape. So we're doing core solidity which is um kind of a redesigned language um and type system but uses the same back end. So everything like the the the the pipeline kind of we will uh be able to to reuse. So all the work that we put into the K compiler the back end over the years will still be relevant and all the work we're putting into SSFG will be reused.

Um, and here, yeah. So, now I'll show a little bit about the what the language looks like. Um, or what you can do. I don't know if it's too small, uh, for the people in the back. I hope you can can read it.

Um, here's an example of kind of like a payment handler that um, on the left side you have the example in classic where you have a strct and basically this strct there's not really anything keeping you from creating invalid uh, payment types. Um and the only way you can kind of uh shield against it is by the like if statements or requires that we do on the left side. Whereas on the right side we have pattern matching and uh abstract data types which allow us to define exactly what a type uh of payment what a payment type looks like. And this way we can ensure that we only allow for the given payment types. And in the same way if we decide to include a new payment type like ESC 1155 um nothing would really help us on the left side in classic to ensure that we cover all cases whereas on the right side in core um we would uh the compiler would tell us whenever we are missing uh a case um or we don't handle it correctly which is a very nice um feature of a language and probably a lot of you are used to something like this for from from some of the languages you use nowadays.

Um, so one thing that I think is like quite interesting that I read about recently is that in aviation, uh, you go to great length to make it as difficult for pilots to make mistakes because pilots and humans will always make mistakes. But it's kind of our job to make it as difficult as possible to to make these mistakes. So I think designing a programming language with uh this in mind makes a lot of sense especially when it's a programming language that holds uh billions of dollars um hopefully trillions at some point in the future. But yeah, you definitely want to make it as difficult for the people writing smart contracts to to make mistakes. Um, and here, yeah, there's a a nice error message example from what it probably will look like.

Um, and this basically also like if you have this pattern match I showed before, you'll have something that it like basically compiles to what a careful developer could also write in a U switch statement. Uh, and it comes at no extra runtime cost. So basically it compiles down to this U switch. Um, which is just uh, yeah. So just because we have this pattern matching doesn't mean that we have any extra runtime cost.

The another thing that a lot of people have been um asking about for a very long time in uh solidity is a standard library. Currently uh stuff like ADI and code uh and a lot of other language features is uh built into the compiler which is written in C++. Um but now uh in core we are going to have a like very small core language and a standard library which means that we can implement all these things in the standard library and we can let's say move faster and we don't have to make a new version of the a new release of the compiler just to have new functionality in the language. So I think it's a very healthy split. Um and a cool example of this is um just last week uh we had someone implementing memory slices in around 50 lines of code in the standard library um in a couple of hours and he told me after that this took uh like a month to build into the compiler back in the days.

So I think this is a pretty powerful showcase of how having a standard library in a smart contract language can be very useful. Um and we also have um generics in the language um which again compared to how let's say forge uh as forge standard library they have 381 handwritten lock functions. Um whereas in coality you can just have one function perity which is more elegant smaller surface for mistakes. Um so I think these things add up to something that will actually be a very um comfortable language to use that also makes it um harder to include or introduce bugs in your code because a lot of the things will be caught at compile time. Um yeah, I will not go too much into to to to detail with like the the the inner workings.

I have a talk on Wednesday at DVCON you can check out if you want to know more. But since I promised to also talk a little bit about Argo, I'm cutting uh keeping it very high level here. Um but the core language uh sale is basically eight primitives and one type. And one of the things we wanted to do is make sure that the language is small enough that it can be formally verified. Um, and we plan to do that.

Uh, yeah. So, we do have a couple of uh external contributors already which have um contributed with some some really uh great things. We have uh Axik who some of you probably know. uh he's been helping out a little bit lately and he built the beacon chain deposit contract in core and he also built a multisyc and provided a lot of very good feedback um about the current state of the language and um just in general polished it up a bit. Then last week we had an external contributor also writing a unis swap v2 pool um and providing a bunch of feedback in the forum.

So, it's it's really nice to start to see that people are showing some interest and helping out with uh like whatever they find while they they try it out. So, I encourage anyone uh here who'd be interested to also give it a go and uh open a thread on our forum or or come and find me if you have any um any feedback. You can play around with the language, but please don't uh don't use it for production yet. that would be a little bit risky I think. Um we also have recently released a blog post um about pattern matching and pattern matching in core solidity which is uh quite interesting I would say and if you're not too familiar with pattern matching it's definitely worth uh a read especially if you're a solidity developer.

Um we also recently merged uh our first uh version of the module system in core solidity and as I mentioned earlier the 0835 version of solidity uh also has a comp time built in um and this experimental uh SSA CFG code gen. So it's all uh starting to to come together and we will have the the foundation to be able to really have a language for writing smart contracts that fits the let's say state of programming languages in 2026.

Sorry of classic or core. Sorry,

I I don't know if there will ever be a version one. I think um the team got got into some uh interesting versioning uh way back and now we have like 0835 which is should probably have called it uh gotten rid of this zero, right? Um but uh that's that's too late by now. Um yeah, and we also uh working on a playground that people can use to try out the the the core language. Um, and also like it doesn't mean that we we're not stopping work on classic, but I think it's just I'm I'm think it makes sense to talk about core as the the the the version or the language that we should focus on in the future, but we will be maintaining classic of course.

Um yeah, but u give it a go. Don't expect production readiness in 2026. Um do we have a time Martin? Time because I

how how much time?

Okay. Okay. Um yeah so a little bit about the the people and the collective building all these things. So we are Argo and we spun out of the Ethereum Foundation uh around a year ago. As I mentioned, we're around 25 uh people with uh slightly different backgrounds but all within the computer science field.

Uh for sure uh most of the people uh come from the Ethereum Foundation were there before we spun out. Uh but there's also been a couple of additional hires, myself included. I'm the the the latest uh person to join um and yeah as I said independent entity since 200 25 but for the last two years um Argo has kind of worked also within the year of the first year as an independent uh thing and one of our goals is to be a credible neutral home for Ethereum's uh core infrastructure um that is not like the the the clients the the consensus and the execution clients but like more the the core tooling for writing smart contracts. Uh a little bit about how we are set up. So we are not for profofit and we run flat.

Um there's no management layer. We're consent based um and voting on things that are like bigger decisions and it means decisions take longer but I've from my four months here it feels like we often land on actually the best decisions because we take the time to discuss it and listen to different points of view instead of just one person that feels strongly for something making a decision. Um and also there's a very high autonomy of the day-to-day work which I think empowers people to get stuff done and um yeah take initiative. Uh it's funded in the open. Uh we have 5 years uh initial runway from the Ethereum Foundation that we're topping up with public grants when we can get it.

And uh we release transparency reports twice per year that you can go and find um on our website if in case you're interested in knowing how uh we're running things. Um, another thing that I have dear to my heart and that I really like that we're doing is we run the whole organization on open source tools where possible. Um, and we self-host as much as possible and it's a little bit rough around the edges. Um, I'm sure some of you have tried using something like Crypad or whatever and it doesn't always go too well, but we still believe that it's important to do it so that we can u provide the feedback for these tools and so that they can uh become better over time. Um, and I often hear people say that, "Oh, we should all use open source."

And then when they pull up their slides or whatever, it's a Google uh Google Slides or they run a Discord server for their community or something like that. And I think that's we should not accept this. We should really try as a kind of a the whole ecosystem to do better and use more open source tools where possible. And we definitely also subscribe to a lot of the values that the EF recently coined props. We've been doing it like since we started out in in Argo and um yeah, if if if we're not the ones doing it, then then who are um and lastly we also do give some grants out ourselves to some of the the the tools and the the open source infra uh tools that we actually rely on.

So recently we gave a a grant to um a team that is uh helping build debug for example. Um lastly I'll just quickly go over the the projects that we're working on. Uh we had we have H EVM which is a symbolic execution engine for the EVM. Um for example the tool a cheetah uh or a cheetah is is uh is built on top of this. Um we have sourcifi which I hope most of you know what is it's an open- source decentralized source code verification tool.

Um and I really think this is actually a very cool tool that more people should be using and a lot of people are. They have uh 32 million uh verified contracts uh across uh 325 chains and they are also one of the projects spearheading the the open uh the clear signing initiative that I believe my colleague Khan will talk more about in about an an hour on this stage. So uh yeah also stick around and check that out. They're really doing uh cool work. We have Fay which is a a second uh programming language that we are also building um a statically typeyped smart contract language um and it has like similar syntax to to rust and immutable uh by uh default um give it a like yeah check it out.

They also recently had a a bigger release um than if debug I mentioned which is aiming at having a standardized uh debug format or debug information format for the EVM so that we can have proper debugging which also hasn't happened in 11 years. Um then ACT is a formal uh specification language uh for EVM smart contracts. Um, and yeah, as you all know, uh, everyone's talking about formal verification these days, and we've been working on this for quite a while as well. Um, and if you're interested in in learning more about this, we have a Anna from the team gave a very nice workshop on this from F Prague a month ago. So, you can find this online and get a good idea of what you can do with this tool.

Yeah. So, I think uh I'm I'm almost through. Yeah. Um anyway, give it a go. Uh try it out.

Um especially Corey and uh let us know what you think. Uh check out our website uh argo.org if you want to know more about our road maps and uh our our future plans and I think that is it for me. Um I think we'll skip the questions to see if we can get a little bit back on on time maybe and um then I'll hand it over to my colleague Moritz. Yeah.

And