How EVVM is Solving Ethereum's Gas & Privacy Problem (Demo)

Ecosystem Project Demo (EPD) · 20 Apr 2026 · 1:02:29

German Abal, Arturo and jistro demonstrate EVVM, the Ethereum Virtual Virtual Machine, which runs virtual blockchains inside smart contracts. They cover gasless transactions, ZK and FHE privacy layers, compliance use cases and a comparison with traditional L2s, with live CLI and vault demos hosted by Pooja Ranjan.

Speakers

Topics

From Ecosystem Project Demo (EPD), hosted by ECH Institute.

Transcript

Probably will be the future of the identity and a new way to make a KYC [music] and AML. Sometimes they can do some abstraction, but these very particular implementations on EVBM is always abstracted natively. >> One thing we try to create a question is the gas fees. >> So, in the infra aspect, a traditional blockchain or L2 needs validators, nodes devops [music] that is one of the most important part of the blockchains. On the EVBM, zero. It's everything inherited from the [music] host. No infrastructure is needed.

>> I think it's the app store for blockchain. Basically. >> Ethereum infrastructure by the offer and demand game that is paying us, getting incentives, and well, be a liner is what is alive for decentralization, permissionless, and deterministic. So, for us [music] is vertical scalability. >> [music] [music] >> Ethereum is often referred to as public infrastructure.

>> [music] >> Imagine Ethereum as a city where we are going to use the governance, the police, the and roads, and things like that to set up our business there. And today we are going to talk about a project which actually kind of gives us [music] a picture about how this will come into reality if we are using Web3 and Ethereum as public infrastructure. Welcome back to Ecosystem Project [music] Demo. This is episode 31. Today I'm joined by three developers [music] of Project EVBM, Ethereum Virtual Virtual Machine, [music] and we are going to learn about how this will look like in real world. Welcome, Kevin, Arman, and Arturo

to ecosystem project demo. >> [music] >> Thank you, Bohar, for having us. >> Well, we would love to hear about the project. I'm sure there are a lot to talk about, and I understand there is a presentation as well as demo. But, before we get into the project details, it would be lovely to hear from all three of you about yourself, the way you entered the Web3 ecosystem, and how you joined together to come up with this project. So, let's start with a brief introduction. >> Okay. Myself, I entered to the ecosystem of blockchain in 2009 checking the security of Bitcoin, the nodes, and the cryptography.

Uh later on, I saw that was very secure and and no possibilities to hack it as a protocol, as a consensus. So, I continued with Ethereum after a few years in 2015 when I noticed about it and got information, I started checking something on the smart contracts. And then, uh I continue with my things on on internet in general. And in 2022, I participated in an ETHGlobal hackathon in Mexico, and that made me very passionate about solving problems on on infra, on protocols, and and Ethereum itself. And from that moment, I didn't stop developing on Ethereum.

>> I'm Arturo. I've been somewhere in software development. I have been 12 years working on on software engineering, uh designs on solutions. And I start working on saving circles solution that after some researching, we find blockchain like Ethereum. Um we start find some features that we need for this technology to help people in LatAm mainly uh making the saving circles in a decentralized way. And that I met uh the team Herman in Def Con Colombia and I met Gistro I think like two or three hackathons after that. So we start

work together. We presented the MVP of this in Waterloo but we are going to give you more details. >> So yeah, my name is Gistro also known as Kevin. Well, I was in software development like formally two years but I was getting knowledge from university. My path to Ethereum begins with a simple thesis using artificial intelligence just for track some packages and after figuring out like okay, that's good using artificial intelligence for that but what if some data or some database going to be corrupted so I figured out why

don't use Ethereum just for that. And after reading about Ethereum, checking about Ethereum, I literally fell in love with with that and began my path. I met Herman like three years ago in if I remember correctly it was in a hackathon and Arturo I met him the same like three years ago in a hackathons. Literally I meet both in the same hackathon. >> I mean this is the beauty of this ecosystem we meet each other in different hackathons events and we come together and start building together. I met Herman for the first time in Argentina though we know each other for

quite some time. He had been an active EIP author so had an opportunity to interact with him online but that was our first meeting there. And I think in this EIP summit that we organized back in Argentina I introduced the entire group with saying that everything in Ethereum starts with what if like just to mention that what if this happens. So, I'm so happy to learn how you all came together and I feel that this is inspirational for people to come together. We are going to different places and meeting new people. There could be new connection and there could be birth of some new project. So, thank you all for joining us here today. And I understand there's a presentation. So,

without further ado, let's kick into the presentation. >> Well, thank you for for this invitation. We are very happy to be presenting EVVM to you and and to to the all the audience and the the unit developers and community. EVVM is Ethereum virtual virtual machines. It's virtual set blockchains for Ethereum looking for vertical scalability. So, what can't be done on EVM today? This is very important. There is a typo there, sorry. Chain compliance means that the whole chain, Ethereum itself, base, Arbitrum, other EVMs can't be compliance as a whole, right? Every chain has uh

