How Sourcify is Reshaping Ethereum Smart Contract Security

Transcript

and we are basically the only verifier that does the cryptographic verification. I think a common misconception in verification is that a verified contract is safe. Ethereum has contracts open source because we think open source is a cornerstone of Ethereum. Everything should be transparent and verifiable. But if you look closely, these contracts are open sourced through closed source verifiers. So there's actually like something's not matching here. >> Biggest risk of unverified contracts >> completely losing your money.

Verification should be >> it has to be definitely expected. Welcome back to ecosystem project demo. This is episode 30 brought to you by EC Institute and I'm your host Pujaranjan. Today we are talking about something fundamental yet often overlooked. Imagine you go to a D5 protocol and it says it is open source and there is also a source code that you can follow and you believe the project and uh started making some transactions. You you send your funds and poof the funds are not there. The contract is not doing what

that is expected to do. This has happened. Can this be prevented? Yes, of course it can be. And today we are going to have a talk about one piece of infrastructure that exists specifically to stop these kind of scams. We are talking about smart contract verification. Our guest today is Khan us the lead dev at Sourcifi. Sourcifi is an open-source open data open standards project that verifies source code for Ethereum smart contracts and many other EVMs as well. Khan, welcome to the show.

Hi, I'm happy to join. I'm excited for the presentation. >> Well, web three codes secures billions and um verification secures trust. I feel that this is one of the most important yet underappreciated piece of Ethereum stack. We would love to dive deeper into it, but would love to kick off the conversation with your brief introduction. Let's know you more. What brought you to the space and what are your current projects that you're engaged with? >> Yeah, absolutely. So thanks for the intro and maybe as you said I'll give a short history and maybe my story of how I got here and so I have been in the space for a while. I think I start started following Ethereum at the

university when I was doing my bachelors. I was a computer student, computer science grad and at the end of my studies I started hearing about Bitcoin and then Ethereum and I first traded stuff and then I got curious about the technical aspects and over the time of my bachelors I did finishing project on Ethereum like it was a it was a voting system very early days of solidity and then I continued my masters in Munich my bachelor's was in Istanbul I moved to Germany and I continued my studies there in Tumik and there I also continued having some courses on blockchain. I participated in in a chair that does blockchain courses and there I

got a part-time job at Maxplank Institute and actually they have a blockchain prototype called Bloxburg at the time. It was a proof of authority chain across different universities and I got my hands on with EVM chain there managing the infrastructure and closer to finishing my studies when I was in Germany I started looking for positions specifically in crypto space in Berlin and I was quite lucky to come across the position opened at Ethereum Foundation and for the project sourceify at the time sourcify project was already in the Ethereum foundation it was contracted out but it was being moved in inside the foundation. So I

applied and I joined the project around 2021. I was the sole developer at the time. Um right now we're three people but since then uh I have been working on sourcify and related projects. Yeah, as I said it was an Ethereum Foundation project but maybe I'll shortly touch on this as well. We recently spun out from the Ethereum Foundation into a new organization called Argo Argo Collective with other projects such as solidity fail language and other formal verification languages.

>> Very interesting. Yes, we recently had a conversation with the developer solidity and new about argo collection. We would love to learn more about it and how that project supports sourcy. I find your journey quite incredible. starting as a student doing some trading then getting into voting at blockchain. Voting at blockchain is something like uh our time we used to make calculator as our first software right say that we have just started. >> Yeah it is an awesome journey and we would learn more like I think that you are doing a great job not only uh beginning now now you are into the auditing of these smart contracts which are very valuable. I understand there is a presentation. So without further ado,

let's uh look into the presentation. >> Yeah. So I will be giving a overview of sourcify in general. I will walk you through what source code verification is and how sourcify is different than other verifiers. So let me start with this. And I like starting my presentation with something I recently come across. So I was looking at one of the Ethereum forums. This is the open zeppelin forum. If you've seen that before, a lot of people have been asking questions here.

And here in this case, someone was asking a question around the EIP 1155, which is a token specification. And at the time in 2022, they were giving an example about EIP 1155 on a contract that is deployed on girly tested. So this contract is deployed at girly. So I was curious. I was looking at this and I click on this and I I and I come across this. So the gly test net as you know is shut down and with that the block explorers were also shut down. So I was really not able to see this contract and for me the this this kind of showed me

