oksolc, a Solidity compiler in Zig

Devcon 8 · 4 Nov 2026 · 8:04

Henri Binsztok, co-founder of OKcontract Labs, presents oksolc, a Solidity compiler written in Zig that reproduces solc output byte for byte, including JSON and metadata. It began as an AI-assisted port of the C++ code using LLVM instrumentation, then gained speed from better data structures and caching (2.5x on one core), parallel compilation (10x to 12x on EigenLayer) and incremental compilation backed by SQLite, cutting a Pendle recompile from about 55 seconds to 0.44 seconds. It works with Foundry through a solc path setting, and formal verification of the compiler in Lean has started.

Speakers

Topics

From Devcon 8, hosted by Ethereum Foundation.

Transcript

[music] [music] >> Hi everyone. So, I'm Ori. I'm the co-founder at OK contract. Uh and uh I'm HBBQ on on Twitter. And uh there's one tweet if you want the last one, you can have a look. And yeah, and basically we've built OK Solci, uh which is a Solidity compiler written in Zig.

Uh and it's a smaller code base that's really important. It's up to 50x faster to compile and getting the exact same output. How did we Oh, sorry. Uh where is the back? >> [snorts] >> Uh yeah. So, how did we do this? Uh first, we translated Solci into Zig uh using an automated process where we instrumented LLVM. Basically, get more annotations about the initial source code of in C++ of Solci and extracted uh more about the semantics so we could use AI to port in a much better way the C++ code into Zig. And this is the

AI-assisted port, which gave us uh a Zig baseline. And from that point on, we made a promise that we should stick to the exact same output of the compiler, including byte for byte the JSON, including the metadata. Then, we optimized it uh and Zigged a whole lot. Happy to talk more uh if you have questions about it. But basically, we went uh 2.5x faster using a single core, one compiler job for instance on Uniswap Pendle EigenLayer using better data structure and some uh optimization in the passes, better caching, etc. etc.

But, we didn't stop here. Once we had this pretty good foundation in Zig, which is also much shorter than the initial code base. It's only, I would say, 140,000 lines of Zig. Then, Zig is also very good for parallelizing code, which we did. And then, we started getting up to 10x or even 12x performance on Eigen Layer just by parallelizing the compilation. And this mattered a lot to us because we are building a pretty large protocol called Chainlink, and it's We started doing this because actually compiling Chainlink was 12 minutes with Solidity, and that was way too much. But, we needed the exact same

output. And we didn't stop here. Then, we also implemented incremental compilation. So, especially if you're working at a fast pace, if you're adding more tests to your code base, and we we did the split where we manually wrote most of the contracts, but we used AI to write the tests themselves which grew our test Solidity code base to 70k 80k lines of tests, and that took a lot of time to compile.

And that's why we also needed this fully incremental compilation. So, what we did was embedded SQLite in the compiler so we can save the right intermediary representations and have them compiled and properly and and restart operation. And there, we get 4x to 5x acceleration in addition to the 10x we already have with parallel compilation. And this is how, for instance, we can recompile a change in Pendle. Pendle, just to give you an idea, the initial compilation time of Pendle is on that machine was 54, 55 seconds, and we bring this time down to 0.44 seconds

for incremental compilation for some changes. And for Uniswap, we get from nearly 100 plus seconds using Sol-C to 1.5 seconds to to recompile things. And again, using the exact same compiler output, same bytecode, same metadata. It's very easy to use. It's compatible with Foundry, of course. You just need to either set in your foundry.toml the Sol-C with the path to OK Sol-C, or if you want to do it globally, there's a global called foundry_solc, and you point it to OK Sol-C, and you're

done. And then you have a some little configuration, which you can do on OK Sol-C.toml, the new file that you're adding, where you say you want parallel true, you want eight jobs or six jobs or 12 jobs if you have a recent computer, and whether you want to enable the incremental compilation or not. And there's many other options. For instance, there's also a web browser where you can browse your Solidity codebase, etc., etc. And all this is included in the the light count I mentioned, and we're going to add way more things. And this is the bigger things that I want to announce. I have another longer talk on the Security Hub

by the DAO upstairs, and we are going to announce a pretty big news, and which is also one of the reason why we made this. We have started formal verification of OK Sol-C in Lean. I just pushed the PR, that's 300,000 lines, most of it in Lean. A lot of automation, but my background is formal verification. I did formal verification manually in the past before AI. And but now we we have it, and we are going to fully formalize OK Sol-C in the next months, and hopefully we'll be done within within a year. Thanks a lot if you have questions, there's 1 minute left.

>> [applause] >> Beautiful. Thank you very much, Henry. That is fast. That is very very fast. >> Oh, thank you. Any questions? >> Now we can open up to the table for questions. Would anyone like to ask Henry anything about how fast he managed to get this compiler? All right, this is coming your way. >> [snorts] >> Go with it. This one. >> So, how are you testing the bytecode equivalents? Like do you have a mass test like a bulk test on every single contract? I'm asking because I'm working on CertiK and >> Okay.

>> use the dataset to have bytecode equivalents? >> We want your dataset. Right now, we've built a benchmark. We assembled a few code bases of all the largest projects and we're using it as a benchmark. But of course, we would love to have way more. Let's chat. >> Beautiful. Thank you. I'm going to put a question in here is how does it compare on gas performance? >> Oh, on purpose, right now we exact we output the exact same bytecode. So, it's the exact same gas. But we have what by doing the compiler, we have a very large catalog of gas optimizations that we can do and we will introduce them. But we

are also discussing with the Agda guys and we're trying to sync on that. So, we we will if you look at the issues on okay so see that the the the PRs, we have some gas potential optimization for Solsee and we will share them. So, we'll try to keep in sync and have the exact same bytecode together. >> Great. So, not only making yourselves fast, but you're also making Solsee more gas efficient as well. >> Oh, thank you. >> [music]