their own compliance and it's fine for different services. An example, Circle is compliance with the USDC in their way, so they can do blacklisting and they can freeze some accounts, USDT as well. But the whole chain itself is not compliance. What we can do with the EVVM that we will look later is that we can make a part of the chain compliance. Token incompatibilities. An example, ERC-402 that to be used by any service, it has to be wrapped or it has to be a token launched respecting some EAB that supports a paymaster and a and a few other functionalities. Complex privacy

solutions, we know that when we talk about privacy there is a lot of signatures involved. There is a lot of of different protocols that we need to audit. And later, sadly, there is many drained protocols and treasuries. Post-quantum resistance that now is becoming a thing after the CK concerns. Now we are talking about quantum resistance on the signatures. Gas and account abstraction is also a thing that continue without a global solution. And the multi-chain composability that is a everyday problem that we are facing.

Why am I'm listing these points? Because EVBM solves all of them. So, EVBM solves all of these problems. And we feel that is also the future for stablecoins and agents that is the topic for this 2026. What brings EVBM? In the EVBM, that the solution is basically smart contracts that are deployed within a blockchain, emulated all the functionality, and having a virtual RPC on the core contract. This means that the transactions goes into the chain directly or through a relayer that is an external owner account. And the payload inside the transactions is

the EVBM transaction. So, there is where the abstraction starts. This means that everything that is executed on a private environment, a virtual set blockchain, is carried to this deployment in a transaction itself. In this moment, the user doesn't need a gas because the gas is paid by the one that is relaying this transaction, that doesn't matter who is. Everything all the magics will happen inside the EVBM. This is a gasless UX completely because now the accounts can sign transactions completely off-chain. They don't need to connect to an PC and they can interact freely inside the EVBM. Doesn't matter if they are using CK, full homomorphic

encryption, a normal transaction, registering a name, or even through the abstractor service, they can interact with the whole ecosystem doing composability. And there is well, the full composability item comes here. This means that now if you want to use the typical account abstraction, you can make the call as you usually do from an external lunar account or through a sponsor. This is fine. Well, using the EVBM, you can also do it, but you don't need to configure it. You can do your own call, you can control your own account abstraction contract with your own signatures, but other person can bring

the transaction to your EVBM and the EVBM will do the rest of the execution. To be more clear on this and and more more targeted to devs, this means a full abstraction. So, the whole blockchain is abstracted. So, we have to forget completely about gas. Believe me now and check it later, but gas doesn't exist anymore if we use an EVBM. CK privacy and full homomorphic encryption for confidentiality. Arthur will show later on this demo how we can add CK bolts to create services with full privacy for users to send tokens, receive them, split them in different transactions

without revealing who are involved in these transactions. This could be a little like a controversial because these are the type of activities that are not very well seen by governments. But what happens if we do a KYC and AML to our EVM in example a bank. A bank that wants to bring privacy for their users but want to be public for the interbank experiences or for the funds to be used outside their scope. They can deploy an EVM.

This EVM can be KYC'd AML or with EAP 8004. That is fun because I sent the the ERC 8003. So every time I see 8004, I I remember that was one one after. It's just a a note in the middle anecdotic. But well, imagine that that we were a bank and today we want to bring our users on chain and we want to give them privacy and we want to offer products for the whole ecosystem as well as give our users to have the chance to use Ave, Uniswap, and any other deployed protocols.

Well, we can deploy an EVM. We give this opportunity to all our users from our institution. We can be compliance because all the addresses that are accepted to interact in our EVM ecosystem are KYC'd. So we can have a secret beside. They can use secret. They can have a tornado cash inside the EVM because this is legal. They are compliance. And to go outside, they can also do. So you can have these private environments in Ethereum that will be small parts of Ethereum base Arbitrum, any other EVM that are compliance. And what happens outside the

walls is configurable. And they will also have a native X 402 because paymaster and Axiom Noses are part natively for the EVM structure itself and architecture. And for the post-quantum resistance, we had today meeting with the Lucerne University in Switzerland. And we already have been talking with Qubit Network that they are both on the on the post-quantum security research. And we agreed to start working in the quantum resistant EVBM. And we have a plan.

And thanks to the abstraction that EVBMs bring, we can start using with our name service that is upgradeable and resolving on chain was on quantum resistant accounts ready to use in the smart contract level. So, it's about execution level in 2 months or 3 months at most. This doesn't bring quantum resistant to the EVM itself because the nodes and part of the consensus is still using the old cryptography. But, to operate on chain users could be using an EVBM to interact within the whole ecosystem using their quantum resistant

signatures. And this is very important because it's more secure that don't have it. >> So, in this part well, as any blockchain is completely yours. So, your rules, your environment. So, you can configure it how the interaction happen inside the EVBM. So, if you want to a little bit closer or maybe a little bit open or maybe some other system can interact with this EVBM you can do it completely. And you had compatibility with all the host protocols. So, in comparison with the some L2s or L1s that all the protocols need to be inside of the blockchains. And

