speaker-0: 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. has contracts open source because we think open source is the 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.

speaker-1: biggest risk of unverified contracts.

speaker-0: Completely losing your money?

speaker-1: Verification should be...

speaker-0: It has to be definitely expect

speaker-1: Welcome back to Ecosystem Project Demo. This is episode 30 brought to you by ECH Institute and I'm your host Pooja Ranjan. Today we are talking about something fundamental yet often overlooked. Imagine you go to a DeFi 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 started making some transactions. You send your funds and poof the funds are not there. The contract is not doing what it 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 kinds of scams. are talking about smart contract verification. guest today is Khan Uzom, the leader at Sourceify. Sourceify 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.

speaker-0: Hi, I'm happy to join, I'm excited for the presentation.

speaker-1: Well, Web3 codes secure billions and 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 this space and what are your current projects that you're engaged with.

speaker-0: Yeah, absolutely. So thanks for the intro. 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 this space for a while. I think I started following Ethereum at the university when I was doing my bachelor's. I was a 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 bachelor's, I did finishing project on Ethereum. Like it was a voting system, very early days of Solidity. And then I continued my master's in Munich. My bachelor's was in Istanbul. I moved to Germany and I continued my studies there in TU Munich. And there I also continued having some courses on blockchain. I participated in a chair that does blockchain courses and There I got a part-time job at Max Planck Institute and actually they have a blockchain prototype called Blocksburg at the time. It was a proof of authority chain across different universities. And I got my hands on with an 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 that Ethereum foundation and for the project Sourceify at the time Sourceify 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. Right now we're three people, but since then I have been working on Sourceify 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 spawned 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.

speaker-1: Very interesting. Yes, we recently had a conversation with the developers at Solidity and they knew about Argo Collection. We'd love to learn more about it and how that project supports Sourceify. 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 our time we used to make Calculator as our first software. Just say that we had just started. It is an awesome journey. we would learn more. Like I think that you are doing a great job, not only 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 look into the presentation.

