 Hi, today I'm presenting you FHEVM. This is a project we are working on at Zama. So Zama basically is a company working on homomorphic encryption. So homomorphic encryption to summarize it is the possibility to compute over encrypted data. So FHEVM is one project dedicated to integrate homomorphic encryption and computation over encrypted data directly in an FHEVM. So today I'll show you an example like a classic ERC-20 contract. So basically to use what we've done basically you need to import like a library available on NPM. The idea around the FHEVM is that we added some pre-compiled contract to compute over encrypted data. So if you take a look at our contract we have like the total supply, which is not like a classic Uint 256 but non-crypted Uint 32. And the same for the balances because the idea is that all balances of every user are encrypted. But still if it's encrypted we can still do transfer, mint and etc. So this is like a classic ERC-20 like the few differences we'll see is basically like the way we mint for example. So if you mint an amount of token the user will send a non-crypted amount. So this is an amount encrypted with FHEVM. We need to validate this amount. So to validate this amount we'll check the zero-image proof that it's a valid safer text. And then when we validated the amount we get like a non-crypted Uint and we can add it directly to the balance of the contract owner and also of course to the total supply. If we take a look at the transfer method and you'll see that it's really similar of what you would do for a normal contract. So if you want to transfer some token you will send an encrypted amount to someone. So first you need to check that the user has enough token to transfer. So this is like a require but at this point you need to do some decryption because if you want to check the amount regarding the balances of the sender you will get encrypted Boolean. So this is encrypted you don't know if the user has enough token. So you need to do a decryption. So at this point we will do one decryption so if we decrypt something we are leaking some information but the only information we are leaking is this user has this encrypted amount on this encrypted balance. So basically we don't link much information but in other case it could be a problem. So this is the require and then you see the balance is like what you would done with a classic transfer. So you're just adding and removing amount from the balances. We can do that because we are using the Soliti 0819 which allow operator overloading. Behind the scene this sign is interpreted with a pre-compiled function doing homomorphic computation. So this is like it looks like classic computation but it's really like a homomorphic encryption behind the scene. So we can test it. So this is like a classic remix instance because we don't change the compiler like it's a classic Soliti compiler. So you can compile your contract. There is nothing new because like when you are using TFHC library basically we just call pre-compiled. So the only need is you need to deploy it on an EVM with this pre-compiled. So you need to deploy this on the FHCVM basically. So we'll switch to MetaMask account which is connected to DevNet with FHCVM. And we can deploy our contract. So when the contract is deployed the first thing we want to do is to mint the contract. So we are using a specific version of remix. Basically it's exactly the same as remix but we have did like a small tool to encrypt data on the fly. So for example I want to encrypt 1000 token. So I will just tip 1000 but in fact it will create the cipher text with the proof in remix directly. So I can make a transaction. So I asked to, I sent to the EVM basically I want to mint an encrypted amount so no one knows how many token I asked to encrypt. And if you look at the transaction hash, so this is my mint transaction. And as you can see like the input is fully encrypted like there is no 1000 appearing anywhere. And so next step is to check the balance of the owner. If you want to check the balance of your owner you want to be sure that you are exposing the balance of someone because like if you are doing a call this is not authenticated like you can ask any balance and put on to be anyone. So to do that we are using EIP 712 token. So the idea is when as a user you want to to allow it up to access some information, you will sign a public key and you will send this public key to the function. So if we have a method called round crept, you will send the cipher text and the public key, and we will do a transcription, because the whole EVM using the same FHG key. So you will do a transcription with the user key. So to be sure that it's valid user key, the user need to sign it. So for example, I will use the balance off. So we added a public key signing. The DAAP asked me to sign the public key. I allow the signature. So now I can call with my public key and the signature of the public key. So the contract knows that I'm really the message sender and it allows me to round crept my balance. So it will be the same for the transfer. So if I want to transfer some token to a second account. Basically, it will be the same. Let's say I send 200 and transact and confirm. So I didn't switch back. No, okay. I didn't switch back. Okay. Yeah. Okay. I didn't switch. Let me do it again. Okay. I need to mix two. Okay. So now I have 800 token on the other second because I transferred 200. So that's all I think it's, if you want to try, try this, this is already available in who DevNet. We just announced who alpha version of FHVM. This is available on the Zama FHVM. You can see quickly the link. It's you have all documentation there. You can already play with FHVM and try to, to build smart contract with encryption including and that's all.