 Okay, folks, thanks everyone for being here, especially being the last of the lightning talks. Well, my name is Santiago, I work at Zeppelin, and today we're going to discuss a bit about EVM packages and how to reuse code directly on-chain. But before we move into that, we should talk a little bit about proxies and the proxy pattern and how we use it at Zeppelin OS. Basically, the idea for the proxy patterns is to decouple the execution code and the storage layer when we work with a particular contract. So we end up having what we're calling the logic contract, which actually holds the code to be executed. And we have a proxy that actually keeps the storage and the state of the contract we're interacting with. We call it typically the upgradeable contract instance. So any client typically just interacts with the proxy, well, even knowing it's a proxy, this contract keeps track of all the states that we're interested in and simply delegates all the logic back to the logic contract. So for instance, let's say we have a typical ERC-20, which implants a transfer function, the proxy just keeps track of the implantation address of this logic contract. So whenever there is a transfer code, let's say it's simply delegated to the ERC-20 contract. For those of you who know about this little opcode, this basically allows us to execute code from here while retaining the state and the context from here. Okay, so a nice benefit of this besides the gas savings, for instance, is that this allows us to update to a different implementation. So let's say we find a bug or want to improve or whatever it is on the ERC-20 contract. We simply deploy a new logic contract. We update the implementation address on the proxy contract. So all subsequent calls are delegated to the new implementation while retaining the state here and retaining the address that all of our clients are interacting with. Okay, so now let's move into EVM packages. So going back to the example we had just a couple seconds ago, let's say we have a new ERC-20 and let's say we want to actually deploy more than a single proxy. We want to have multiple tokens. Okay, the thing is we don't need to deploy more than one logic contract. We only need one copy of the code that's actually going to be executed. This allows us to spin up multiple proxies, each of these representing a different token, all of which will be delegating to the single implementation contract. Moreover, all the proxies can actually belong to different projects. They can be managed by entirely different development teams and they all can rely on the same single implementation contract deployed on the same network. And furthermore, the implementation contract can even manage by a fourth by a different team. So we could have a team that works just deploying implementation contracts for standards such as ERC-20s and 21, whatever you prefer. And then you have the users or the clients of this code that can be completely different teams that will just deploy their new tokens pointing to this particular implementation. Mind you that while these contracts are upgradable, this one is immutable. This one is fixed. So this means that if any project wants to work with a new version, they simply need to point to a new one. So basically, what we are doing is we are standardizing this concept into EVM packages. EVM packages are a collection of related contracts that are deployed on chain for other projects to connect to and reuse directly on chain. So this is basically a form of code sharing entirely on chain. So in case the owner, the developer of this particular EVM package, again finds a bug, an improvement or whatever it is on ERC-20. They only need to deploy a new version and then it's up to the project, to the users, to the clients of these logic contracts to decide whether they want to upgrade to opt-in to this new version that is being deployed. So one of the first EVM packages that we are pushing is OpenSupply in EDH. This is basically a fork of OpenSupply in Solidity that's built as an EVM package. For those of you who don't know, OpenSupply is a set of reusable smart contracts. We have implementations for some of the most common standards such as ERC-20s and 21 and a handful of utilities as well. So what we're offering right now, but not intended, is basically an implementation on chain already for ERC-20s and 21 and also a couple of goodies for token vesting and splitting payments. All these contracts are already deployed on chain. If you go to Mainnet or to any test network, it's Robstein, Rinkaby, Coban, whatever it is, you can link to these contracts. You can spin up new proxies pointing to these implementations. And you don't need to redeploy the code for your C20 or C21 every time you want to deploy a new token. You basically delegate the development of these standards to the development team behind OpenSupply. And you just act as clients of that code directly on chain. Of course, this package also has all the contracts from OpenSupply and you know and love and are already set up to be used in an upgradable context. And yes, these are all the contracts within OpenSupply. So how do you actually use this from a user perspective? This is where Zeppelin OS comes in. Zeppelin OS basically leverages the proxy pattern for providing a predictability and also cold sharing using the EVM packages pattern. So Zeppelin OS provides a handy CLI in which you can specify which EVM packages you want to use as dependencies. You use the link command for specifying that. And this is basically going to gather the information for OpenSupply and allow you to create new upgradable instances or proxies directly from the command line specifying whichever initialization arguments you're interested in. For instance here, we're creating an ERC-20 instance named MyToken with big decimals and giving this address 100 tokens to begin with. There are other ways for interacting with Zeppelin OS. We're providing JavaScript libraries as well if you don't want to play around with the CLI, but this is by far the easiest way to integrate with. Okay, so to recap, EVM packages basically is a new standard that allows us to share code directly at the bytecode level by having the code already deployed and having the users just linked to it. This allows for gas cost savings because you don't need to redeploy the implementation contracts every time and make it easy for upgrading to a new version. You just delegate to the developer of the package and you choose when you want to work with a new one. And we're providing Zeppelin OS as an easy way to both publish and consume these EVM packages. And one of the interesting things is that OpenSupply 88 is not the only EVM package going around. We have a lot of very wonderful teams also working on their own EVM packages. Some of these are already available on Mainnet. We have packages for Oracles, for TCRs, for Multisig, for a handful of things. We'll be releasing even more and partnering with more teams as time goes by. So thank you all. Hope you enjoyed the talk and sorry I have to say this. We are hiring. Look for us, any of us with a Zeppelin t-shirt. We are a distributed team. We are growing. Please, if you're interested in this, let us know. We'll be happy to have you on our team. Thank you.