speaker-0: Yeah, so I will be giving an overview of Sourceify in general. I will walk you through what source code verification is and how Sourceify 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 Gurley Testnet. So this contract is deployed at Gurley. So I was curious, I was looking at this and I click on this and I come across this. So the Girlie testnet, 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. for me, 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 happens if this happens on the main net? ⁓ 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 some things not matching here. And these contracts are also in closed datasets. So it's, even though you can see them one by one, the whole dataset 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 bytecode. So bytecode 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 the Ethereum protocol and if you get a get the code of a contract. This is how actually it looks like. And it's not really possible as you can see to tell what this does. But in fact, this is the bytecode of the beacon chain deposit contract. Problem here is humans, we can't read bytecode. These are suited for machines. They do ⁓ EVM instructions and they are not really understandable 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. 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. can be showing a wrong code. And at the end of the day, you are giving your money to this code. So you really need to make sure that this is actually doing what it does. That's why we need ⁓ mapping from the source code, from the solidity code to byte codes. This is essentially what the source code verification does. So if we go through an example, imagine We have these contracts, mycontracts.sol, these are all Solidity 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 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 can read. we do the compilation and the compilation gives us a bytecode. 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 bytecode of that contract. And then we compare if these bytecodes match. Of course, this is oversimplified, but in on high level terms, this is how the source code verification works. So we say like, these bytecodes match, we say, okay, like these files and these settings are actually the original. But of course, the whole process is not ideal. 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, 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, largest block explorer is closed source. And even if the block explorer part is closed source, At least the verification part should be open source. 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 dataset is that this whole dataset is closed. So you can say, how come it's closed? I can see the contracts, right? The problem is You can of course see the contracts because that's the whole point 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 off chain 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, sold it files, are not in Ethereum protocol. So they are off chain and they are usually under just a single database. this comes to the next point of decentralization that when these are gone, it's gone. So this already, as I said, happened in the Gurley's case, in the Rinkeby testnet's case. So these links are already 404, these links are gone. And that's why for me, It's not so anyone can build a block explorer because the whole protocol to EVM data is ⁓ out there, but it's not the same case for a verification service because the data is off-chain and siloed. And finally, the tooling is stagnating and the dev ex I would say is suboptimal. I would say a lot of developers, EVM developers have had a problem with verification once and it's a bit difficult to understand why the verification failed. A lot of times the API keys are required and also the current APIs, I would say, is lacking rich compilation data. So we are actually not providing the developers with the full information such as source maps, bytecode, storage layouts, immutables. So I think we can do better on this front as well. 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 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 succeeding the build. So it's not really attractive someone looking outside to the crypto ecosystem. That's why we are working on Sourceify and Verify Alliance that I will also introduce. So Sourceify, as I have briefly introduced ⁓ 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 Sourceify is a non-profit. We don't have any revenue. And Argo was seeded with a three to four year grant from Ethereum foundation. And we are part of four different projects. And in general, the Sourcify 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 sees you soon. that we wanted to start sharing data, right? I talked about how this data is siloed, is the data is centralized. So we started collaborating both by sharing verified contract datasets. That means that the Verify Alliance is a shared database between all these verifiers, as well as we share knowledge and collaborate between each other, right? So yeah, as the name suggests, it's a... open access database of EVM smart contracts. And we export this data as well as the source by data daily in the parquet format. So if you want to learn about it more, you can visit theverifierlines.org. And as I said, right now it's consisting of block scout, route scan, and sourceify as verifiers. So I talked about problems. What are we doing to solve these problems? So first of all, we open source everything at sourceify. For example, our verification logic. is under this npm package. It's Ethereum Sourceify, Leap Sourceify. And the nice thing about the package is it allows reproducing verifications. That's one of the problems I talked about 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're not familiar, is another fully open source block explorer based on Aragon node. So, if you run the Aragon node, you can easily spin up and AuthorScan instance and Block Explorer instance and AuthorScan uses lib-sourceify to do local verification because lib-sourceify 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 sourceify. and it will compile the contract locally on your browser on your machine and it will do a re-verification of the whole thing. So this allows reproducing the verification very easily on your browser. Of course, the whole Sourceify 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-byte 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 Sourceify 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 4 byte databases for Ethereum EVM chains. And this is now powering a lot of the dev tooling behind the scenes. if you're using Foundry, if you are doing any kind of ABI decoding, you're probably already using this behind the scenes. And we also have a lot of Sourceify instances. 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 Sourceify 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 errorware. 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 on you. Why would you go to a one verifier 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, Sourceify, as ourselves, when you verify on Sourceify, we share this verification, share this contract with all verifiers that we are aware of. There is one limitation here that Etherscan has, which says with one API key, you can only verify 250 contracts per day, regardless of the tier 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 Etherscan, Routescan and Blockscout so that this goes to everywhere, not that this data is not siloed in Sourceify. 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 plugin that allows verifying everywhere very easily. So whenever you want to verify a contract on Etherscan, 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 drive as well by default since recently when you verify a contract on hard drive 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. Does the data being siloed? Right. So to work against this, we share the whole data set daily in Parquet format. Parquet is a modern data format that is often used in data analysis. It's a very compression friendly and a very modern format. And every day we share this data in these export.sourcefiedev and export. VerifyAlliance.org addresses. So right now we have around 26 million verified contracts on Sourceify. So Sourceify supports basically every EVM chain. Right now, I think we are around 180 chains. Of course, like most of them are long tail of chains that don't have so many contracts, but it's your main being 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 BigQuery and Google. And that means you can also use this in Google Collab in Jupyter or Python notebooks. So this is 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 dataset to do some data analysis on the fly. To showcase that, we also have an AI playground. So if you go to our main page, there's a dataset playground that you can ask questions to the dataset. 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 SQL query and this will run against the BigQuery instance to answer, for example, how many ⁓ Benosys safe proxies there are. Yeah, and what we want in general is, so we think this open dataset 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 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, a parser compiler, S-Lang. You can use this to do some data analysis. 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 the war rooms, like when there's a security hack to understand what the bytecode does. Because we don't have the source code verified there. security researchers try to understand what it does. And I think using this dataset, 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 dataset 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 dataset 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.

speaker-1: Would you want to maybe go ahead with the demo?

