# Panel: Source Code Verification | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 45:36
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-XBYmL8ICFyQ
- YouTube: https://www.youtube.com/watch?v=XBYmL8ICFyQ

## Description

Source code verification is the basis of trustlessness and transparency in blockchains.
Many projects do source code verification but there hasn't been much collaboration and public interaction. The panel will bring members from the new collective "Verifier Alliance" together to create an open discussion.

Topics include open-data and open-source, standardization, future challenges like state and data growth, multichain, monetization, and financial sustainability

Speaker(s): Kirill Fedoseev, Kaan Uzdogan, Gary Thung, Giacomo Barbieri
Skill level: Beginner
Track: Developer Experience
Keywords: Developer Infrastructure, User Experience, blocks, explorer

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] all right hey everyone thanks for joining us today uh I'm Gary I work at Electric Capital uh I'm an engineer on the team uh and amongst other things I work on codaw which is a uh search engine for deployed smart contracts on eth mainnet and then a handful of other l2s uh today we're going to be talking about source code verification um briefly if uh you're not aware this is the process in which um the raw source code of a deployed smart contract is verified openly and that code is available for anyone else to verify to Fork uh you know to interact with uh we're going to we're going to go over this problem uh within the ecosystem and the challenges that we Face uh joining me today we have Joo from rout skin uh KH from sourcify and kol from block Scout so I'll hand it over to them to introduce themselves thank you Gary hi I'm I'm Jago Jack for everyone um I am ad of growth at rout scan we are the world's first unified multi-chain block Explorer for edms hi everyone um my name is Khan I working on sourcify uh sourcify is a decentralized and open source source code verification service he everyone my name is k I'm the head of research at blog Scout so blog Scout is an open source blockchain Explorer for evm networks and Beyond and yeah we've been building tools for verifying smart cont smart contracts at block Scout for many years and it's always been hard so let's discuss how to make it better awesome thanks guys uh to kick us off K's going to go over some slides uh a little technical intro describing what exactly goes on in source code verification process uh and the things that he's built yeah um to set the stage for the whole thing and in case not everyone's familiar with what exactly source code verification is and even if you know the concept in general to see what's going on behind the scenes and what we are all the projects are doing uh I wanted to show some visuals about this so what is source code verification one thing I want to emphasize is when you say verification it might be confused with formal verification formal verification is that different type of uh verification on programs here we are talking about the source code verification so the problem arises from the fact that the smart contract codes on blockchain lives in bytes in bite code in ones and zeros so essentially these are not human readable and from purely from a pure blockchain data perspective I if you want to look at the contract what what the contract does you get you'll be greeted with btes so you don't you won't be able to read it and for that reason what we need to look at is actually the source code um it can be solidity wiper F Huff any evm language when we're talking about ethereum and if you look at a smart contract code in this case I I come and show you a code from GitHub let's say a simple storage contract how do you really know this code I'm showing you is exactly is doing what it's supposed to do so I I show you this code oh at this address 0x123 here is the code in the end you are giving your money to this program um it might be doing something else than the code I'm showing so this process of making sure the code is actually the one that is deployed on chain is called source code verification yeah the how do you know this and so on if we dive into a bit how this works is let's say we have these source files installed my contract ownable erc20 what we do is we take these we feed them into the compiler let's say solity compiler in this case then we have a bunch of compiler settings uh the version the optimizer and so on and then this will give us we will compile it and this will give us a bite code a in this case I call recompiled bite code next we go on chain and take the ask for the bite code on chain let's say on ethereum network we get the bite code then we compare if these match so this is a simplification there are more details into this but overall this is how we do um the verification amazing uh to kick us off I want to dive into just the problems that we face in this uh and the importance of having open source code when it comes to blockchains um so my first question for you guys is why do we need to do this and like why is it important so um I think you know first kind was you know enough um accurate to say that the first thing is they actually are you know lending or spending money on that on those contracts so you kind of not maybe not you because maybe you're a user you're final user but someone uh some researcher or anyone can help you understand what I what is actually going on and that actually you know chat jpt you know does a some somewhat accurate job at understanding what's the what's in it and so basically it's to understand what you're putting yourself into and also it's about sharing what you did so that others you know since it's open source so that others can maybe um take inspiration from it and build on something better and for example I think there's a pretty good examp not not so good but like a successful example of this and it's um like solidly it was a project a DEX project called by um founded by cron and so solidly didn't really took off as it was planned but then it was forked and like upgraded from the guys at iodrome and badrum and now that deck is the most successful decks even I I guess now um over Unis swap so I think that is a successful case when you like share the contract and um you know we make a better product so I mean for me it's the basis of everything like um the whole promise of blockchains is U verifiability open source transparency and without the source code verification uh nothing happens you don't know what's going on you don't know what your code does even if you don't understand yourself the community and the Auditors should be um investigating this code for me I would personally would not touch a touch a contract that is not source code verified I it's really sad that still I think this is much better in ethereum ecosystem and ethereum related ecosystems but it's sad that there are a lot of let's say chains or projects that don't emphasize on this and I think this is in a way something we take for granted in the ethereum ecosystem yeah I agree with all that has been already said I can said that to me source code verification is also about security and um pretty much everyone assumes that as long as we build open source projects and the bite code is deployed on chain and is publicly available but as long as there are not that many people who can reason about this bite cod in its raw format so we can't and the gain this a lot of benefits from this been open sourced this been transparent as long as people cannot verify that this exact source code that they are seeing on GitHub that they can that they are able to review there that this is the exact source code copy that has been deployed maybe years ago I think um sorry I think there's another there's another thing that it's um uh I think it's just been researched and I think l2b made some um some some steps in that direction there is um like um a bit of research that we've been doing on rout scan since I don't know 2 three years and it's to understand how contracts inter like smart contract within a single dap interact with each other and now they interact with other DBS uh like I don't know in the defi summer there were a lot of yield optimizers that interacted with dexes to optimize on the liquidity pools or whatever and so um it is also a way to understand how the money is flowing and to predict how the money will flow and so to basically um have a better prediction of like the tvl and you know everything that defama is doing also but you can also do it better if you know know how money will flow because you know how how money is interacting like yeah how information is like um being interacted um you know between different smart contracts and different apps like about interfaces let's say yeah I see there's a lot of benefits to it seems pretty straightforward right you deploy your contract you get the buy code and then you like upload your source code to this thing and everyone wins I guess what are the problems that you guys are seeing uh and the products that you're building when it comes to source code verification so I guess um as the verifi alliance so just an intro about the verifi alliance I think I think we didn't no we didn't you have that yeah so so the very far Alliance is a joint uh initiative between um um sourcify block Scout route scan um also the consumers of as smart contracts Source codes and uh uh other block Explorer providers and um languages uh that wants to share wants to have a open database of um Source cont contracts so that's so that is for example easier for uh chains to switch from one Explorer to the other or for example to have um a unified you know um bucket of everything that uh no single provide data provider can actually uh provide you know and um and so what's the question yeah about the difficulties yes so uh one one of so we launched the verif alliance in E Denver I believe it was was ITC ITC yes it announced in E Denver yeah e Denver yeah and um so we still uh have some issues that I think KH and kol Al better suited to tell you about but one big thing is about coordination so when you're like a lot of people that basically you've never worked with each other before and you are working with each other with a like a with a with a strong alignment towards one thing um it's about also finding those other things that you may not be aligned with that maybe are um are are some issues and also another you know entity that is you know involved is Paradigm through Sam CZ so um so yeah there's a lot of a lot of people involved and um a lot of we had a lot of meetings and uh we also host by weekly on monthly meetings um to coordinate on that but um but we have some issues that I think yeah can and G can tell you better um yeah maybe I'll touch on the technical problems a bit um I also have some slides about that but in general the problem is um it's not always straightforward to match the code the onchain to the source code that you have there might be uh there are sometimes the bite code can become really sensitive and also the bite code is quite not not quite it's unstructured um it being unstructured is it's difficult to make sense of it and there are a lot of workarounds we need to do to match for example these were about more um rify Alliance but um so one problem I want to mention is the difference between creation bite code and runtime bite code so when we compile a contract we get two bite code outputs one is the runtime bite code um we in Source at least like calling it runtime and creation instead of bite code and deployed bite code you can see this is a this is an output from the solidity compiler here the bite code is the creation bite code and deployed bite code is the runtime bite code as we say um we call it creation and runtime because the creation bite code is the code that is executed to deploy this contract in this case the above one is the creation bite code and as you can see it contains the runtime bite code the what creation bite code entally does is execute the first half of this um program and then copy the runtime bite code at this address and the problem here is yes we get the creation bite code from the compiler but it is not as straightforward to get the creation bite code on chain we can get the runtime bite code from the RPC directly there is a e get code um RPC call to get the runtime bite code on chain but there is no RPC call to get the creation bite code so what we do at least in sourcify is we don't we don't index the chain so we are different than block explorers in that sense what we do is okay now we need to find the transaction that creat this contract then we look into this transactions payload if this contract is an external created by an eoa good then we get this payload compare it with the creation bite code everyone's happy if it is a factory though then things get tricky then you need to trace use the traces to like see the intermediate steps inside the evm to be able to get this creation bite code so I find this fact to be a centralizing force within the ecosystem and for that reason for example we are at least in sour i s side struggling a bit more um the other technical problem uh is that there are like Fields let's say inside the bite code that are like changeable for example in this case the compiler puts a placeholder for a address Library address and this needs to be modified inside the bite codes for that for that reason we call this Transformations uh Transformations are the set of changes you need to make to reach the onchain bite code from the recompiled bite code so these Constructor arguments immutable variables libraries CX these are um the changes that we need to look into the bite code technically so these can get tricky yeah to continue on this problem with unstructured bite code and the pain of getting the creation transaction I can also add that um I think that in general the space of verification of smart contracts lacks a lot of standardization so we have a bunch of different block explorers with a bunch of different apis that implemented in different uh formats Works slightly different maybe have different API routes and so on then we have different implementation of this verification logic which someone came up independently and there is no like a single spec that how you must exactly step by step verify the solidity of Viper contract then we have a bunch of different language and compilers that work completely differently have the different API have the different input output format so solidity Viper half and so on so I think that space can gain a lot by doing this standards and writing some specs and uh creating tests to cross test every and each of these apis uh implementation of verification Pipeline and stuff like that yeah and exactly this is the reason why we have the verify Alliance like this is in its Essence as Jak said this is a shared database I want to find the slides so this is a shared database with a shared database schema and in that sense this is like a shelling point for whole verification data but it's also a it's also an Avenue for collaboration like we I think learned quite a lot in technical terms between each other uh when we were trying to sync on everything and so far this has not been done so everyone was trying to solve the problem on their own and the knowledge was being also siloed like we don't know each what project was learning there and in this sense we want this um Alliance to be a knowledge sharing and yeah a shared knowledge platform as well yeah because it's also fragmented you know because uh if um you support some chains we support some chains you support some other chains then we have different learnings from how developers use and and and you know build their contracts and so there maybe some exceptions that we need to um that we need to use for example there are some trains that do not support Viper for example so for example we we didn't have to support Viber until a few months ago so that we didn't have that problem so yeah okay awesome Let's uh I have some questions about the verifire alliance um I think one common outcome of a lot of you know OSS and public goods projects is they kind of struggle to gain traction over time um interest waines kind of like the buzz waines and the projects kind of just fade out of uh you know the spotlight um I guess how are you guys thinking about spurring adoption of the verifier lines uh and keeping it running and alive so um so I believe sourcify is was inside the ethereum foundation so still you know we got some someone watching from there I believe then we also try to um do Outreach uh I believe this is a top down Outreach that we need to do so we try to get on board the optimism Avalanche and over time we will basically try to on board everyone um every chain that that we that we have relationship with with um so that a top down approach it see it it is actually more centralized because we want we would like to you know everyone to just autonomously um use this but I think standards um need to come down from a top down approach also because we have to I think we have to challenge the elephant in the room that is ether scan that um it's really another topown approach can we take questions oh yeah we could do live questions sure so I'm a user of your services we are building an online transaction debugger like a solidity Deb so and we need more information than you give us like okay sorry um so we are building a solidity debugger that you can use to debug online transactions and we are using your services because well ultimately we need the source code but we need more information than just the source code we also need for example The Source Maps um and actually KH here was quite helpful in designing a new API in in scify that would let us do that so the question is uh speaking of the verifier Alliance like you have this common database format is there also some ongoing effort to have a standard at the like web API level like because we are ultimately we are not talking directly to the database we are talking to the scify server or maybe to a block Scout server so and uh that just duplicates the amount of work that we have to do if there's no standardization on this level um I find a shared API goal a bit ambitious at this stage I ultimately of course want to see that um now the de facto API is The Ether scan API which also has its own flows including typos um but uh at this like I think this like shared API is definitely a ultimate goal of this Collective but at this stage I find it a bit ambitious if there are other opinions yeah know I mean I mean yesterday I I see there was just announ say seven-year planned for ethereum 3.0 so maybe we can just take a year or two to but yeah I believe eventually um you know we talked about having a for example a front end for the this database so it is is you know in the plan not not we don't know when but but um we would like to do that because it's also a really um useful way for researchers all over the world to Simply um manipulate you know the source code they have and I don't know find patterns maybe they can find some I don't know degression bugs or something I don't you know when when when data becomes available uh and everyone can do whatever they want um there are some like expected surprises that can happen so great thanks for the question oh we have another one how do you expect eof is going to change your validation and your verification um I haven't fully I don't have a full grasp yet maybe you guys have a better yeah I think in the short term it will make it even worse for us because we'll just have to support one more bite code format and one more contract format and just double the effort but in the long run I think it bring something to the table because now at the status quo the bite code format is unstructured and it's hard to reason about it but in eof there is like an idea of containers and um there is some static analysis you can do on these containers and I think it will make the verification a little bit easier to specify to standardize and to to verify it will will be harder to make mistakes during the implementation of this verification pipeline right so in the long run I think we'll benefit from it but yeah I agree I think the fact that the data will be separated from the code is going to thing make things a lot easier for all of us but the transition phase is obviously going to be a bit bumpy all right no more um I guess on that same note um you know one of the big problems with the way the compiler works and the evm works is you just kind of send this bite code it's like kind of gibberish almost uh I'm curious what like protocol level changes do you think should be made to help improve like the source code visibility and just the developer experience as well working with smart contracts um I think this was it is used to be a kind of a debate if this should be kind of included or insured in the protocol um I don't remember exactly but I guess we already decided um I'm not sure if it's like I don't think it's possible to have Smart contract um like the code the solidity code or Viper code inside the protocol I think it's more about improving the tooling to to do to continue this way I for me it's a bit difficult to have a protocol change for this and I don't think cordev will like it you know I remember um was um uh some time ago that I saw that there was an ERC in discussion about onchain audits M so that is something that for example ether Canan does uh off chain um and it may be something that you know it it won't change like drastically but it will enrich developer experience so I believe that's one thing and um yeah there like there are a few erc's that are like here and there are like trying to uh add few details about how um you you want to um manage contracts um and related things for example there's a u IRC that I just was looking know yesterday 7785 that it's about um having an onchain registry that it's going to deprecate the ethereum chain lists and that that could be something that you know if if there is an unchain registry and not a um a an offchain registry we could integrate that into the verifi alliance and have also a better way of um I don't know maybe discriminating contracts based on the on the specific um chain because for example there are contracts that are deployed on the deployer address on on the Genesis address on the L2 that is like deployer address and uh also there are also contracts that are deployed on the same U contract address on multiple chains so maybe we could do some some work around there I'm not really sure what but I see that there's some potential in uh enriching the developer experience for a L1 plus L2 ethereum future let's say yeah I also don't see how we can change something at the protocol level to benefit the verification ecosystem but I see that a lot can be done in the infrastructure part so in all the tooling Foundry did a good job and but I think we can go even further and to make it so that verification is done by default so that people don't have to think about API keys they don't have to think about different specific endpoints to a certain block Explorer they don't have to reite this verification multiple times to verify their contracts on multiple sources and stuff like that then we can also to push um from the user side and from the stuff like wallets so that wallets show different warnings for example to users if they interacting with the unverified contracts and then if users care enough about such warnings maybe they can push for the protocols to verify their contracts and we'll see this increase in the number uh of verified contracts in the in the rate and the speed of how they are verified um maybe not on the protocol level but I'll throw this in a bit uh at this point is one thing maybe worth exploring is a bit ZK in this sense um this is also a idea that we are exploring uh in sourcify and trying to understand what what's possible if you have knowledge please reach out to us maybe make contracts self verifiable like if you kind of zky the compiler and you put the proof on chain and then without even needing a verifier like us you can prove yourself that okay this the output of the compiler from this source code is this proof maybe oh you need you mean like verify it on your own like ZK proof in the contract on chain and and trying to I don't know match it offline yes sort of you don't need to run a Full Compilation you can maybe have a self-evident proof that the source code is actually matching but at the end it's not Poss I don't see it's possible to put the source code inside the protocol or in any way but maybe there's some exploration in in ZK here just throwing this at this stage or or maybe since we're like I don't know saying things that theoretically possible thinking just as we have da layer you know data availability layers we could have Smart source code layers like you can post data whatever and then a de creation takes you can just post the source code on a on a on a different layer than maybe I don't know Celestial so is like I don't know targeting one one gigabyte blocks so maybe they will have enough uh block space to also host tens of SC Source codes in a block yeah I think sourcify does a good job here with the automatic fetching of source code from ipfs as far as I remember so as long as the developer or someone else puts this source code blob somewhere on ipfs and the sourcify is able to detect automatically and match by driving the metadata from the deployed by qu so here the people might not even think about this idea that they need to go somewhere and verify their contracts yeah um that's that was I think the idea with the ipfs hash if you don't know I added some stuff about that here um there has been special dis solity compiler tried to work around this by putting an ipfs hash of let's say the compilation uh so the compiler by default adds appens this by string at the end of the contract and this is an ipfs hash to a file called metadata this contains all the information about the compilation and ABI and how to interface with this contract so this is still done by the compiler and this the idea here was to work around this um the idea is to have all the contract data on ipfs and you can fet yourself and verify but then turns out this is both a bug and a feature because then this this becomes quite sensitive and I think the community is divided in this front if this is a if this is something we want to have or not and at souri we are supporting this but still it's has been quite unclear uh how to go about with this we have a question the what's the push back against the um yeah I can rephrase the question what is the push back against this the thing is um the metadata file is a Json file that for example has the source file paths and these paths can be quite sensitive so if you put your source file to another path then give it to a compiler again the reproducibility of the whole thing reduces um that means and also especially if you are using a create two contract then the whole bite code changes which in turn changes the contract address that's one reason I want to move on to a question more about the ecosystem um I think that the the the way that the compilation and contract creation is done is uh kind of led to this world where you know you guys mentioned it like we improve the tooling around the process we build tooling to do the verification um and that's kind of led to um ether scan being pretty much the deao place that uh almost all the source code is verified first um I'm curious for Joo and curol you guys work at UH block explorers um why should ether scan give this data up it's kind of the biggest Mo I think in their business um it's like one of the only sources of private data within like crypto um so yeah I'm just curious uh your guys' thoughts on that I have a very simple answer for this it's because they have they index ethereum so they should at least a little bit align with the ethereum EOS that is of being open source and collaborative and inclusive yet they are not so um so yeah that's um like I'm not much of a technical person so I I have degree inpr science but I'm not much of a technical person but I use my technical skills to like try to convince as many chains as possible to avoid using E3 scan and instead uh use our Explorer and so far it went a bit well not really really really good as I hoped because I'm super ambitious about this but we we transitioned um two explorers from from from ather scan that is um Boba scan and and snow trace and we also uh convinced a few chains to use us instead of V to scan when they were chosing about the Explorer provider because we were cheaper and we're faster and we're also more inclined to open- Source projects so I believe when when and uh actually Sam CZ from Paradigm um dm'd me about um you know the opportunity of the verify Alliance back in November 23 um I was really excited about it because it is actually what we need to do um because we the thing is it's okay to compete but it's not okay to lock in so um and they have a really bad way of not giving back anything so and this is something that I tell everyone because this is the biggest issue that we've had and and I think everyone needs to know this so when we transition snow Trace snow TR snow Trace you know the Avalanche C chain Explorer um C chain had one around 1.5 million contracts between mainnet and testnet so per the contract with the Avalanche foundation and aval laabs they were you know the contracts are of the chain so so the source codes are of the chain that they're in so they had to scrape like they had to like export their contracts but yes they did they send us a dump of 1.5 th000 contracts 99.9% less than what we asked so we had to find other ways to to import those and eventually and eventually no but but eventually uh a lot of you know we were also integrated a lot of tooling hard that Foundry so everything would you know became much easier but the thing is they really were not collaborative at all and I hear a lot of a lot of chains that are simply and they say to me we have the hands tied we cannot change the block Explorer because of this this and that maybe someone I don't know um for example optimism optimism is under e scan optimism. Ean Ando if they even change one letter that's going to be a pain in the ass for developers to just change the one letter across thousands of lines of codes and repos and whatever so that's that's a huge lock in so they need to stay with that and to pay those money and on average a chain pays from1 to $2 million a year so that's really bad can please tell tell something yeah I agree with everything why should you not don't have much to add but um yeah I think that if is Canan even cares about the their clients and their users that they must give up their contracts because this not only about sharing with this contracts with the other block explorers and their competitors or whatever but for sure sharing those contracts and importing them automatically in different tools improves the security for the users who are trusting their funds and uh their life with the the blockchains that are supported by eer scan right because if these contracts are automatically available on public data sets and can be automatically imported in different static analysis tool or security analysis tool or different researchers and security analysts can do some research and find some buck in those contracts without manually importing contracts one by one from eer scan right then the security for all users for all ether scan and all blockchain users will be greatly improved so if ether scan carries about that then I think the answer is obvious yeah I can speak more from a Pure Source Code verification side because we are not a block Explorer um um so I think of course it C provides a lot of value provided a lot of value to the ecosystem but it's um and also like we I at least personally are am in touch with quite a lot of ether scam people they're really nice people I like collaborating with them but ether scan people is of course different than ether scan as the entity um so I kind of want to approach this in two sides one is uh I think we need to change the tooling to break this Monopoly at the pipeline at when the contract at the contract pipeline one example we want we did was uh the remix plugin we worked on a unified remix plugin and now the contract verification on remix is done on a single plug-in that yeah sends uh contracts to everywhere I don't see why would anyone want to verify at ether scan only and not on everywhere like because one you want to share data everywhere everywhere you want your contract to be verified by everyone if it's not verified by someone then there's a problem obviously um so we at sourcify trying to push the ecosystem in this direction and for that reason we came up with the remix plug-in that has sortify eer scan block Scout and Route scan so you can easily um if we can run the video you just compile the contract uh give the address give the chain yeah and then uh it it gets verified everywhere so this is one part of it attack the problem at the pipeline before the contract is being sent and the other part is I see is uh basically Community pressure uh I think developer Community pressure developer Community pressure yeah yeah that's the single thing that yeah I I think this is like the elephant in the room not being talked in the ecosystem basically the whole like this only gets recognition when ether scan goes down for a couple minutes and we're like oh my God like ether scan is down we can't look at the chain data uh maybe it seems like the chain is down yeah and it seems like the chain is down and maybe we should do something about it and be loud about it the first thing is I think um a lot of trains have it but not all is have two block explorers at least this is like a normal avoiding single point of failure situation like you need to have two things cuz if one get you know breaks the other will will function you know and it's a simple you know security 101 and um so yeah it's even better if one of those two explorers his open source yes yeah that's uh along the lines of the next question I want to ask what um I guess what do you think it's missing from the industry or the ecosystem to add more incentive for teams to verify their source code I think some of the ideas that we've kind of thought of are you know some social pressure some badges um yeah like have you guys thought about anything that could add more incentive for teams to actually do this shame yeah and I believe right now there are a lot of um uh rules in place but only for uh tokens so right now when you um when you deploy a token and I don't know shitcoin or whatever you need to verify it otherwise that will not be verified and the Dex screener or Dex tools or whatever do not have or other like token security tools the not that cannot read the contract and it cannot tell like if the supply is locked or whatever and so nobody will buy your token if they don't have some security guarantees but that only happens with um year C20 tokens I haven't seen this behavior for nfts or for other types of contracts and we are now seeing a lot of non-financial applications being built like social and so on and I do not see the pressure to verify those types of contracts honestly yeah for me it's really simple um if you if a contract is not verified don't interact with it if you had a wallet tell your user not to interact with this contract I mean it's I think it's pretty straightforward we've been telling this all the time and unfortunately we haven't really seen wallet teams implementing this yet uh we have a question from the audience is there any plans for the verifier lines to verify other languages such as rust or CYO um I think maybe it's good to clarify what verify Alliance does here verify Alliance is not a single verifier we are different verifiers so we can separately start verifying rust or Kyra and start writing in the database ourselves but the verifier Alliance does not verify something so if for example block Scout tomorrow starts starts supporting rust then it's support it will be supported in verifier Alliance as well so it's about the verifiers not the alliance itself and I would say that it's a really big defocus personally but I think also for Block Scout maybe because it's you know evm um deployments are really flexible and replicable while don't rust I mean maybe you're talking about Cosmo wasm or Solana you know and and kaido kaido may be kaido may be one of the you know um because it's like extension of ethereum so it might make sense um but I'm anticipating that since there will be a lot of alt VMS built on ethereum then there will be a lot of I don't know Aztec I think there was no there there were a lot of um pring languages being built on top of etherum fuel for example um and so yeah in the future yes but it takes time yeah I mean um I forgot to say we are more evm focused at this stage but if you have contract data um still uh just approach us then we can see maybe not today but tomorrow what we can do about it I think not only evm contract data should be public and easily accessible but all contract data all right thank you guys so much for your time and uh thank you all for joining us for this panel today uh that wraps up our time here thank you [Applause] thanks thank you very much for the panel fellas so that was the the end of uh the last session of the day thank you very much for coming and we look forward to welcoming you in this room tomorrow all right