well, all the liquidity are depending of the those interactions. With EVBM, you can choose any blockchain that you want, maybe I don't know, like Ethereum mainnet or maybe Arbitrum, and get all the liquidity from this host blockchain to your beta blockchain. >> Here we have an example of the architecture that is is the most desired from bank institutions, and in fact it's a request. We have an agreement with a company that is called NTT Data from Japan that they are supporting us in the way to find bank institutions to implementations. They already gave a talk about EVBM in the

decentralized trust event from Linux Foundation in New Jersey on January of this year about EVBM. And we we deployed a Hyperledger Visu configuration with a consortium of EVBMs bridging to Ethereum mainnet for offering their products and get alias extract a liquidity to be operative on the on their private environment and then throw it back with another product. So, this is the the standard implementation that it was proposed by Arturo.

And that basically is a bank that has a private communication with a trusted execution environment interface. And on that interface there is happening full homomorphic encryption communication that gives confidentiality to interact with the EVBM ecosystem for the users of the bank. And then the users from the blockchain in general can have a configurable access as Kevin said before to the EVBM to come and go. At same this happened with the CK bolts. The previous configuration I was talking is very very similar. The only thing is that the the proofs will be generated also in a trusted execution environment interface. And and well, Arturo will show in in in the demo that that is

coming. >> Yes, so starting from understand that privacy is by layers. We are working with let's say two types of privacy like confidentiality from fully homomorphic encryption and the probable computation with this selective disclosure data with CK proofs. So we we are combining this. We also understand that we are combining these expensive systems, but we are trying to improve the the efficiency. So we start to doing basically about it's it's just like the normal vault that that you already know.

This vault is receiving deposits in tokens in ERC-20s. We generate a proof to just prove that deposit was made in the in the vault with ciphertext with our fully homomorphic encryption. We are encrypted the amounts of these receipts basically. Also, we are planning to improve the architecture encrypted the the root of of each deposit in the Merkle tree. So here we we take this approach because Vitalik was mentioning some stuffs about privacy and transparency, how they this ability to make privacy was like

necessary for the users and optionally for enterprises basically. So here is more about how we are using privacy for users. We also select fully homomorphic encryption because we find that it's more composable with other solutions with other DeFi solutions that are ready in the market more than CK. So because we are not trying to redesign every protocol or everything in on the chain because also EVBM is composable with other protocols, we choose this this way. But, also we add a compliance layer that is basically doing a KYC and AML for institutions uh because this is

important. The the proof is the like uh privacy pools is doing uh the their own system to also try to make compliant stuff. So, how this works? In the UX side, we abstract everything because EVBM has this ability to to help us that it's more easy for the user using a CK applications with no need to understand like uh hard concepts or heavy concepts also. So, we have relayers that it's basically a fisher. We have our users.

So, the the relayer lives in the EVBM, is connected, and the user sends transaction, the fisher or relayer takes this transaction. We We are checking as a middleware the KYC part, the KYC layer. If the user pass this this KYC or is valid for for this AML stuff and compliance layer, we deposit in the CK vault to start to giving privacy, giving private transactions, private movements, private payments also for this um feature that is a splitting notes basically. So, also in the EVBM two parts, in the DeFi part, we are integrating with Uniswap and Aave in in a private way as I

mentioned before uh for fully homomorphic encryption. So, we can do these encrypted amounts and encrypted movements. So, a little bit deeper, if the user is not registered or is not passing the KYC, it's basically a boolean true or false, uh the KYC of the transaction, the interaction with our protocol in in this version, in the CK version, is denied. In case that the KYC is is passing, we generate a proof of the deposit as I mentioned before and when the user try to make the withdrawal we are checking the proofs. Also, we are checking the compliance layer that is because today I I cannot be on the OFAC list on

on blacklisted or sanctioned a country but tomorrow probably so we are checking in every transaction that the user is trying to do this compliance layer to to try to avoid breaking some regulations some rules. The user take that we are using is the KYC module for the EVBM. We are using Noir for generate the CK circuits with this verifier that it's generated with Ultra Plonk and Ultra Honk proving systems and also fully homomorphic encryption that is not there but we are also using it.

>> So. Right now we are deploying in EVBM. We format the integration. So, this is a simple process is using using a CLI so you can configurate in literally minutes your own EVBM instance in every chain you want. So, I'm going to skip a little bit in the deployment part. And right now we had pre-configurate our EVBM and after this we had all verified contracts and we get our EVBM.

>> It's interesting to point that we have a CLI deployer and you can deploy your own EVBM in 1 minute literally with this tool and this is very interesting and it lets you choose which chain do you want to deploy on and also verifies the contracts automatically for you. >> So, right now we are preparing the contracts for the CK integration. It is a simple giant deploy and using our staking core and also our admin address.