speaker-0: Sure. Let me give some quick demo. Maybe I'll first show the AI Playgrounds. So this is the Sourceify main page. And as I also mentioned in the presentation, we have this dataset 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 Mainnet is one of those that has this old Solidity version. So you can imagine out of different stuff that you can use here. You can also check out the Colab Notebook that has a lot of examples and see the BigQuery 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 Sepolia test net. 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 am on MetaMask now and I'm clicking confirm to deploy this contract. You can see the creation of the contract is pending and I guess this is successfully deployed. Yeah. So we have the contract address here. And now I take the contract address. go to verification page. paste the address here and I can choose Ethereum Sepolia. As you can see, Sourceify, Blocks, Cards, Routescan, these are already selected. Etherscan 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 Sourceify and you can see the contract here. You can also see it's also on ether scan, block scout or route scan as well. 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 plugin 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.

speaker-1: That's pretty insightful. The presentation was precise and something that we can understand even if someone is looking at it for the very first time. So, Sourceify 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 the very first job that Sourceify does, the verification. Suppose I am a DeFi user. I do not deploy any kind of contract you think Sourceify is for me, why do I need to go ahead and check my contracts before using it?

speaker-0: Yeah, exactly. So first of all, if you want to interact with a contract, you need the ABI of the contract. So ABI 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 ABI 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. maybe this won't be something you will look at daily, but this is the basis for everything that you are relying on a blockchain such as trustlessness. transparency and so on.

speaker-1: 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 developers who are actually deploying contracts or trying to interact with different contracts. I'm curious if there is anything that SOCify has in the plan or the roadmap for general users to make it even more simpler so that with just one click of button, they would be able to figure out if this is a contract I should interact or not at all.

speaker-0: 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. guess everyone has been familiar with this when you are 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 Bybit 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 Uniswap contract? 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.

speaker-1: 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 bytecode 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.

speaker-0: Yes. So, Sourceify, 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 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 bytecode that allows us to cryptographically verify. So we show this at playground, sourceify dev. And by default, the Solidity compiler, I'm going to open an example contract. Maybe this one. So this is a bytecode and by default the Solidity compiler appends a hash at the end of the bytecode. 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 ABI. So like how to talk to this contract. And it's like a blueprint of the whole compilation. It has a 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 on chain at the end of the bytecode. So when you verify a contract fully, not partially, when you verify fully, we verify this functional byte. So this is the executional bytecode that's executed by the EVM. And we also verified this metadata part, which means the source code that you are seeing is a byte by 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 Consequently, 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 exactly the same thing, exactly the original one. So if I go to the source file 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.

speaker-1: So I understand these are the two options. Those are currently available at Sorsify. Depending upon choice, people can pick it up.

speaker-0: Not the choice, it's a feature of a verification. if, unless you turn it off, so there is a setting to turn off the hash. There are reasons to do that. Unless you do that and you verify on Sourceify, 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.

speaker-1: That's good to know. And these sources can be run by itself. Like this can be self-hosted, right?

speaker-0: Yes, absolutely. You can either use our instance or if you want you can just download the whole code base and run it very easily.

speaker-1: You mentioned about a verifier alliance, the open database that is available for all verifiers. OK, perfect.

speaker-0: So, I mean, right now, as I said, there are like three verifiers. There is Sourceify, there is Blockscout, there is RouteScan, but we hope other verifiers, even the bigger ones, to join one day and share their data. And we'll see.

speaker-1: Yes, this is open source world. I'm sure that's going to happen one day.

speaker-0: Hopefully.

speaker-1: 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?

speaker-0: 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 Sourceify, it's not on Etherscan. 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 auditing and a requirement.

speaker-1: Right. I 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 contracts reviewed. I mean, of course there were like three million unique contract, as you mentioned, but still the number is too high. would be a good idea to have it verified if we can get it done. How many chance do you know how much of the ecosystem today is still running unverified contracts?

speaker-0: 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 Grove Depay. Grove Depay 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. just, people just deploy it and just forget about it. But I think the important part is how much of the aggregates 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 MEV and trading bots. So that's contributing to the other side of the equation.