that part of the Ethereum history has been actually lost. I mean you can say Khan this is just a test net. Why do you care that much? But this also leads me thinking what what happens if this happens on the mainet. So um I was wondering like where are these contracts like where are they gone? So how can we what can we do about it? And don't get me wrong, like in general, I think Ethereum has good verification culture. In this case, I'm referring to, of course, source code verification, but I think we can do better. Ethereum has contracts open source because we think open source is a cornerstone of Ethereum. Everything should be transparent and verifiable. But if you look closely, these contracts are open

source through closed source verifiers. So there's actually like something's not matching here. And these contracts are also in closed data sets. So it's even though you can see them one by one, the whole data set is not as open as we want to be. That's that's what I'm going to explain. But before we dive before, let's give a background about source code verification. What it does, how it works, and why it's important. So in general, the Ethereum contracts are stored on the blockchain in byte code.

So bite codes are essentially ones and zeros. Those are not readable by humans and they look like this. Essentially if you look at if you look at Ethereum protocol and if you get a get the code of a contract this is how actually looks like and it's not really possible as you can see to tell what this does but in fact this is the bite code of the beacon chain deposit contract. problem here is humans we can't read bite code these are suited for machines they do um EVM instructions and they are not really understandable by by us humans write in programming languages

such as in EVM case it is most solidity wiper and there is something that is getting lost here so this is an example of a solidity contract and this is in fact part of the deposit contract track. So here it's more understandable, right? You can see some variable names, you can understand some of the operations, what it does. But again, if I come to you and show you this code, how do you actually know this is actually the code that is working behind? So I can be deceiving you. I can be showing a wrong code and in the at the end of the day, you are giving giving up giving your money to this code. So you really need to make sure that this is actually doing what it

does. That's why why we need a mapping from the source code from the solidity code to bite codes. This is essentially what the source code verification does. So if we go through an example imagine we have these contracts my contracts solve these are all solidify files and what we do is we take the solidity files that you give us or the developer gives us to do some source code verification. Then we add the compilation settings that were used and then we feed them into a compiler and we we compile this again. So you have actually deployed your contract the contract is already there and now you come to us and you give us these files. So we we do the

compilation and the compilation gives us a bite code and then what we do is we go to the contract address that you say okay like this is the contract and we get the bite code of that contract and then we compare if these bite codes match. Of course this is oversimplified but in on high level terms this is how the source code verification works. So we say like if these bite codes match we say okay like these files and these settings are actually the original settings. But of course the whole process is not ideal. Uh we have some problems in the current ecosystem let's say and the first thing and one of the most important ones is open source. So as I I don't think I need to emphasize

why open source is important in Ethereum but the case is right now that the largest verifier is closed source large block explorer is closed source and even if the block explorer part is closed source uh at least the verification part should be open source I would say because in this case the complete verification process is a black box so you can't actually reproduce the verification done by that verifier because it's a closed source process. The other thing that I mentioned about the data and the data set is that this whole data set is closed. So you can say how come it's closed like I can see the contracts, right? The problem is you can of course see the contracts because

that's the whole point you that you can see the contract source code, right? But the problem is that the data set is not really available. So it's under it's offchain and it's siloed under databases that are owned by companies. Why does this matter? Because the difference here between the EVM data, EVM protocol data and the contracts data is that the contract data, the contract sources, those files, solidity files are not in the Ethereum protocol. So they are offchain and they are usually under just a single database. So this this comes to the next point of centralization that when these are gone it's gone. So this

already as I said happened in the guries case in the rinkb test net's case. So these links are already 404s. These links are gone and that's why for me it's not so anyone can build a block explorer because the whole protocol the EVM data is out there but it's not the same case for a verification service because the data is offchain and siloed. And finally the tooling is stagnating and uh the devx I would say is suboptimal. I would say a lot of developers, EVM developer de developers have had a problem with verification once and it's a bit difficult to understand why the verification failed.

A lot of the times the API keys are required and also the current APIs I would say is lacking reaching rich compilation data. So we are actually not providing the developers with the full information such as source maps, bite code, storage layouts, immutables. So I think we can do better on this front as well. And the aside from that, if you look at the big picture, the current players are not really incentivized to open up themselves, right? If no one does anything, the status quo will stay like that and the current players in the ecosystem will not improve by themselves. So this requires some active

