 Okay, so thank you everybody for attending. I'm working at Open Zeppelin and this talks about like five smart contract patterns, but that's actually a lie. The real thing I want to discuss is what I think is a good mindset when writing a solidity contract. And basically the pattern I'm going to show you are more like examples of what I think can be fun development in solidity and how I think it aligns with the good development practices. So I think one of the two main points I want to make today is that a lot of the ecosystem's value is the result of smart contract composability. That's particularly true of DeFi. And the first thing you should do when writing a smart contract is make sure that you are leveraging as much composability as possible and trying to make sure that your contract can interface with all the existing tooling that would be relevant. An example is people always ask us like, hey, can we make an ownable contract payable like someone could buy it? And this makes really no sense because there is already a lot of tooling for buying assets and that's the NFT space. In the NFT space you can just buy anything from OpenSea or Rarible or any other market places. And we don't want to redeploy that for the ownable contracts that exist. So the idea is that when ownability is just the ownership of a contract in order to have access to it, to some admin functions, well you could just turn that into an ERC721. And this is how you would do it. Basically you can very simply say like, hey, my owner is just the owner of a specific token on an ownership registry and I can have a non-owner modifier for that. And when I want to transfer ownership, the only thing I would have to do is go to this ownership registry and try to transfer the corresponding token. Now on the ownership registry it would have to override the isApproverOwner function to allow that but that's very easy to do. And so here in this example you have a vesting factory. This is actually live on Mainnet. And when you want to deploy a new vesting wallet with a beneficiary for it, well here the beneficiary is just the owner of the NFT on this factory. And when I deploy a new contract I just create a new clone, I initialize it and I mean the token. And that's the equivalent of my owner if the contracts were ownable. The difference is here my contract show up on OpenSea and I can basically sell it or transfer it very easily. If you want to go a bit further you can even have like a universal address ownership registry which I think it's pretty fun because it allows you to get rid of the minting part by just saying that, hey, by default all the tokens are already minted and they are owned by the address that corresponds to the token ID. I mean all the tokens ID that matches an address in a decimal form. And then you can just say that, hey, it's not possible to burn them. You would just send them back to the original owner and there is this is a proof of ownership that I'm doing some fancy stuff with codes but you don't need to care about that. And this can just be another approach, I think it's nice and it shows creative use of your C721s. And another thing we use is that ownable obviously is something that a lot of people are familiar with. The granularity is really bad. Sometimes you have different admin functions in your contract that you want to have different access for and access control does that pretty well. Access control is provided by open zeppelin. The thing is that access control is maybe a bit more difficult to work with because you cannot transfer a role, you need to grant it to someone else and then either get it revoked or renounce it. And so it's very nice for some users but at the same time ownability has some advantages. So let's just combine both. Let's just make a contract that has an owner and the owner is basically the default admin role and then you just cannot grant or revoke this default admin role because that's controlled by the ownership part but the owner still is the admin so it can grant any other role and this here it's ownable but it could be the ownable registry that we showed just before so you could have a contract whereas the owner is the NFT holders and then you have all these access controls that are managed in that way or you could be creative and use your C1 55s here and so yeah that's just some small ideas but it's not very complex code I think everybody can understand that but the point I really want to make is that you can combine tooling together and combine contracts to make sure that everything is as basically as seamless as possible. The second thing I want to present quickly is that the ecosystem is constantly changing and basically when you write a contract I mean you can make your contract upgradable but even we vote the upgradability part you really need to care about what is going to be the life cycle of my contract and are there small tricks that I could use that will make my user's life better in the long run and that's for the users but also for like the UI designers or basically anybody in this space so these are just two small pieces of code like point four and five that I came up with very recently and I think that's things that are interesting because we never expect a hard fork to happen until it actually does and people start trying to do a proof of fork blockchain and then the bridges that are on this proof of fork chain starts breaking and that's a pain so you could imagine having this very small piece of code here that basically takes no size on on chain that just gives you two modifier that verifies that the chain ID that you're currently using is the one that was registered in immutable storage when the contract was deployed and then you could do that to create some kind of bridge where actually most of the function remains completely trustless with this only initial chain modifier but if for any reason there were to be a hard fork the version of the bridge that is on the chain that changes the chain ID then all those would be automatically disabled and you get into recovery mode when some like multi-sig would be able to take over and this multi-sig is not a threat for the user on the legitimate chain because because of this only fork chain like this admin cannot do anything nasty to your users but that's that's an exit point that would have saved some pain I mean it wasn't the proof of fork chain so maybe we don't care a lot but who knows maybe there will be more legitimate forks at some point in the serums lab cycle and another one is that that's something we provide as opens up in and that's what we call the multi-code contract and that's very simple it's just one endpoint one small functions that allows you to delegate to yourself with an area of data and that's very easy for you to integrate into any of your contract and I don't think there is there is any reason not to do it and the way it's being done is earlier we saw this example here and here you have this multi-code that maybe you didn't see because it's red and black so it's not really visible but what it allows you to do is when you want to create a new vesting for one of your investors or someone when if you have 10 or 20 investors maybe you don't want to do 20 transactions that do 20 calls to this new vesting function so what you do is just that you encode like you have a map of entry and you record the function using like ESS or whatever you like and then you just have to do a single call so there is a single transaction here that you have to wait for and what it will do it will basically run like all these these operations so you could deploy 20 vesting at a time or you could do and approve and some something else or you could batch transaction together like you don't need to wait for account abstraction to batch transaction you can already do it at the contract level I mean providing that the target is the same contract for all those subcodes and that's as simple as including that so yeah it keep in mind that there are all these nice tricks that could possibly help your users on the line and I think it's important to have that in mind when building contracts and try to be creative that's it yeah so I'm going to repeat the question for the stream and the live and the question was about like can access control be used for smart wallets is that that's it basically I think well it really depends what's kind of smart way to want to build there are different kind of smart wallets if it's just something that you are the sole owner of I'm not sure it brings anything new to the table but if you are doing a multi-sig maybe it will be relevant I mean my opinion is that a time lock for example is a kind of smart wallet because it's just someone that will manage asset and operation but with specific rules and in the opens up in time lock we use access control to separate the role of the proposers from the executors from the admin that may have the right to cancel potentially so yes if you are building a multi-sig and you want to have different privileged access maybe having an overseer that is able to recover in case of issue having signers having proposers that basically you're turning your multi-sig into some governance mechanism which which it basically is what I'm missing is a governance mechanism so yes you could use access control hey in the example with a multi code that you've shown we are deploying the same methods like a bytecode for this method in every contract wouldn't be better if we have it deployed separately yes it would but it's not possible right now so like if we had EIP 3074 live we could just have this make use this also an old school mechanism to do batching transaction and and you would not have to include that in your contract thing is that this is not available now it will not be available until at least Shanghai maybe later so I think the bytecode increase is is really small compared to the value that is added to your contract right now but yeah in the long run hopefully would have already supported at the execution level later okay great talk by the way in the ownable ERC 721 part you were talking about how you could basically ditch the ownable the ownable library right what what advantage I kind of missed the point of like what's the advantage of implementing the ownership inside the ERC 721 logic instead of just bringing ownable is it just like bytecode size or is there any other advantage that I'm missing no the real advantage is in in composability the example is for example your your ownable contract it could be tied to assets maybe you would want to consider that as a class of its own that you would be able to lend against collateral or maybe it's maybe it's like a vesting wallet that is basically a future financial future that you want to sell on Uniswap on OpenSea right now you cannot sell an ownable contract on OpenSea but you can sell an NFT so the way here is to make sure that your contract is compatible with all the tooling that exists out there OpenSea and others also just being able to see the ownership in your Z-Rion or any wallet you use that's also something nice. Thanks. Thank you.