Argot / Solidity | The Future of Solidity - Jacob Czepluch | Common S3nse - 2026

[music]

In this talk, I'll give you a brief overview of what's currently going on with Solidity and some of the things to expect in the future. And this works. Great. So, I'm Jacob. I'm the devrel for Solidity under the Argo Collective.

Um I started writing Solidity back in 2015 when I wrote my bachelor thesis about Ethereum. Uh this is like a very small snippet of of that code. Uh I'm not sure it compiles any longer. It's it's very old, but uh yeah, that's uh that's when when I started my uh journey with Solidity. Since then, I've been doing uh a bunch of different things.

Most of my time I spent building the Raiden Network, which was basically payment channels on Ethereum. Lightning Network kind of ported to to Ethereum back in 2016. Um did that for 6 years or something like that. Uh then I've worked um for Filecoin systems building hack prevention tools, and then in February I joined the Solidity team. And as part of the Argo Collective, I'll talk a little bit about what Argo is in a moment.

And sorry for turning around like the my other screen is dead. Um yeah, where are we standing with Solidity at the moment? Um It's been in production for 11 years. Um and the the last release we have is from July. Um where we had a pretty cool feature added into the experimental flag, which is eci FG.

I'm talking about that on the next slide, I think. Um and since 2015, uh sorry, 2025, the Argo Collective spun out of Ethereum Foundation and we are maintaining and developing Solidity but also Soursify which a lot of people probably know they have like a big database of verified smart contracts and they also maintain the four byte database. Of function signatures. Yeah, and a little bit about like We did the survey the the developer survey back in the beginning of the year and The biggest pain point for most people is still stack too deep. So weird.

Sorry, it's like my my screen shows something wrong. Let's see if I can fix it. It's very confusing. All right, now it's in sync. As I said, number one complaint for a long time.

We're fixing it now with the SSACFG pipeline that will do memory spilling to to to fix it. But at the core it's basically a problem that the EVM only allows to have 16 elements on the on the stack. There is another way to also fix this which which will be hopefully included in Glamsterdam in December which is the dup and swap and and exchange op codes which will basically give you access to around 270 items on the stack. So we can definitely look forward to a future where stack too deep is not a problem anymore. As I mentioned, we have the SSACFG pipeline on the experimental flag and our main priority until the end of the year is to get that into production.

And SSACFG is also nice for other reasons. For example, it will allow us to do a bunch of optimizations that will bring down the compile time uh quite drastically which is also a big pain point of Solidity developers. But, having been developing this language for 11 years, and when it was initially designed, no one really knew how people were going to write smart contracts, what are they going to use smart contracts for. Um so, that has resulted in a lot of patching uh of features over these 11 years, and now a big code base that is very hard to maintain. And things that we simply cannot really do, and it's not very um what do you call it, like long-term sustainable to to continue with this code base.

So, we are we were thinking, how can we What what what is the next step? How do we How do we make a smart contract language that is sustainable for the long run, and that include some of these features that have been requested since the very beginning? Um and that's where we introduce Cor Solidity. It's a redesigned language, so to speak, um on the same back end. So, who's asking for this?

Is one of the questions I often guess I get, like, who who who Why are you doing this? Did anyone ask for it? Um and the the the the short answer is like, it's been asked for since the very beginning, kind of. Already, as you can see here, like, we have an issue opened in November 2015, uh asking for a standard library in Cor Solidity, uh sorry, in Solidity. Something that it doesn't have right now.

The language is um tied to the compiler. So, every time there's a new feature, you we have to create a a precompile that is part of the the compiler. So, every and every time we touch the those part of the compiler, there's a big like risk that if we implement something wrong, it can have pretty fatal consequences. Generics were requested back in 2016. Same goes for enums and abstract data types.

Um compile evaluation is also almost 10 years ago since that was requested. So, there are a lot of these things in the language that have been requested from the get-go, but they simply cannot be implemented in the way that Solidity is currently designed. And then, people ask, "Why not just refactor the whole C++ compiler?" Um but we would rather not do that because that would also result in a lot of breaking changes over the years. Instead, we want to maintain classic Solidity and at the same time have core Solidity as what we kind of see as the modern, up-to-date language of writing smart contracts.