So, we can deploy a CK bolt in again, literally minutes. For now, we are seeing the deployment. The compiling part. And I'm going to skip a little bit. So, if you see right this right there is complete deployment. So, after this, we use a simple example. One is a deposit into the into the pool.

We can add our commitment. We confirm that. All the signatures for that service. And immediately making a deposit for our CK bolt. After this, if you have the the commitment, you can make deposits, even split deposits, just for uh different contracts you want. So, right now we're making a a deposit, a split deposit.

I'm going to skip a little bit. And yeah, we made the split for various address. I'm going to skip a little bit, and if you want, we can withdraw all the uh the tokens for the bolt using again, uh these type of proofs. >> Here it is important to note that the all the transactions, as you've seen, were abstracted because the UI was only asking for signatures, but never for a transactional chain. And this is one of the capabilities that the EVBM brings to the to the wall ecosystem on the EVM. The transactions, the users

doesn't need to transact anymore with the blockchains itself. >> Exactly. The end user doesn't need to care about uh the gas the gas fees all all the stuff is just completely abstracted. So, they only need a a simple signature if using ERC-1155 and send it out to any place. If you want, maybe an API, maybe radio signals, uh or maybe just a simple message through Telegram, it's can be possible. Any uh medium you can send message, you can think as a simple feature. That's we call the nodes to abstract all the transactions. See?

You can see it's all the withdrawing and all the deposits. So, it's sim- it's just simple and and easy. >> So, why EVBM is cheaper? Why EVBM exists? So, in the infra aspect, a traditional blockchain or L2 needs validators, nodes, DevOps, incentives, that is one of the most important part of the blockchains. On the EVBM, zero. It everything inherited from the host. No infrastructure is needed. If you want to add some nodes to the sharding execution, to the virtual sequencers, or other kind of configuration, it's good. It's up to you, and we bring a lot of extra value, but to have it is not needed at all.

Deployment time, 3 to 12 months to have a testnet, to to test all your configurations, uh your different nodes, etc. In EVBM, minutes. Just one command, as Kevin showed. Initial cost for having a traditional blockchain L2, 500k to 2 million. This is very arbitrary, but but is very very costly. And in EVBM, only the customizations because this is open source and is free to use. We have now a license that is free for personal and academic purposes and research purposes, not commercial, but we are going to open it because we think that is a way to make this grow widely adopted and also

the community will be very very successful if we do that and and we think it's the way. At the end of the day, we are open source believers and we were feeling bad to have this a commercial license. I don't know how to explain it, but but now we will feel more comfortable with ourselves as well. The maintenance, there is a a maintenance cost on on any traditional blockchain and L2s. And on the EVBM will be only more customizations and changes. On the security side, a traditional blockchain L2 is constantly receiving audits, they're giving bounties continuously. And on EVBM, all this is inherited and then you can do small audits on the way that you are

adding more code or you want to check if if everything continues good. And the gas for users in traditional blockchains L2 is always required. Yes, sometimes they can do some abstraction, but these very particular implementations. On EVBM is always abstracted natively. So, here is a little of the progress. I think Kevin, can you explain a little of of what what's happening and how this happened? >> So, yeah. Right now, we had EVBM deployed in plus two chain chains. So, you can see like in this example like base, Arbitrum Monad Mantle Celo.

Uh we have EVBN uh 402. Uh it is a requirement the middleware for uh all AI agents. And [snorts] we had a fee of confidential accounting for Ethereum, a gasless UI payments app for called it by agent. Agent IDs for payments, so you don't need to know about any address, just a username. Uh we have a Hyperledger EVBN Besu, private consortium for banks with trust in Unitarians. So, if you want to go send all the liquidity from Ethereum, you can get it in a private instance.

And we had gasless on-chain governance for boring, too. >> Uh do you want to show the demo for the X402 Kevin? >> Uh yeah, I can show you. Okay. So, I'm going back a little bit. So, this is a simple front-end example, so to be more uh simple. All right. Now, we are connected to our wallet. And we authorize the payment, so if you can see, I'm going to stop right there. So, they need a requirement, so they use the uh 402 error, and they want to set amount, the amount of token the token they want to use and

they want to send and the timeout. So, if you can see, if we are AI agent, we need to send this signature request to the user to say, "Okay, I need to approve that type payment to continue this uh transaction." Why we need this? So, sometimes AI can be a little bit problematic, more in hallucinations part. So, if you let a AI agent alone, maybe they're going to send a lot of money because they say like, "Okay, that's good because I hallucinated that. So, with EVBN you have the more secure part to verify if this transaction going to be correct or maybe it's a hallucination by an AI.

So, uh right now we are getting the payment required as you can see, we get the status and all the inputs necessary to execute the EVBN with X42. I'm going to skip some parts. artists. So, after this we authorize and we confirm the payment and if it's done it's going to send you a a simple message for the payment action. If it was correct, obviously we're going to show like this and if it's correct, we're going to show a error for this.