pushing by by external players like some new projects and this needs raising awareness and in general as I can say the crypto space has a lot of frontiers and this is actually something that is taken for granted and it's not really a sexy thing to build. So it's not really attractive someone looking outside to the crypto ecosystem. That's why we are working on sourcify and the verify alliance that I will also introduce. So sourcify as I have briefly introduced um solidity side project. So it started inside solidity within EF and then we recently spun out to Argo Argo Collective. Argo collective as well as sourcify is a nonprofit. We don't have any revenue and Argo was seeded with a 3

to four year grant from Ethereum Foundation and we are part of um four different projects and in general the sourcified team consists of three people. We are all developers. It's me, Manuel and Marco. And what about the verify alliance? So the verify alliance as the name suggests is an alliance of different verifiers in the ecosystem. Around one and a half or two years ago, we were in talks with different verifiers as well as SAM Sam CZoon that we wanted to start sharing data right I talked about how this data is siloed.

This is the data is centralized. So we started collaborating both uh by sharing verify contract data sets. That means that the verify alliance is a shared data base between all these verifiers as well as we share knowledge and collaborate between each other. Right? So yeah as the name suggest it's a open access database of EBM smart contracts and we export this data as well as the sourcify data daily in the parket format. So if you want to learn about it more you can visit the verifiance.org or and as I said right now it's consisting of block scout, route scan and sourcify as verifiers. So I talked about problems what are we doing to solve these

problems. So first of all we open source everything at sourcify for example our verification logic is under this mpm package. It's itum source lip sourceify and the nice thing about the the package is it allows reproducing verifications. That's one of the problems I talked about with with being closed source and a nice example of this is that we already do this in some other block explorer. So autoscan if you are not familiar is another fully open source block explorer based on argon node. So if you run an argon node, you can easily spin up an autoscan instance and block explorer instance and autoscan uses lip sourceify to do local verification

because lip source is browser friendly. How does this work? So if you open a contract page, you can already see the contract source code in the contract page. So it gets the source code from sourceify. But there is a button that you can click verify locally. And in that case this will fetch the sources from sourcify and it will compile the contract locally on your browser on your machine and it will do a reverification of the whole thing. So this allows reproducing the verification very easily on your browser. Of course the whole source stack is open source the server is open source. The repository is open source and aside from that we recently took over the largest 4 byt signature database. So this is the database of

Ethereum function and event signatures. It was the open chain database and we took it over into sourcify and we seeded with the data from there as well as with the data from our verified contracts and now we built one of the largest forte databases for Ethereum EVM chains and this is now powering a lot of the dev tooling behind the scenes. So if you're using Foundry, if you are doing any kind of AI decoding, you're probably already using this behind the scenes. And we also have a lot of source instances. So we actually want a lot of people to spin up their own instances. And we can already observe that a lot of different chains, different security tools are

using Sourcify in their own stack. So we serve as a whole package a verification service to them and they don't need to reinvent the wheel themselves. The second point we work on is verifying everywhere. So I talked about how data is closed and how data is siloed right and to work against this we are trying to push the whole ecosystem to verify everywhere. So we think a contract shouldn't be verified in one place only. Why why would you go to a one verifier where when you can easily go to all verifiers and also this serves as a comparison between different verifiers and also the data will be replicated

everywhere right so in that sense we sourcify as ourselves when you verify on sourcify we share this verifications share this contract with all verifiers that we are aware of there is one limitation here that uh etherscan has which says with one API key, you can only verify 250 contracts per day regardless of the tire of the API key. Otherwise, whenever we get a verification as as you can see on our UI as well, we share the contract with ether scan, route scan and block scout so that this goes to everywhere not that this data is not siloed in sourcy. The second point

is of course the verify alliance as I said verify alliance is a shared database of verified contracts. We also have built a remix plug-in that allows verifying everywhere very easily. So whenever you want to verify a contract on ether scan by default all explorers and all verifiers are selected so that you can seamlessly verify on all verifiers and we do the same thing on hard as well by default since recently when you verify a contract on hard it goes to everywhere and foundry we are also in talks with foundry and they are open to implement this and so that this doesn't cause any friction to developer and without knowing they verify

everywhere. And the third point is the open data. So again the closeness and siloed the data being siloed right. So to work against this we share the whole data set daily in parquet format. Parket is a modern data format that is often used in data analysis. It's a very compressionfriendly and a very modern format. And every day we share this data in these export.source source dev and export verify alliance.org addresses. So right now we have around 26 million verified contracts on sourcify. So sourcify supports basically every EVM chain. Right now I think we are around 180 chains. Of course like most of them

