 Hey everybody, this is Raul from the FEM team. So it turns out that the FEM team doesn't really rest a lot and we've been hard at work shipping M1, which is Jennifer said is going to be going live with a scour upgrade on July the 6th. And just as a reminder, M1 installs the FEM technology on the network and basically transplants all of chain execution into this new Wasm based runtime. But also in the last weeks, we've started working towards M2, which is the milestone that most people really care about because it brings the much desired feature which is user programmability. And that is basically the ability to deploy custom contracts and actors to the network. Now, the first kind of workloads we'll be able to deploy to the network are EVM smart contracts. And these contracts will have the ability to interact with built-in actors. And just as a reminder of how this kind of works under the hood, the FEM is a hypervisor inspired runtime environment built on Wasm and it's capable of hosting contracts and programs written on four different runtimes and diverse runtimes and the goal is to provide seamless interoperability between those kinds of workloads. So bridging kind of like translating calls and making sure that addressing and identity is well-covered, cryptography and so on. Why before we move forward, I want to just touch on one topic, which is why are we focusing on EVM programmability first before native programmability? And this basically is around the sentiment that we've collected in conferences. It indicates that the community is really eager to build as soon as possible and really they want us to meet them where they are today. And that basically means that many of these developers are Solidity and Ethereum developers and they want to use their existing tools and know how to just build on Falcon and get started quickly. They're also very important. They stress to us that the reason that they're deploying Falcon is actually to be able to use the native Filecoin features. So one thing that we're focusing on is on providing Solidity libraries, precompiles and so on so that EVM smart contracts will be able to interact with built-in actors and utilize and query and so on, Filecoin, Filecoin features and state. Now they also want to be able to, another advantage of focusing on this is that there's a ton, a ton of ton and a massive number of contracts that have been battle tested, audited, that are production grade in the Ethereum ecosystem that will be able to basically port to Filecoin in a very seamless manner. And these, and also like the important thing here is that these contracts will be able to compose Filecoin features. And these are things like ERC20 tokens and FT's and so on, which are useful premises that then you'll want to be able to compose in Filecoin related features, like say for example, providing provability of NFTs stored in or tracked by a particular NFT registry and providing provability that the data that is represented by those NFTs is alive, healthy, being proven as a specific replication factor and so on. So this doesn't mean that we're not gonna focus on native programmabilities. We're gonna continue specifying features and specifying kind of like the design surface for native programmability so that we have a full picture but we'll focus on bringing those native specific features to fruition later after we bring EVM above. So one thing that I wanted to stress is that this milestone is gonna be spec first. And now we have with M1, we shipped a solid set of baseline specs that we're able to work against and this is for 30, 31 and 32. So if you wanna go check those out, you're free to go into the fifth's repo. But kind of like the spec that kicked off all of the EVM, FEM work is this initial parent spec that you'll find a link in this slide side but it's just in the FEM specs repo. We've also enumerated all of the technical areas that are gonna require further specs. So the team is currently in a phase where we're doing a prototype and at the same time we're burning through these specs that will help us continue refining more and more detail. So things like account abstraction for the, concretely, this will bring us the ability to execute native and transactions that were issued from Ethereum wallets like MetaMask and so on, logs and events support, things like how do we support the EVM delegate call, opcode and a bunch of other things. So stay tuned if you want, like I would advise if you're interested in this work, subscribe to FEM specs and also subscribe to the FEM repo and watch the discussions and the issues fly by. Now, this is a complex endeavor. So you're probably thinking, wow, this sounds massive. Yes, and we're aware of it. And we're also aware of the fact that there are many unknowns that we're probably just not seeing yet. So in order to uncover these unknown unknowns we embarked on an EVM, FEM prototype and shout out to Karim. He's a team member at the FEM projects with the implementation there. And yeah, we just made it public yesterday. So if you're interested in what's going on there go to that repo FEM EVM under the FileCon project organization. And as of today, we're able to deploy EVM bytecode and run a simple coin contract that performs state reads and writes. And so with that, we've got a surprise for you. We've got a small demo which Steph is gonna do live right now. Yeah, so what we're gonna do here is deploy the EVM bridge actor then deploy an EVM actor using the bridge actor using an EVM message. So cool thing about this is that we're gonna take an actual EVM message, submit it to the bridge actor and then execute the init code. This, the actual workflow here is gonna change a bit or the flow here is gonna change a bit on mainnet because we're trying to reduce the amount of like, I guess, an EVM specific stuff you have to do. What you'd like to do is to abstract accounts so you can just send effectively an EVM message to the chain and chain will be able to deal with it but we're not quite there yet. Okay, so let me quickly run the test. This will take a few seconds. It doesn't work. We can always switch to a pre-run version but it's kind of fun. So right now it's trying to deploy the contract. What we can see here is like, look at the code. Can you guys see the code? It's reasonably available. So what it did was it went here, created the tester then it deployed it. So it constructed the contract. So that's what happened here. It signed the transaction using the key using the EVM format. Then it submitted a message or basically it called the EVM bridge contract with this custom message. This message here is a clinical legacy EVM message. It has a non-scas price, gas, and whatnot, et cetera. And it includes the input is the contract itself. Again, this is an EVM message, not a five point message. You can see here that it worked but let's actually go down and see what actually happened as if we look at the, okay, so there it is. So basically what this did was it invoked this invoked actor method here, which went down here. Let's try to find where it actually, okay, there it goes. So once it goes through some testing stuff, it executed the message. Oh, that's the long done, fine. So I think it actually did because I can't drill through the code here. Let me just reopen the file. I think it actually did was it eventually called this function here, this create contract function, which takes the signed transaction and it constructs. So it uses a bunch of stuff here to actually construct an FBM actor. And then it actually executes the EVM bytecode on chain inside wasm. So this is all that's happening this year. Sorry, I forgot to mention this. This year is the bridge actor. This is actually running as an actor inside wasm. So actually, let's go back to the top, sorry. So at the top, this is the bridge actor and this is the definition of the bridge actor. We ended up calling into process transaction to actually execute the transaction inside the wasm container, inside the FBM. That process of the transaction, it's, then instead of unfortunately we're at time we have a little time. Are you able to show a message being sent to this contract? Well, so if you look down here, all right. It's no worries. Yeah, it is working. Yeah, I don't think you actually set this test specifically sorry, I did not write the test. This test does not actually send a message as far as I understand. It just sends a message to the bridge actor which then constructs the EVM actor. It doesn't send a message to the EVM actor itself. Got it, got it, yeah. I just wanted to talk about what's next. We have several lines of work that are opening up where the team is working on the prototype. There's a bunch of things that we know that we need to go through and continue building out on the prototype. This, the work that we do here is then going to feed into the technical design. So there's a really nice feedback loop there. We're also working on technical designs. Some of the most critical ones are account abstraction, the universal stable F4 address class and so on. So feel free to tune into the repos for that. There's also going to be a set of EVM focused community RFPs that we're going to be opening up. So things like Solidity libraries and pre-compiles for interfacing with built-in actors, automated test and deployment of existing Ethereum contracts from like things like open zeppelin libraries and so on and a bunch of other things. And also we're going to be starting and Ali and Dragon are going to lead much of the charge here. A new early builders cohort that is focused on use case building, the previous cohort or the existing cohort, the one that's running now is focused on tooling. And this one is going to be focused on use case building using Ethereum tooling, existing Ethereum tooling and deploying on the fiber network. So that's all from the FEM team today. Thanks a lot.