 I'm Conor Swenson. I'm the founder of Web3 Labs and original author of Web3J. And I'm joined here by Availa Kirilov, one of the lead devs, and maintainers on Web3J. We're going to talk today about the Web3J SDK, which is really the evolution of the Web3J library. So hopefully this is going to work. So Web3J is the JVM integration library for Ethereum. That covers Java developers, Android developers, Kotlin developers. It provides things like accounts and transaction management, full type safety with regards to smart contract integration from code. So basically means if you're writing Java code, you have your Java types, and then those get mapped in a type safe manner to Ethereum types. As John just now was talking about, the importance of type safety in the context of formal proofs, although the JVM is not a proof-based language, at the same time, this type safety gives you certain, I guess, guarantees about your code when it's running. We also have native built-all integration. And Web3J itself supports core Ethereum and by extension of that, get parity. But then also Hyperledger Basu, JP Morgan's Quorum. And we recently announced a Aeon integration as well. So it's a special occasion for us, DevKron, today, because it's, in fact, a birthday for Web3J. It's now three years old, so we're really happy that we've reached this milestone and we're really happy to be here as well for DevKron. In terms of the project, though, it's always been, of course, open source. We've had over 100 contributors to it. It's had over 400,000 downloads. I mean, if you say total downloads, that's over 2 million. But again, it shows there's a good amount of traction with it. And we also have a decent number of GitHub stars and a full-time team working on it. One of the classic challenges with open source, of course, is being able to fund it. People love to consume and use it. But when it comes to actually paying for it, then it's slightly harder. And so in that respect, we're very, very grateful to the ECF. They gave us a grant last year. Gitcoin have funded numerous bounties over the last year or two for the project as well. And then at the end of last month, the ECF have also given us a grant too. So we're really, really grateful to everyone who's given us a grant. And also, it means great things for Web 3J and the wider developer ecosystem in our opinion. OK, so why do we have Web 3J? Of course, it's there for specific developers on a certain platform for working with Ethereum. Historically, though, it's been a dependency in effect that people pull into their projects to actually integrate with Ethereum. But there's certain challenges that come with that. And we're always thinking about developers who are new to Ethereum and block chain generally. How can we make that sort of onboarding process as simple as possible? Right now, the journey kind of looks something like the sequence here, where someone needs to create a project in the first instance. They need to create a build dependency, which is pulling in Web 3J. They then need to write smart contract code. They then need to compile that smart contract code. Then they need to find a node to run against, and then finally run the build. And of course, finally pray that it's actually all going to work as well, which is always a big challenge. So we've been thinking a bit about how we can actually simplify this more. And so part of this has been extending the Web 3J CLI, which historically did things like fairly straightforward transfers of Ether, create smart contract bindings. But we're really thinking about how can you make that developer experience better and fundamentally how simple we can actually make it? And that question there is, how simple can you make it for a developer to actually work with this technology for the first time? And so this is what we've been thinking about. And Avila is going to talk a little bit about, too. So hello, everyone. How simple we can make it is three commands. One command, obviously, you need to install the CLI tools to use. So we have a simple code script that will install it for you. It's also multi-platform, so we have equivalents for Windows. That's step one. Step two is you need to create your new project. So simply running Web 3J new after you've installed it will generate a project for you with some boilerplate code to get you started. There is also an option to import an existing Solidity contract or Solidity code to just generate a new project from that Solidity code for you to get you started with Java. And for now, the third step is you need to build it. But we're looking to automate this to make it even simpler for developers to get started in the future. So with the Web 3J SDK so far, what we have achieved is creating a new project, adding Web 3J build dependency, creating and compiling a small contract and creating the JVM bindings, everything of which you had to do manually previously. And we've also been working on a Web 3J unit module to allow you to do better automated testing and integration testing with your contracts. So rather than having to spin up a node or use Gnash to integration test your contracts, we have managed to run the EVM in process in your tests so you can test your contracts as if you're testing any other piece of Java code, which is pretty cool. And I'll hand it back to Conor to let you know about the roadmap and what our plans are for the rest of the year and how we're going to use the grant money. So the Web 3J SDK, it's really the convergence of a number of different components of the Web 3J ecosystem. So your build automation, your core integration library, the CLI tools, automated units and integration testing. And so this is something that we're going to be continuing to do a lot of work on over the next 12 months. But additionally, and this is again where we want to be very transparent about how this grant funding actually directly helps the project as well in terms of the ways in which it can improve the experience. Because our view, of course, is that the more developers we can bring on to Ethereum and the less friction we create for them when they're coming on board, the better it is for overall adoption. We think of it very much so like traditional funnel. In the marketing world, you talk about customer acquisition where you have a funnel that people go through these different stages. And as they go through each stage, you potentially get drop off. We see it with developers exactly the same thing. The more sources that a developer needs to work with, the more commands they need to type, and these sorts of things, in order to get started with it, at every single one of those stage, there's the potential for drop off to actually lose developers who could be people who really get into the technology. And so this comes back to the emphasis on simplicity and minimizing the number of commands to do everything and make it very powerful. Of course, once people familiarize themselves with the technology, then it becomes a lot easier for them to actually dig deeper. But we think it's so important to make this as simple as possible because that's how we drive that much wider adoption to the people who are, who aren't the passionate technologists who are at this conference, but the kind of wider ones who want to dip their toes in, but maybe don't have the time to spend a lot of time going through documentation and everything else. So the testing enhancements, this is an important part of this strategy so that we have automated test generation based on contracts. You have enough information about a smart contract to be able to infer these sorts of pieces of information. And so having, not just integration tests, but also unit tests so that people can test everything locally without having to think about running up the node infrastructure is very, very important there. And another building block for that as well is an integrated EVM. Certainly, whether we actually design our own one or whether we use one of the existing ones like in Hyperledger Basu remains to be seen, but the point is, is having something very lightweight. So if developers are developing a contract using Web 3J, then they can quickly see if that's working or not without having to deploy it to a real network. The other piece as well is Viper support. Outside of Solidity, certainly now it seems that Viper is where there's the most interest in terms of a language for smart contract development. So we want to ensure that there's a seamless developer experience there. And then finally, as well, is like a RESTful API generation off the back of smart contracts. So that a lot of the time people will create some sort of RESTful service on top of the application that actually integrates with the blockchain. So we want to automate that generation as well. And again, just simplifying the experience and then people can use whatever languages they want to to plug into it. That's all we were gonna say about Web 3J. Thanks everyone for your time. We're just over there if you wanna come and chat to us about questions. We've got some nice hexagonal stickers as well and we've got T-shirts and so on. So yeah, thank you and have a great conference. Thank you.