are longtail of chains that don't have so many contracts but Eure main mainet being the leading one. We have 26 million verified contracts and I would say we have around 3 million unique verifications. So of course you can imagine like a safe or a wallet contract is deployed multiple times right sometimes millions of times so this number includes that but if we only take the unique contracts it's around 3 million we also share the data as big query and Google and that means you can also use this in Google collab in Jupyter or python notebooks so this is the the bigquery database that we share And here in this example that you can

also see on our website on our main page we see for example how you can make use of this data set to do some data analysis on the fly. To showcase that we also have our AI playground. So if you go to our main page there's a data set playground that you can ask questions to the data set. So for example you can ask which contract is the most popular contract by contract name and then it will generate the query for you. Yeah, it will generate the SQL query and this will run against the big query instance to answer for example how many um safe proxies there are. Yeah. And what we want in general is so we think this open data set is really valuable and we think

this has been holding the ecosystem back for a while and we want this data to be used in other frontiers. So we think this will open a lot of innovation and this is basically an open call to everyone to have a look at the data and some of the examples we think this might be useful is using this in EVM tooling testing in bulk for example if you're writing a compiler basically you have a mapping of millions of contracts to byte codes so you can do the bulk testing this is for example being done by nomic foundations uh parser compiler Slang uh you can use this to do some data analysis is we can feed this data to AI models to have better solidity models.

We can build a better decompiler. That's something I'm really interested in. So decompilers are basically tools very useful especially during war rooms like when there's a security hack to understand what the bite code does because we don't have the source code verified there. security researchers try to understand what it does and I think using this data set we can build better ones and yeah another final example maybe is finding vulnerability patterns so this has actually worked in practice recently I think when there was a small bug in solidity with the transient storage the security researchers used the verify alliance data set to see which contracts have transient storage

and then they were able to address these and they were able to see which contracts are affected. So yeah, this is an open call to make use of this valuable data set and move the EVM tooling forward. I'll keep it here. So this was a quick intro about everything. If you want to learn more, you can follow us on X in SourceFi ETH and verify alliance as well as you can feel free to reach out to me anytime on matrix and Telegram. Thank you. >> Great. Would you want to maybe go ahead with the demo? Sure. Let me give some quick demo. Maybe I'll first show the AI playground.

So this is the sourceify main page and as I also mentioned in the presentation we have the data set playground. So we can say you can ask questions here and we will use some free LLMs to ask these questions. So as I said for example we can say which contract is the most popular contract or gimmick contracts with solidity version a very old version then this will generate the SQL for us. This is the query generated and then we can execute this query in BigQuery and this will show the instances of contracts. For example, this contract on optimism mainet is one of those that has

um this old solidity version. So you can imagine a lot of different stuff that you can use here. You can also check out the collab notebook that has a lot of examples and see the bitquery data set. The other example I want to give is through remix. So I just want to quickly verify a contract on Remix. Yeah. So I guess a lot of people are already familiar with the remix IDE. So what I'm going to do here is I'm going to compile a contract and one of the basic contracts and then after compilation I can go to contract verification tab and here sorry of

course we need to deploy this contract before. So, I'm going to deploy this on Sepia testnet. I have this account that has some ETH here and I'm going to deploy this contract. I guess it's not shown on the screen, but I'm on MetaMask now. And I'm clicking confirm to deploy this contract. You can see the creation of the co the contract is pending and I guess this is successfully deployed. Yeah. So we have the contract address here. Um and now I take the contract address. I go to verification page. I paste the address here and I can

choose Ethereum Sapoleia. As you can see, sourceify blocks got rodcan these are already selected. Ether scan is also selected because I have added my etherscan API key here previously. So this is also checked and then I can click verify and this contract is verified on sourcify and you can see the contract here. You can also see it's also on ether scan block scout or route scan as well. So it's also verified on ether scan. I also forgot to mention normally when you are deploying remix has this checkbox that is by default checked in that will say deploy and verify instead of deploying but I wanted to show the

plug-in separately but otherwise usual practice is just deploy and verify at the same time. Yeah. So this will be a short and quick demo of how the verification works. >> That's pretty insightful. The presentation was precise and something that we can understand even even if someone is looking it for the very first time. So sourcifi is basically doing everything what it says open source open data open standards. I will come back on each one of them one by one to you. So let's begin with um the very first job that sourceify does the verification.