And here, you can see it's a the same back end all the way. So, as soon as we uh are at the the Yul level, then the the pipeline is the same, which also means that the SSA CFG uh work that we're currently doing carries directly over to also benefit core Solidity in the future. Um the plan for classic moving forward is to get into more of a maintenance mode. Um so, we're going to be planning 0.9, which will um remove some uh things that were introduced for EOF that never went through.

Um and just like cut down on some of the stuff that we will not be like continuing to develop on in the future, but it will go into maintenance mode, and it will continue to to to work as you know it today. Um but, you should not expect like a bunch of new features. Um and as you as I said, the tool chain is more or less the same, and probably we would just have a pragma in your Solidity files that mark if it's a classic or core, but this is still up for discussion. Um a couple of code examples so you can get a little bit of a taste for what the language looks like. I don't know if it's too um it's readable or not.

Um on on the left side you have a classic example of a payment handler where we have a struct that defines kind of what a payment uh looks like. Um and here you can see you have like all these different fields and then in your uh function that would calculate the fee, you have to do a lot of if if statements to find out which type of payment it is and then handle all each of these uh in in different ways. But in Core, we have abstract data types as I mentioned that we will have pattern matching which allows you to just define the different types of payments and match on them exactly. And that also means that if you add in a new payment type like ERC-1155, um then the compiler will directly tell you uh that there it's not matched like if if you forget to to add a a check for it, then the compiler tells you that it won't work. Whereas that's not the case for for classic and that this is something that has led to a bunch of bugs and exploits in in the past.

So here is what you'd see in in in Core. You'd simply get a message saying that your check is non-exhaustive. Um so you're not even allowed to compile your smart contract without handling all cases. And that means also that case coverage is no longer something that auditors need to check by hand because you get it for free by the compiler. Um one example that we actually have implemented um is uh multisig that is run like a state machine so pattern matching uh and ADTs are very good for for for state machines and represent sending state machines.

So here we have this multi sig that is very simple. You have the the approve and batch which basically just just can be represented as state machines. I won't go too much into detail with the code examples. I'm happy to to to give some examples after my my talk if you want to dive a little bit deeper into it, but I don't think it's worth it to to kind of explain line by line what's going on. And in the same way, this is a big one of the bigger things that we will change is that we will get rid of inheritance most likely unless we find some people that are very very strongly against it with some very very good arguments, but if you have ever written any big smart contracts, you probably know how hard it can be to deal with inheritance and like understanding if you have something like a diamond pattern, it's like you don't really know because of the C3 linearization if you're getting one value or the other value.

So these are some of the things we see that we can change at a language level that will make smart contracts more secure and less prone to errors. So we think it's worth doing it even though it does require that people kind of rethink how they structure their smart contracts, but I would be happy to give if you're if you're one of the people who are very much thinking I I have no idea how I can ever write smart contracts without inheritance, then please come talk to me after. I would love to understand why, but also show you a couple of examples of how we think you possibly can do it instead.

[snorts]

So yeah, the proposal right now would be with type classes and traits that they can take over most of the inheritance composition as you we it today. Another thing I mentioned that I think personally is really great is that we are separating the language from the compiler. Um right now in classic, ABI and code is C++ inside of the compiler, for example. In core, it would be a standard library uh function. So, instead of having to rely on the compiler team to add new features, you can simply have a standard library.

We could have, let's say, an Open Zeppelin version or a Solidity version that would represent your standard library. So, you have all the functionality that you you you know from Open Zeppelin directly available in your smart contracts just by importing uh basically this uh library. Um And from the the core language itself, there will be a very small uh standard library, at least that's our thinking at the moment, so that the community will be maintaining like the bigger um standard libraries. Um and that means that anyone can add features. You don't need to be a C++ uh developer and have an idea or an overview of more than 100,000 lines of uh of code just to to add new features.

You can you can do it yourself. Um a good example was that in the multi-sig example I showed earlier, the guy implementing it uh is an uh he used to work on Solidity back in the in the very early days. Um

[snorts]

