 As you mentioned earlier that now Lotus can also sync mainnet of our mainnet with FVM using built-in actor, which is super exciting. We are the node is now launching in Lotus V1, 151, like RC, we're getting tested with some of our TSEs. So that's that. Yes, Venus F4 seems to be beating us, you know, they are also on mainnet, they're very excited. So, you know, the first step towards FVM. Slingshot. Hey, everybody, we launched a new program within the Slingshot umbrella. Yesterday actually called Slingshot Evergreen. For those of you who have been following, Slingshot has been on a nice long journey or since mainnet of onboarding loads and loads of data to the network. I think we just at about 35 every bytes now in terms of data onboarding of about 61, I believe, public and open data sets across the board. But of course, 15 months also means some of the initial deals have started to expire and we want to ensure that data isn't lost, that we can reliably host mirrors of those data sets on the network into the long term. So Evergreen is effectively like a mechanism or a long-term program that watches for data that is in deals that are expiring in the next two months and puts them up for effectively like renewal. And so storage providers can sign up, get vetted and then identify specific PCIDs that they're interested in storing in verified deals for the next year and a half and we will automate like deal proposals for them. You should check out the program details are super swanky website. And like they want to thank the team for a lot of hardware for the last week to get this out the door. Nailed the timer. Good stuff. All right. NFT storage gateway. Hello, it's Alan's lucky day to see my face again. We launched an NFT storage gateway. It's a little bit misleading if you come from the world of IPFS gateways where it's actually a gateway racer folks send HTTP requests to the NFT storage gateway, NFT storage that link. And then we race multiple public gateways by sending requests to them. And then the first one to get back to us with the data. We serve it up to the client. It does come with very aggressive CDN caching cloud worker is built on cloud workers running on the edge. So we do get to take advantage of a lot of, you know, the awesome caching infrastructure out there. We actually have had a 70 percent plus cash hit rate so far for content requested on the NFT storage gateway. Just really specializing in doubling down on NFT storage or NFT CIDs. And there's been about 30 million requests in the last seven days. So a lot of folks have already started using it. There are upgrades coming soon, a paid permacash, super hot gateway. Contrary to what you might believe, I did not make this. It was Vasco with the help of net ops and really appreciate the hard work there. Another thing we shipped mentioned earlier, you can delegated uploads. Hugo was the real driver here. There's a problem in NFT storage previously where we would issue API tokens. But we our users couldn't put those API tokens in their end users, browsers and as a result would have to put up a proxy server to kind of be an intermediate touch point to upload data to NFT storage. But now you can do it without this proxy server because of you cans. There are JWTs where you can have a chain of signatures signed with folks as DIDs to grant subsets of permissions to subsequent you can token. So a user can get a you can token authorizing them to upload data on the marketplaces behalf directly to NFT that storage. And it's coming in Web 3 storage soon. It's going to be super valuable there as well. We're spending out a general you can microservice to kind of combine all this into one thing as well as use it in our new uploads flow as talked about earlier. So super excited about that. Please test it out if this sounds interesting to you. And finally, there was a big Web 3 storage redesign and it is real drippy. It's nice looking. Please check it out. Agency Undone did this for us. Just yeah, I mean, not a whole bunch to say other than it looks completely different than super sleek. I'm a boost here. Hello, boost. Yeah, it's coming. It's so close. So we're kicking off testing with SP's next week, which is very, very exciting. And we're on track for a full release in April. We're wrapping up right now updates to Estuary and Phil client so that when boost launches, they'll be able to take advantage of it right away. We're also working with textile to get support into auctioneer and bid bot. So all those offline deals will no longer need to be offline. It's going to be great. So and what is boost? Well, here's a couple of feature height lights. So boost is the new version of markets for Lotus. It's fully backwards compatible with the current version of Lotus. It's also standalone. So Lotus can release on its own and boost can release on its own. It's really, really great. They only depend on the Lotus API, which is awesome. We're also launching with support for storage over HTTP. So all those car files you have on S3, guess what? You can just make deals with them directly. We're also launching with a lightweight CLI client for data preparation and storage. So if you ever thought like dealmaking on Lotus or dealmaking on Filecoin was too hard, it's going to get easier so soon. We're also launching with a web UI for storage providers. And you can check out a bunch of the in progress docs at boost.Filecoin.io. Thanks. All right. So just a quick update from the FEM already built as program. This has been great work from Ali and Dragon happening here. We had about 100 applications out of which we accepted 25 teams and individuals. And last week we had an informal meet and greet call. Forty-five faults from many groups joined, including people from Balas and Mansdow, Polyfine, Phil Swan, all of those groups that are listed on the left. And we basically went around the room and introduced ourselves. And it felt like there was great energy and pussy-assam. And it felt like the start of something big, lots of cool builders all around the world. And each team spoke about what they're aspiring to build on top of the FEM. And some of the great ideas there were things around reputation systems, cross-chain bridges, NL2s, new SDKs, indexing services, a bunch of things there, pretty cool stuff. And last but not least, Ali and Dragon also worked on spending up a notion website for the program. So there's a link in the slide, go into the slide and check it out. And Ali is also putting together a public directory of all the teams that are participating and what everybody's working on so that you can spy on the progress there and stay updated with everything that's happening inside the program. So make sure to check it out once it's out. All right, DRan is in space. We have been collaborating with CryptoSat for a while since last year, September last year. And finally, the experiment went live and it was successful. They actually ran an instance of DRan between a node in the ISS and on the ground station. And they intend to roll this out to multiple satellites in the future. And essentially, this is going to become a new frontier for a more trusted, tamper-proof computation, so to speak. So DRan is one of the first early set of protocols that are going to be onboarded into space. And we are looking forward to working with them further. So stay tuned. We actually grew our ecosystem collaborations as well. So a couple of weeks ago, we actually had an ETH Global BuildQuest Summit on Web3 Gaming and we gave a talk on DRan. And a lot of folks excited, got a few responses on Twitter as well. So just kind of building up on the ecosystem collaborations going forwards. We also grew the League of Entropy, the collection of the partners that actually operate the DRan network as a decentralized network. Store Swift joined us as a 15th member and we have a couple of new members lined up as well, including CryptoSat as well. And of course, we completed the development of new DRan features, which is quite groundbreaking in sense. One of the first few randomness beacons, which will be unchanged and will actually also be enable us to run multiple variable frequency networks, which means we can run the 32nd network. And in addition to that, we can also run lower frequency networks as needed for supporting additional use cases. So testing is going to commence next month. And we intend to file a Filecoin FIP and engage with the Filecoin team to understand how best they can actually make use of the new features that we are actually launching. Timeline is not a concern. It's more about making sure that we find the right integration with Filecoin in the future that can make use of the new features. And of course, we are kicking off a number of LUE, League of Entropy Focus projects that are going to make life easier for those 15 odd independent organizations to kind of operate DRan. Thanks to Yanez, Nicola, Yolan, Mario, Will, Hector. I think it's been an amazing push that we have been giving here and looking forward to taking DRan to the next level and growing the LUE as well. Thank you. Hello. Hello. It's Yanez here. I'm coming to report after a great meeting that we had in Berlin with ResNet Lab and our collaborators. We gathered everyone for the second time physically in Berlin. And we had great updates from all the teams. We had lots of what they're doing. There was lots of enthusiasm, lots of breakout sessions and lots of results. There was many LiPi2P and IPFS students that joined. So thank you for joining. It's a great way to start working closer together. The primary topic was on network measurements and benchmarking and protocol optimization. I gave a demo in the Endress demo day on the 10th of March. So watch that recording. We've produced a 14-page report with all of the latest results. And there are links here to find out the outcomes of the meeting. Which, to go in a little bit more detail, are a list of items that we want to dive deep into. This includes the flare nut hole punching that Max and others mentioned previously. We want to see better how the effectiveness and the performance of protocols like BitSwap. We want to identify if there are peers with rotating PRADs in the network, which might be screwing up some of the content routing processes, unresponsive DHT server nodes, the reliability and effectiveness of hydra nodes, and so on. And eventually build what we have a vision for the IPFS network observatory, where one is going to be able to look into the network from multiple different perspectives and be able to identify problems and where there is space for improvement. This is the GitHub repository that we're going to be using. There are already several RFMs requested for measurements. So if you're interested, just follow that repository. And out of that, it became clear that we need to have a dedicated team that is going to be working on protocol benchmarking and optimization. And we call that the probe lab. It is still in formation, and it's going to live within production engineering, which is a new group that is going to be announced very soon. So stay tuned. There is going to be lots of collaborations with IPFS and Libby2P students again, as was said previously. We have a Notion page where we explain and we have pointers about everything we're working on. The first order target is the network branching success rate measurement, optimistic provide, and several network measurements for the IPFS observatory. The main motor here is that we're not measuring networks just for the sake. This is not an end, but what we want to do out of this is identify bottlenecks, find bugs, quantify the available space for improvement, and eventually have protocol optimizations. We are going to have grants for that, milestone grants. So get ready, spread the word, and follow us to see interesting things. We have already some results on that whole bunching. You can see a snapshot of a Grafana dashboard down on the right-hand side, but there is much more to come. Thank you.