Suppose I am a defaer I do not deploy any kind of contract. Do you think source is for me? Why do I need to go ahead and check my contracts before using? >> Yeah, exactly. So, first of all, if you want to interact with a contract, you need the AI of the contract. So, AI is the application binary interface and that basically tell us which functions to call and how to talk to a contract. And you actually need unless the API is published separately, which is quite rare, you actually need the source code to be verified to be able to see how to talk to this contract. So if you want to send a transaction, you need to know the API of this contract. So that's one of

the main use cases of a verification service like Sourceify. Of course, the other thing is you want to see what your source code does. And even if you're not a technical user and if you don't understand the code, you want the community and the security researchers or auditors to be able to see the contract. So maybe this won't be something you will look at daily. Uh but this is the basis for everything that you are relying on a blockchain such as trustlessness, transparency and so on. So in general it may not be that much helpful for general users who do not understand the technical codes behind it but it could be useful for developer who are actually deploying contracts or trying to interact with different

contracts. >> Yeah, >> I'm curious if there is anything that source has in the plan or the road map for general users to make it even more simpler so that with just one click of button they would be able to like figure out if this is a contract I should interact or not at all. >> Yeah. So that's a larger problem set. That's more in the whole contract security stack. That's also something we are very interested in. But we initially wanted to focus only on the source code verification because we saw the problems there. But now we are also trying to expand and attack the problems in the ecosystems there as well. For example, we are also part of the recent clear signing initiative that will be

announced soon that we want to have users to have human readable instructions before they sign transactions. I guess everyone has been familiar with this. When you're signing a transaction on Ethereum, you are basically greeted with ones and zeros and you don't understand what you're doing. You blindly sign and everyone knows the consequences of this such as the Bit hack. I think that's the biggest and the most well-known one. So we are also now shifting our focus there. That's something we think we can help with. But as I said the whole security stack is very big. So you need to know is the contract that I'm talking to the correct one. Is this actually a

unis swap contract? Is um like do I have my passphrases secured and so on? like the whole stack is very large and we are trying to see where we can be useful and be focused on that part. >> That makes sense. Every stack has its importance and people can make use of whatever they are sharing with us. Let's talk about how sourceify works. You explained about that it actually works by mapping the source code with the bite code and ensuring that the project is doing what it says it should be doing. There were a couple of things like partial verification and functional verification. if you could maybe elaborate a little bit more on that to understand the functionality of sourceify.

>> Yes. So sourcify as I said does so I didn't want to get into that much detail initially but sourceify also has a feature to verify contracts fully as it was named before versus partially. This means when partially when we say partial we say it's also a complete verification. The name is a bit misleading but it's also a verification but it is not a cryptographic verification of the contract. So if I may show a feature of the solidity compiler. So the solidity compiler has a field at the end of the bite code that allows us to

cryptographically verify. So we show this at playground sourcified dev and by default the solidity compiler I'm going to open an example contract maybe this one. So this is a bite code and by default the solidity compiler appends a hash at the end of the bite code. So if you decode this part you will see an IPFS hash of a file and this hash called metadata file metadata hash contains things like AI. So like how to talk to this contract and it's like a blueprint of the whole compilation. It has the compiler version. It has if I scroll down it has the settings and it has the sources and their hashes. So like every

source that was used has its hash in this file and the hash of this whole file as I said is appended onchain at the end of the bite code. So when you verify a contract fully not partially when you verify fully we verified this functional byte. So this is the executional bite code that's executed by the EVM and we also verified this metadata part which means the source code that you are seeing is a bite byte match of the original one. How? Because if I deploy a contract and I have this hash, right? And then if I go ahead and if I add a space in one of these

sources, so the hash of these sources will change, right? If I add a comment to this file, right? This hash will change and then consequentially the whole hash of this file will change. So you will end up with a different hash. So we will say okay like these two source codes actually function the same but they are not 100% the same. So this even gives a higher degree of guarantee that what you're seeing is actually the the exactly the same thing exactly the original one. So if I go to source repo for example here I see it's a match.

This means yeah this is not a full match but if I go to an example contract here an exact match will tell me okay like this is actually the complete 100% cryptographically verified match yeah >> so I understand these are the two options those are currently available at sourceify depending upon choice people can pick it up >> not the choice it's a feature of a verification so if unless you turn it off so there's a setting to turn off the hash there are reasons to do that unless you do that and you verify on sourcify, it will end up with an exact match. And we are basically the only verifier that does the cryptographic verification.