And he he uh needed some some features and it was like five uh functions in the or features in the standard library. And one uh with a small change in the compiler, and it took him a couple of weeks in total. Um and since he was part of the Solidity team back in the days when they actually implemented these things in the in the compiler itself, he said that, "Okay, this was a couple of weeks. Back then, it was months. Um so he was extremely impressed and also excited about the fact that now he didn't have to sit and wait for the compiler to support the features he wants.

He can just add them into the language himself. And I think this is something that will really be nice um for everyone. Like we have a lot of feature requests, but we cannot we don't have the time and capacity to to do all of them. Um another example is we will have something like generics. Um so right now Forge standard library has this uh or Forge has this lock uh I think it's called function, which has 381 handwritten functions.

Yeah, it says lock. Um whereas with generics, we can just have one function per arity, which is also a a nice thing and it has like a smaller um risk of making errors. So that's very much the the focus of the language. As I said, the reason we're we're also like one of the the reasons we're doing this also it's it's of course for all the the users, but it's also for the maintainers. Um Core is a classic silly sorry.

More than 100,000 lines of code C++ um it's it's difficult to to understand and navigate your way through. Um so with Core, we'll have a small language that is much easier to maintain um and also maintain for the next yeah, I don't know 50 years. Um which is also important because if we continue with classic as it is now, I'm not sure that it's possible at all to make changes to the code in 5 years from now because it will be too complex and too high risk. Um so yeah, what are we doing now? Why am I I here?

Um How far out is is the is the language kind of? Um, it's still early days. We do have like it does compile. You can write smart contracts in it. Um, and because we are at that stage now, um, I'm currently talking to a lot of different people from the the the ecosystem.

I'm interviewing like DeFi protocols, library maintainers, security researchers, auditors, tooling builders, CTOs from from big companies to understand what they would like to see in a next generation Solidity and also what their concerns would be. Um, and we just want to share it with them early so that we can collect feedback in time for actually acting on it instead of releasing something and say here here's what you what what what we built, use it or not, but we really want to make sure we build a language that makes sense for the users. Do I have a time? I forgot when I started. Ah, okay, no one moderator.

Okay, I'm done in a couple of minutes anyway. Um, yeah, the current state is we have a a playground which you can play around with. It has a bunch of examples built in already. Um, but other than that you can you can try to write your own seed compile and inspect the the Yul. Um, couple of real contracts have already been ported over um, like the beacon chain deposit contract, the multi-sig I showed earlier.

Someone implemented a small Uniswap V2 um, and a bunch of other things and there's also one of the uh, things I'm currently doing is I'm taking some of the uh, libraries or contracts that people send me when they say I worry about how this will work or that will work and then I try to to port it over and this is a very good exercise for us to see what's still missing in the language and and what can be done differently. So, I encourage you to take a look at the at the playground linked at the bottom to see like what the language looks like and feels like and yeah, share any feedback with with me. Other than that, yeah, we currently had a we recently had a a big pull request merged that makes the syntax look and feel very much like classic Solidity which we think is kind of important for people to to to migrate. Then, the formal semantics of the of the language are in in progress and we hope that that will be done in a couple of months as well. And we're starting the production implementation hoping aiming for an early alpha by the end of this year, but that does not mean that we are necessarily anywhere close to a working production version.

So, yeah, just keep that in mind. Um The last thing I think I want to I want to end on is that if you are working with Solidity, have opinions on Solidity, uh opinions on what an improved version of it would look like, we still have a bunch of open questions. Um some of them is like around coercion, like implicit in classic. Should it be very explicit maybe in in in core because like in these these days most code is written by LLMs anyway, but reviewed by humans and in that case it might be good to have uh explicit coercion, but it would be maybe annoying to to write all the time. Same way, should it be backwards compatible or only or is forward compatibility an interesting thing?

What should the standard library look like? Compile time evaluation, like how far how far should that reach. So, we have a bunch of open questions still, and these are also the things that I usually talk to people about when I do these interviews I mentioned. Um so, yeah. Please, after this, if you're interested to see a couple of examples or have opinions, come and find me.

And in general, check out uh like the the state of things, and reach out if you have uh any comments or ideas. Um Yeah. I think that's uh that's all from me. Thank you.