speaker-1: Still a lot of other contracts have to go if we are only at the 10%. Well, you mentioned about the privacy. I understand in ⁓ the three ecosystems, especially in Ethereum ecosystem, people care a lot about privacy. I wonder how Sourceify helps about the transparency, the user transparency. Do you think that at one point of time, even wallet can warn users when interacting with unverified contract?

speaker-0: Yeah, unfortunately. 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 ABI to be able to understand what it does. So. In general, think to be able to have an overview of the 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.

speaker-1: 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.

speaker-0: So I think a common misconception in verification is that a verified contract is safe. It is not. So a verification only open sources. So I sometimes wish we have a better name for this. 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. 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.

speaker-1: 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's proved able 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 EAPs or ERCs in general?

speaker-0: I would say we don't have that many EIPs or ERCs 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 data that sourceify and verify alliance is exporting is somewhat standardized. that everyone can make use of. We actually had an EIP around verification. It was for EOF. Eventually EOF 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's... we're mostly working on.

speaker-1: Right. We understand that EUF is not the part of current roadmap of Ethereum, but maybe in future if there is anything aligned, maybe we can see some proposals coming in. Well, talking about roadmap, I wonder what is the roadmap of Sourceify? How do we see the project progressing in the year of 2026 and specifically the role of AI? I understand you mentioned a little bit usage of LLMs for some basic queries. Could you maybe elaborate more on that?

speaker-0: Yeah, so first of all, we value working openly a lot in Sourceify and Argo and our roadmaps and progressives. We periodically share our roadmaps and progressives so you can see our 2025 look back and our roadmap in the Sourceify 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. So the chain coverage, as I said, we have pretty good coverage in Ethereum mainnet 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 clear signing efforts. We are developing the clear signing SDK for software wallets to be used. In short, clear signing, if I can give a summary. So as I said, we see bytes and hexes 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 SourceFY 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 of 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 sets that we have with this verified contracts to see how this can be useful for AI models for the EVM developers to be useful eventually.

speaker-1: 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 a 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 it is complimentary. And for a project like this, AI can do wonders here. Well, my next question in this section is if. Someone is listening right now and want to help her get involved. Where can they find the team?

speaker-0: 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 Sourceify.

speaker-1: 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. Sorsify in few words.

speaker-0: Source code verification, open source, open data.

speaker-1: biggest risk of unverified contracts.

speaker-0: Completely losing your money?

speaker-1: Verification should be optional or expected.

speaker-0: It has to be definitely expect.

speaker-1: Blocks Explorer versus Sourceify, what would be the key difference or the unique point that you want to mention?

speaker-0: Yes, Sourceify is source code verification only, so only the source contracts, but Block Explorer's index and keep track of the whole chain.

speaker-1: One myth about contract verification.

speaker-0: Yeah, it's not that if it's verified, it's safe, it's wrong.

speaker-1: Should Dow governance contract always be verified?

speaker-0: Yeah, absolutely. don't see that they will also have to be verified to be able to collaborate, let's say.

speaker-1: Is verification more important for users or developers?

speaker-0: 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.

speaker-1: one metrics that you would want to keep track of for the impact.

speaker-0: Definitely the contract coverage, number of contracts. And also, as I said, the other metric that we want to work on is how much of the transactions go through verified contracts.

speaker-1: The future of a smart contract transparency is.

speaker-0: open source.

speaker-1: Yeah, indeed. It's inevitable. It's going to be there. Yes. Well, thank you so much. It was great talking to you, Khan. In one sentence, if you have to summarize, sourceify.

speaker-0: It is fully open source and fully open data. Just verify everywhere, not in one place.

speaker-1: Aasim. That was great. It was lovely talking to you, Khan. And ⁓ 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 Sourceify is quietly bridging that gap and providing that infrastructure which actually can be used running on chain, verifying all these contracts. Thank you so much for your work and a congratulations to the entire team.

speaker-0: Thank you! Thanks for having me. It was a pleasure and great to be here and talk to everyone.

speaker-1: Dear listeners, if you are a developer, auditor or enterprise users, please check out your notes and learn more about this project. This is very important for upcoming days. We would want that Web3 to be a safer space for people to follow. And 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.