Other verifiers are not considering that part of the code. >> That's good to know. And these source can be run by itself like this can be self-hosted right? >> Yes, absolutely. You can either use our instance or if you want you can just download the whole codebase and run it very easily. you mentioned about a verifier alliance uh that the open database that is available for all all verifiers or okay perfect >> so I mean right now as I said there are like three verifiers there is sourcify there is block scout there's route scan but we hope other verifiers even the bigger ones to join one day and share their data and we'll see >> yes uh this is open source world I'm

sure that's going to happen one day >> hopefully Very well. My next question is with respect to the audit. So I understand that verifying is important for an individual, for a developer, but it could be important for a project as a whole and especially for auditors who are going to audit these projects. Do you think that having the contracts verified could be made mandatory for auditing purposes? >> I hope so. I'm not fully familiar with the complete auditing process but I think auditors definitely require this require a contract to be verified to be audited even if it's not publicly available like that means for example

it's not on sourcify it's not on ether scan the auditors still need to verify first otherwise how can they be sure that the source code they're auditing is actually the correct one so that's definitely a basis of audit thing and a requirement >> right I mean I feel like it could be a very useful feature if that can be considered as a standard I was seriously surprised to see the number close to 27 million contract reviewed I mean of course there were like 3 million unique contract as you mentioned but still the number is too high it would be a good idea to have it verified if we can get it done >> yeah by any chance do you know how much

of the ecosystem today is still running unverified contracts. >> Actually, it's surprisingly large. So, I think maybe the 10% of the whole contracts are verified. But I think the important thing here and we actually wanted to create a metric with this in collaboration with Grovey. Grovi is also a data analytics platform and we wanted to create a metric of how many of the transactions go through verified contracts. So I think that's the more important metric because we have a lot of contracts that are not used at all.

They just people just deploy it and just forget about it. But I think the important part is how much of the aggregate Ethereum code let's say goes through verified contracts only. And I think today the number I would assume is quite high in Ethereum probably much higher than other ecosystems because as I said Ethereum has a really strong verification culture. People really demand the contracts to be verified. And the biggest exception to this right now is usually the trading bots. So a lot of people don't verify of course their me and trading bots. So that's contributing to the other side of the equation.

>> Still a lot of other contracts have to go if we are only at the 10%. >> Yeah. Unfortunately. >> Well, you mentioned about the privacy. I understand in web three ecosystem especially in Ethereum ecosystem people care a lot about privacy. I wonder uh how sourcifi helps about the transparency the user transparency. Uh do you think that at one point of time even wallet can warn users when interacting with unverified contract? >> So I think as I said the source code verification is the basis of everything.

So without knowing what your contract does, it's basically a black box that you are talking to. So you don't know what the whole contract does. And on top of that, this also empowers all the downstream tooling. So if you want to see what a transaction does, you still need the contract source code or the AI to be able to understand what it does. So in general I think to be able to have an overview of the whole whole blockchain a source code verification is very essential because without that the only thing we see is bytes ones and zeros and it's really impossible to understand >> right and I'm wondering if there is any kind of misconception or common mistake

that is being done by the developer even while using the verifier. So I think a common misconception in verification is that a verified contract is safe. It is not. So a verification only opens sources. So I I sometimes wish we have a better name for this. A verification of course like semantically implies something safe, right? It's not. So it's just open sourcing the contract. So a contract being verified does not mean it's safe to interact with. It's just a requirement, but it's not sufficient.

You need to have the contract verified, but to be able to say that this contract is safe, this needs to be audited and of course battle tested and must be scrutinized by the community. >> Yeah, I understand. But I think at least verification is giving some sense of security, some sense of assurance that it can be proved. Yeah, >> it is provable there. Well, Sourceify talks about open standards. I wonder if people are engaged in any kind of standardization that should go behind these kind of verifiers. Are you people trying to work with any EIPs or ERC's in general? I would say we don't have that many EIPs or ERC's around this because this is more around the tooling and what

we try to standardize here is for example a shared data format that how we export the data set right so with the the data that sourcify and verify alliance is exporting is somewhat standardized that everyone can make use of we actually had an EIP around verification it was for EUF. Eventually EF was not included but it was to standardize this hash metadata hash that I show in the code container so that all the verifiers can easily ignore that part but unfortunately that didn't go through it would have made our lives very easy. So these are the

