 I'll talk about ETHPM and a lot of this piggyback stuff what Liggy was talking about with the source verify project, how we've kind of our attempt to find like a mutually compatible data structure for both of our projects. I'll probably start by giving just a little history of ETHPM, how it works, where we are, where we're going, and try to open up for discussion as soon as possible. ETHPM is a decentralized package manager. We're just trying to do what package managers and other languages do for Ethereum. There are two main components. One is a JSON schema. So essentially, every ETHPM package is just a JSON object, and the schema defines how you arrange your contract assets and standardizes it. And the second component is an on-chain registry specification. This is just a read and write API for your on-chain registry. So this is a pretty simplified version, but just to give you the full workflow, you start with a smart contract. Then you create a JSON object that represents those contract assets. You publish that JSON file to any content addressable file system, mostly IPFS. And then you would write these three pieces of data to an on-chain registry, the package name, the package version, and the content address URI. That constitutes a package release. And inside a package, you can also include any number of contracts and any number of on-chain deployments. It's really up to the package author to choose what they think is important to include in the package. And so we also have a defined URI scheme. So with this one string, you can plug that into any tooling or framework that supports ETHPM. And now that tooling will framework, we'll go to the blockchain, look up the URI, pull down the JSON object, and expose the contract assets, and whatever way is useful. ETHPM started in 2016-ish. It was a joint effort between Piper Merriam from the ETHPM Foundation and Tim Coulter from Truffle. One important thing to keep in mind is V1 had a single on-chain package registry. This was decided not to be great. It's a lot of maintenance overhead and introduces some security assumptions that weren't ideal. But also, it made the developer experience a little better. And so far today, ETHPM V1 has had much more usage than V2. And this is mainly because of Truffle. Truffle's integrated it very nicely into its workflow, so it's easy to use. ETHPM V2, which is the current version of today, broke the single on-chain registry model. And now we have federated registries. So if you're a package author and you want to publish your packages, you're responsible for deploying your own on-chain registry, where only authorized parties are allowed to release packages. So far today, we've got a pretty wide range of tooling. We have a CLI. We have a remix plugin, native support in Brownie, JavaScript Python libraries, a Web Explorer. But Truffle's still on V1. And we haven't seen great usage or a large amount of V2 packages floating around. Although V2 support for Truffle is in the pipeline and should be available in the next major version bump. But yeah, so this is just to say that developer experience has been really important in adoption for ETHPM without the nice integrated Truffle workflow. We kind of had this chicken egg problem, protocols and companies, package author or smart contract riders don't hear demand to publish ETHPM packages and smart contract devs are happy to copy and paste code from GitHub to build off of other people's code. And so on the right is just some of the top level keys in the JSON schema. And so ETHPM v3 is started, the conversation started in the source verify and getter channel, trying to find a data structure, a standardized JSON schema that can work for both of our uses. And this is just really nice because it was very important as it's proven very important for package management for it to be as simple as possible for developers. Otherwise, we'll just copy and paste our code. And so now with native support and the compiler, we'll just automatically seed the ecosystem with a ton of packages. And hopefully this spurs adoption and better software development practices rather than copy and pasting code. We've had some productive workshops over the past month. We're quite close, I'd say, to finalizing the v3 spec. There's still some technical edge cases to iron out. But yeah, so once we iron this out, the next step would be to create an EIP and then work on implementation. And yeah, this is essentially the workflow that I envision or one instance of it where a protocol or auditor would have this widget in their GitHub. And you just click it to copy and paste the URI. And then you can plug it into any framework or tooling that you want. It's a really simple spec to implement. It's just JSON. So NPM is used a lot, but that's only for JavaScript tooling, which isn't ideal. And NPM also comes with some security concerns. And so I mean, that's the background. I would like to open up for discussion. Here's some important links. I mean, you can find everything from ethepm.com. The theory of magicians working group is where most of the discussion is happening. And so yeah, if anyone has any questions, it seems like we have a shortage of packages in Ethereum. OpenSethlin has done a phenomenal job of building the standard library, but standard libraries only get you so far. And so if anyone has any thoughts on the developer workflow, it'd be interesting to hear those. Why is this something you want to use? Would you find this useful? And then if not, we can move on into the technical details.