So, and again can be more beneficial to use this and the user can be more beneficial because they had a more secure pathway to execute all the transactions. >> Here is also very interesting uh because as you see, we didn't request again for gas to the users and this means that agents neither has to have gas. So, now you can have a paymaster that doesn't need to be registered because anyone can sponsor these transactions. So, they can bill after it in a monthly free basis or or there could be a wallet with gas specifically for all your agents setup.

So, you can sponsor this this gas for all your agents without needed needing to do a configuration. Because doesn't matter who is bringing your transactions on chain. If you want, you can restrict it. You can restrict in the EVBN the transactions by transaction origin, that is who is submitting the transaction to the blockchain, the first one in the chain in the chain of of events to submit, or you can also restrict it to message sender, that is the last one. This means that you can also restrict the transactions to be executed on chain by a specific contract, and this is very good for DeFi. In the DeFi example, when we want to have an order, a limit order, we have to do a staking,

we have to authorize a third-party contract to access to our tokens. If we do a staking, we are freezing our money. If we are authorizing a third-party contract to use our tokens, we are in a post potential rabbit hole of security that will end on our loss of tokens. With EVBM, we can pre-sign a transaction of our limit order to be executed as it is, and sign in the message sender field the address of the contract that is going to execute it, that is the DeFi contract.

So, this contract that is also very interesting can be stored on chain our transaction because no one can execute it. Using asynchronous nonces, it will not also cause any damage to our journey on the on the blockchain because we put an asynchronous nonce knows that we are not going to use except for this. We put the message sender, the contract that is doing the DeFi, and then this transaction will be stored on chain by the contract, and only a trigger will execute it by the contract because nobody else can execute it because it will get reverted by the core contract of the EVBM because we will not match the the message sender to the contract, and if this happens correctly, the

contract will be able to execute it. Of course, the contract will have to check if we have funds first to avoid a revert and make a transaction that will be not worthy for the incentive that has for the one that is executed this to activate it at chain. But the the the nice part is that we didn't have to authorize the username of any token and we didn't have to stake anything. And this opens the possibility to many many many other use cases. The possibility to to give contracts our transactions not off-chain actors, on-chain actors is something that is not possible in other way on Ethereum today without staking or without failing in in risk of

authorizing our token splits. And then to finish our presentation, for this 2026, we think that the ecosystem is Ethereum and the stablecoins and agents are ready to ship. I don't know if Kevin if you want to explain a little more of of our suite of solutions that EVM has. >> Yeah. So, right now, as I say Herman, the ecosystem of Ethereum our stablecoins our agents ready to ship. So, we have a pretty good suite for all stablecoins and agents needed.

So, >> [snorts] >> you can integrate with EVM, make your own EVM just for agents. Maybe you want to make a a simple closed ecosystem for your own agents or maybe like a mold book. For example, instead of have your own Facebook for your agents, you can have your own blockchain for your agents. We have yield generation. So, any stake doing inside EVM can generate yield. This is good for stablecoins or even banks. They want to make more improvements about the yield generations. And you can generate your own sandbox. So, you can use APIs and we can to test it out inside the EVBM to

see how it's going to be. And if you want to implement another EAP, it's just simple as pointing out of the contract and that's it. And we had a QR EVBM. So, for banks or even stable coins, this is a very way to execute. >> We have also ready for for having for the developers a scaffold EVBM. And we have the CLI deployer. We have a a boiler plate that is ready. We have a coffee EVBM is called that is a full example of a deployment of a store using EVBM for payments. And also the X 402 implementation is is is complete and is ready. And the CK EVBM implementation is

also ready in the repo for cloning. The CLI deployer, of course. So, uh there is also a EVBM GS library that uh is type scripted. So, it's it's very interesting uh for for any developer to do a feature or a relayer or an implementation on apps or their own contracts. Also, examples on contract beta service. Service are the other contracts that interacts in in among the EVBM ecosystem.

And there is a full tokenomics plant inside that you can activate it and is using rewards for the features and the actors that are helping on the execution of these transactions uh that they should be doing staking. So, it's a compromise also to to the layer and they will get the yield generated by the treasury where the all the tokens are deposited to use inside. It's a little complex. It's a whole ecosystem. So, for a call it's is is difficult to to explain everything. And and I hope uh it's clear for for the audience and the people that that is hearing us, but we're all always open to to talk more about this, to do more chapters, and to also talk in

another podcast or or or spaces that we get invited. And also, we can have calls for clarifying everything. So, thank you for for for this opportunity. I would like to know if if you have more questions for us, and and if you want to to resume this conversation in in outside the presentations, please let us know. And and thank you. >> Thank you you all. Of course, there was a lot to take in, and I can definitely see room for having another version of it, like another episode of this particular project. There's a lot of ingredient of a successful ecosystem. You talked about