standardization efforts that we're mostly working on >> right we understand that EF is not the part of current road map of Ethereum but maybe in future if there is anything aligned maybe we can see some proposals coming in well talking about road map I wonder what is the road map of source if I uh how do we see the project progressing in the year of 2026 and specifically the role of AI I understand you've mentioned a little bit usage of LLMs for some basic queries could Could you maybe elaborate more on that? >> Yeah, so first of all, we value working openly a lot in Sourceify and Argo and our road maps and progresses. We we periodically share our road maps and progresses. So you can see our 2025

look back and our road map in the source blog as well as the Argo blog. But if I can summarize the biggest milestone we are working on right now is increasing the contract coverage. So the chain coverage as I said we have pretty good coverage in Ethereum mainets and some other bigger chains like optimism but we want to increase this 25 million 26 million even more and we believe we can create the largest EVM contract database and the larger it is the more useful it is. So that's one of our main goals.

Other thing that I also mentioned is we are assisting the clear signing efforts. We are developing the clear signing SDK for software wallets to be used. In short, clear signing if I give us if I can give a summary. So as I said, we see bytes and hex's when we are signing things, right? So to fix that, we need a separate descriptor of transactions. And with other projects we are building this registry and the tool set and source is assisting with the tooling and the knowledge around source code verification and APIs. So we think this is the most impactful thing we can do for the Ethereum ecosystem and that's

another priority of us and regarding AI. So I think I actually have been talking about this this week with my colleagues. Our productivity has increased a lot using AIS and over the next couple months we are integrating all the AI tools in our workflow as well as as I said we are looking into make use of the data set that we have with the specified contracts to see how this can be useful for AI models for the EVM developers to be useful eventually >> I see that there is already a very decent coverage like 180 plus EVM chains it's good like contracts also even If we are at the 10% that's not bad. That's actually an commendable number for the

team who have recently started about working on this thing and the usage of AI I'm sure it's going to help a lot. We believe that um it is complimentary and for a project like this AI can do wonders. Yeah. Well, my next question in this section is if someone is listening right now and want to help or get involved where can they find the team? You can follow us on Twitter and we also have open chat channels over matrix and discord. So our preferred platform is element matrix but we also bridge it to discord so that you can reach us out. We have some power users that are quite active there. So feel free to ask

anything about sourcify. >> Great. And before we wrap up our session for today, we do have a set of rapid fire questions for you. So if you're ready, we can go ahead with that. All right. Sourcify in few words. >> Source code verification, open source, open data. >> Biggest risk of unverified contracts. >> Completely losing your money. >> Verification should be optional or expected. >> It has to be definitely expected. >> Blocks explorer versus sourcifi. What would be the key difference or the unique point that you would want to mention? Yes, sourceify is source code verification only. So only the source contracts. But blog explorers index and

keep track of the whole chain. >> One myth about contract verification. >> Yeah, it's it's not that if it's verified, it's safe. It's wrong. >> Should DAO governance contract always be verified? >> Yeah, absolutely. I don't see they will also have to be verified to be able to collaborate. Let's say >> is verification more important for users or developers? >> Both. It might be more apparent for a developer, but for a user it's equally important that behind the scenes everything is transparent and working as expected.

>> One metrics uh that you would want to keep track of for the impact >> definitely the contract coverage number of contracts and also as I said that the other metric that we want to work on is how much of the transactions go through verified contracts. The future of a smart contract transparency is >> open source. >> Yep. Indeed. It's inevitable. It's going to be there. >> Yes. >> Well, thank you so much. Uh it was great talking to you Khan. In one sentence, if you have to like summarize Sourceify, >> it is fully open source and fully open data. Just verify everywhere, not in one place.

>> Awesome. That was great. It was lovely talking to you Khan and uh very interesting this project is and I'm sure that it will get its shared attention that people should provide because this is very important. We understand Ethereum is programmable trust and trust requires verification. So sourcifi is quietly bridging that gap and providing that infrastructure which actually can be used running uh onchain verifying all these contracts. Thank you so much for your work and a congratulation to the entire team. >> Thank you. Thanks for having me. It was a pleasure and great to be here and talk to everyone. Yeah.

>> Dear listeners, if you are a developer, auditor or enterprise users, please check out show notes and learn more about this project. This is very important for upcoming days. We would want that web 3 to be a safer space for people to follow and uh you would get all the information below. If you like this episode, if you like this conversation, let us know by your comment below. We will bring another interesting project from ecosystem. Till then keep building. Cheers everyone.