vertical scalability. You talked about X402, post-quantum resistance, and there is um this account abstraction, the basic concept behind it. It's a lot of things going on, and I'm hoping that it will be really good project. Curious if it is already in mainnet, or are we still in the testnet phase? >> Our contracts are ready to deploy be deployed anywhere, but we are about to start. We we were quoting right now the audits from from very very known and and formal auditors on the ecosystem prior to push or or to incentivize devs to deploy this on public mainnets. So,

now the CLI offers you only to deploy on testnets. For security reasons, we want to be responsible with this. We want to to be committed with the security of Ethereum. So, we are improving the security. We don't want to make it worse. So, before making something that will be widely adopted if in the best case, we need to warranty the minimal commitment from our side that is formal audit. So, after this formal audit that we think we will happen and and take end of process by July, maybe August. Maybe early. Who knows?

We are going to promote it to to be adopted for minutes. But, the product itself is ready. The code is just improving on services, improving on more more things in things to make it ready. >> So, currently it is like under commercial license as it was mentioned. It is not for people to like open source and can can be used by anyone else right now. I understand the limitation of being audited. It is always good to be audited because that gives a comfort to user and implementer. But, just where we are at the status.

>> We are open source. We are free to use for personal and academic, but we are going to open it also for commercial use. Right now, the license that you can see when you see the code because it's open source on GitHub in our repo is a license for non-commercial use, but but this will be extended. So, you can trust us and start trying to to do your developments on that. But, the license will be updated this month. >> Very well. Well, as we understand there is a lot to take in. I want you to take a step back, maybe consider our listener is someone who has never used blockchain in real sense. They are the kind of end users of the product. Say, if this is adopted by

a bank, he he or she may be the user of the bank. For them, if you have to explain EVM in very simple terms and maybe like in a minute or so, it can be taken in by the individual. >> I think I can explain as a is the App Store for blockchains, basically. >> The simplest way to say so. Thank you. Very well. That kind of explains a lot of thing. As we started Ethereum as like world computer, smartphone, the reference is reference as an App Store is very good to have here. So, I understand uh right now the project is using uh ZK to hide the data, the personal information because KYC and AML

is also there in place. Is that the way to meet the regulatory requirement as well as the actual benefit of blockchain technology? >> Yes, I mean like we need to do more work around this, also because of the culture for some governments need to switch or need to be extended for understand the ZK benefits, also for understand the ZK complexity. But we when we start like working more together with governments or with institutions that make this accepted because if now I'm I'm going to a place trying to not showing my ID, trying to show my ZK

proof that I'm older than 18 or something like that, no one is accepting me, right? This kind of verification. It's valid, it's valid computation, but it's not valid in terms of institutionality or confidentiality. But yeah, we need to work more around this, make more acceptable for institutions. Yes, probably will be the future of of the identity and and a new way to make a KYC and AML. >> That's brilliant to know. Well, I understand the concept of EVVM is basically building your own virtual machine, building your own project altogether. So, if there is a developer who would want to launch their project

on top of EVVM or with the help of EVVM, I wonder how does building with EVVM is a different than building on top of any layer one layer two project like something that is very unique. What is that we are removing from the equation that helps the builder to build on EVVM? >> So, the more easy way is that more of the protocols they are trying to develop, one thing they have in for sure always is like, "Okay, the user needs to pay gas, but if they want to be more open and want to be more usable." One thing we

try to quickly take a question is the gas fees. So, with EVVM, you can abstract directly all the stuff for the end user so they have to worry about the gas fees. And developing side of EVM needs more easily than just install a library or if you want to deploy your own EVVM, you just using a simple CLI or maybe if you want to go more deeper, you can use a docker container for all you need. So, it's more more easy and you have all the benefits of gas gas abstraction and all the abstraction for all your blockchains.

>> Oh, yes, I forgot. We also have a docker ready to use with an EVVM. >> It's good to know. Well, yes, of course, gas is one of the blocker I imagine when institution wants to bring a blockchain into mainnet adoption. Gas is one worry that everybody is worried about especially when compared to Ethereum. Paying in Ethereum is like high. Also, I understand this project talks about cross-chain payment of gas and uh everything is being done with a concept called Fisher. I'm curious if you could maybe explain a little bit about Fisher. Who can be? Do they require some special equipment or is it uh anyone having a laptop can be

Fisher for this protocol? >> The concept of Fisher comes because we started when people were thinking in how we are going to tell people that exist more than one blockchain that is Ethereum. How difficult is to switch from Ethereum to Polygon? We come from that era. So, for us it's very it's very fun, but at the same time is is like a relieving, but that every problem that we have faced in blockchain about UX wasn't a thing later. We discovered that there was a solution or maybe wasn't a problem up to the gas. The gas is is the first blocker that we really found a little blocker. So, the Fisher was a network of incentives where anyone can

fish a transaction in a fishing spot, this is what we called. So, the fishing spots were Telegram groups, the mempool of Ethereum mainnet, maybe a radio frequency, an API, where different actors, relayers, can go to try to catch transactions, to fish transactions, and deploy them on the EVM getting a reward. This is where the Fishers figure comes into the game. Later, we found that uh the Fishers are not only incentivized by getting rewards. They can be incentivized by being a business that want to sponsor all their user

transactions or just I deploy this contract that is a DeFi contract, and I promise you that if you throw your transactions over there, I will going to execute it because I have benefits for you using my service. So, my contracts like Uniswap. Now, Uniswap, if they want to say we will sponsor all our users transactions, they can give a a payback. All right, it's okay, but this is not a sponsoring. If they were deploying using an EVBM or if they were using an EVM, in fact, we have Uniswap implemented at the APY of Uniswap are implementing the EVBM for voting in this case for other other concerns, but we have also peer-to-peer

swap that later can be Uniswap before only EVM without any problem, but if they would like to do that, they can do tomorrow if if they were on an EVM because they can say we will sponsor all the transactions the valid transaction that has as a target our contract. And they will just need to go and execute it. So, officials are important. Is relayers the most understandable word because are keys interconnecting the non-gas abstracted work to the on-chain gas necessary work. So, this is the one connecting the the transactions of the EVMs that are like intents at the end of

the day unless are on-chain and the interface of the contract that are the virtual RPC we were talking on on the first time. >> I'm sure this is very helpful for non-technical users when they don't have to worry much about like how to pay the fees for everybody when you click over there. So, definitely this concept will give ease to many user and will help increase adoption. Well, let's say an enterprise deploys EVBM today and they are built on top of it. And they are in production and then the protocol evolves. What does an upgrade or migration look like for them?

Is there a smooth path forward or they would be locked in the older version? >> There is a few ways to to do this like upgrade on migration. For first, what we imagine it is that maybe you you don't need to do a hard migration. So, what you do is there is a functionality on the EVBM. All the the proxies or delegate calls or contract that are interconnected on EVBM has the possibility to get renounced. The these functions can be renounced. So, you can change it anymore, get go got frozen on chain, or you can still have the possibility to update them. When you can update, there is a time lock that you also configure in how will be used.

Time lock means you have to tell the users 30 days, 40 days, 1 week prior the change what are you changing. And after this time, you can apply the change. This is important because it's a security measure that if you are doing something that the users don't want, but you want to keep all your contracts agreeable, well, you will have to do a fair usage of these functionalities. And there is one that is the fallback contract. Before the fallback is activated in the EVBM core, there is a delegate call that is null by default. But if you want, you can create there a delegate call to catch everything that is going to be executed

and make this call. And this is how you can make upgrades to the core EVBM code itself. Later on, you are always able to freeze. Also, if you don't you don't uh block it, your EVBM withdraws and certain activities, so you can tell the users, "Hey, we migrated to this other EVBM." And you create a service that is a contract that is connected to your EVBM. And the second EVBM that you are now deploying as the upgrade, where this service will be migrating the accounts that activates the the migration the necessary migration to the new contract.

So, this will be like bring one NFT to another contract by burning it and re-minting in the second in the second contract, you know? It's it's it's not very complicated, but it has to be be done properly. Migration is not a thing, it's just migrating the balances and tokens and move from one contract to another or you can do also with the upgrade that maybe you don't want to migrate everything, you want to just apply some upgrades, you can do it using the given functions.

>> So, a lot has been already considered in this project and I I I know I understand like going careful about it because it may involve a lot of fund a lot of money in there. Just imagine that EVM succeeds beyond your wildest expectation. What does the world look like to you? >> hyperstructures where where the people can contribute and where where something else is needed and is not given, a hard fork of an EVM is happening while we sustain the Ethereum infrastructure by the offer and demand game that is paying us and getting incentives and and wealth be aligned is is what is is alive a form decentralization,

permissionless, and deterministic. So, for for us is vertical scalability. We imagine one chain, maybe it will be more, but we imagine just one chain with a lot of virtual blockchains there scaling using the resources of Ethereum not only properly at 99.5% of demand that is needed for a healthy ecosystem. A chain that is not being used or is on the lowest demand is not on on the full performance.

>> A beautiful world out there. All right, so we are at a good section to move on to our next round, but before we go there, I would like to mention our community partner Eat Clutch. I understand her husband is also a very good friend of Simona. So he already knows about Eat Clutch. So Eat Clutch is organizing its annual event in the month of May and ECH is a community partner to that event. Anyone from ECH community may reach out to us for free tickets or discounted tickets. We would be happy to provide links and resources that they are sharing. So yeah, if you are planning to join the event in person, please reach out to us and if you are someone who is trying to organize an

event at your local community, reach out to us and we would be happy to partner and support. Moving on to the next section. Right. Well, I have few last questions. Any one of you can maybe go ahead and answer that. We would like to have some precise answer for following question. We generally call it as a rapid fire round. So if you're ready, we can get into it. All right. One feature in EVM that you are most proud of but almost no one talks about it yet.

>> A little bit hard but I will say in the CK EVM, I love the part of the privacy feature. >> One blockchain project you wish existed but nobody has built it yet. It could be on EVM. >> Well, um if I want, maybe a bank system, a decentralized bank system. >> An EIP or protocol improvement you think is underrated and deserve more attention. >> This was a good one. Arthur, Kevin, come on. Okay, I think ERC 4337 that it's a construction. I think we use have the the starting part like the community is not exploring more like

more use cases more experimental stuff. I think we try to make more deep in in that ERC. >> What's the first EVBM service you want someone to build on? >> Yeah, it's pretty difficult because there are many ideas, but the one thing I I wish for sure is like difficult payment systems because we see all the all the payment processes like okay, if you want to pay with USDC, USDT, all the stable coins.

If you want to pay with this, you need firstly to have gas. So, on top of you pay for your coffee, your your packages on Amazon, and etc. etc. You need to add the gas fee for that. So, if we eliminate this part of the equation, it would be more and more easy to integrate. So, I think it's the the best service anyone can build. >> I will answer also. I would really want to see games. Games running on top of an EVBM, but high consumption transactions games because with async notices, we have the the potential similar functionality that we have with the UDP

protocol on TCP/IP. And UDP means I will send you a lot of information and you just need to catch most of them to follow some a game timeline, right? With EVBM, you can also do the same with asynchronous transactions sending to a very very not reliable, high efficiency network and the transactions that come will start doing the checkpoints of how the game will will be evolving. So, a first-person shooter or or something that needs a a sports game on chain using this for me will be great because the the sequencing of the transactions will not affect you

because are not sequential nonsence are not more 1 2 3 4 5 6 7 8 9 10. Now are assorted they are asynchronic and the ones that came put you on the game. So we will break the concept of lag on chain and will be a good news because means that we are now using blockchain also as a source of truth for games that are like games that should be like a playing very fast without taking care of one transaction that get blocks and then you are out of the game.

>> Game has always been like one of the primitive use cases for blockchain so this seems to be a perfect one for this particular project. Yes. Well, my final question is I think it is applicable for all three of you so maybe all three of you can respond to this. If you couldn't work in crypto, what would you be building? >> I can answer this. So I always be a open source guy. >> Instead if I building crypto, I was collaborating in some open source project and even so like all the all the crypto protocols and all the crypto products are open source so it's like working in the same environment.

>> [laughter] >> Automotive something like automotive systems or fixing parts or something like that. >> I would be a chef. >> Interesting. Yeah, again I would repeat my statement that this is the beauty of web3 ecosystem. People come from different background, different interest and yet they are together to build something which is good for the entire ecosystem. Well, this was great conversation. Where can our people find you? If someone wants to contribute to the project, want to learn more about the progress, what is the best place to go to?

>> If you are a builder or want to contribute with the project, you can find us on evbn.info. You can have all the documentation and all the information, even the GitHub repo. So, you can check it out and if you want to contribute for the contracts, we have all the documentation for how to contribute. >> And if you want to join our Telegram uh community, uh the channel name is evm.org. And and you can find it on Telegram. And on X, we are rollarmate. I think uh this will be written in the post or or somewhere.

I guess uh you are welcome to join the community in in any in any way, contributing the GitHub, uh asking questions or or writing some documents. And anyone that wants to invite us to their programs and to talk to their spaces, we are very open to talk. Also, we we go to many conferences to talk about EVBM and virtual virtual blockchains as well. And we just came from ECC. We were talking there about virtual blockchains. Uh and well, we we are very uh hungry to build. So, uh we we want to continue doing this and and that's why we are open sourcing and and free licensing this because Kevin

said we are open source guys. >> Very well. Well, if I may request you to maybe send the links to all the presentation documents and other resources that you have uh mentioned right over here, we would love to include them all in our show notes for people who are following these podcasts. And yes, of course, this was a great conversation, genuinely one of the interesting infrastructure project that we have discussed in this podcast. >> [snorts] >> I believe that it is going to solve a lot of real friction that most people just accept that as a part of crypto and I would like to wish best of luck to the entire team. Hopefully we see the project [music]

on mainnet. I guess the timeline mentioned was July and August. >> [music] >> So yeah, all the best to the team. Thank you all for joining us here today. >> Thank you for having us. Thank you. >> Thank you. >> EVM [music] is not a project, it's an effort to make an entire ecosystem. I wish all the best to the team. Dear listeners, if you find [music] this project as well as the series interesting, please share it with like-minded people. Check out the show notes for details of this project and we will try to bring more and more informative project, the public [music] good project for your references. Stay tuned. Cheers everyone.