Go searching around on my disk. I'll tell you what I want you to read. And so I pass that into the eval. It reads a file. You got simpler code, cleaner code, and oh by the way, accidentally more secure code. And that's sort of the basic object capability architecture is just use objects have the right frameworks which someone who's more expert than it can define it. But now when someone's building components, they just have available to them what they're allowed to use. It's called the principle of least authority, and it is sort of a long, standing bastion of how you make systems actually secure is you give them just enough authority to get their job done, you don't give them all the user's authority to read all the users files. If they don't need that. And libraries don't need that. And in default JavaScript in rust and C and Java in all these languages, everything launches where libraries can do anything the user can do, and it's just a bad architecture. Our model of ocas gets rid of that. And you need that for smart contracts. Right. So maybe I want more question on that. So if I let's say if you look at something like, right? Like my understanding will be that like, okay, as a very much of an amateur who has no clue basically. But one of the ways that smart contract might be vulnerable is, okay, there's some function in this smart contract and it was meant to be a maybe used by this program in some way. Debates a mistake and now basically anyone can go and call that function in some way that wasn't intended. And so maybe I maybe it's like the program was like, oh, distribute these tons, but actually anyone can come up and say I'm going to send this. So how would this be different in because a function, the object and fundamentally, I mean, that's like The Blacklist model of security rather than the whitelist model of security. You can do anything to anyone unless they put up barriers to stop you. And if they forget, oh well. Too bad. Right. Not a great system design architecture. So yeah, in like, let's talk about ERC 20. And the approved function and that sort of thing. Or before you actually, if I was going to pay you a token, I would expect to get the token and hand it to you. So Brian dot enjoy open par in token. Enjoy open concert ticket better still, right? And maybe with objects now, we both have it, but you'd have some library so you could say, great, I take acceptance of it now I have it uniquely and you don't. So I send you the package and you open the package and now you have it and I don't. And so that's what we build in our smart contract framework. In Ethereum, you can't do that. You can't pass objects, which means you fundamentally can't do all caps. Instead, what happens is I talk to another contract over there and say, take this money, take this token, take this concert ticket, set it aside for Brian. He's going to come get it. And then I tell Brian, okay, I said a package for you, number 37 over on that he actually 20 contact. Go get it there. And now you go to that ARC 20 times and say, hey, I'm Brian. Let me show you my ID, and you get the package, right? And that's the ERC 21. That's fundamentally what's going on, except that if there's going to be a bunch of stuff you might want to do, like, I want you to buy a stock for me, you know, and then I want you to buy another stock. And then, you know, you're like, you're my portfolio manager. Every time am I going to take a $100 and I'll put it over there and then you go over there and pick it up or I just say, let me put a $1000 and just give a general thing that Brian could come and take whatever he needs out of my $1000 and he'll figure it out. And well, you know, now that's essentially the approved function. Okay, I put all $1 million and I'm expecting you to do a $1000 at a time and you want to go on vacation. You just take all $1 million, go buy a vacation, you promise to pay it back. I mean, what's gonna happen? What's the worst rate? Okay. An analogy I like here and this goes back to the easy to understand things is if I lend you my car, right? The Ethereum model is I tell my car, Brian's allowed to drive it. You then take my car, you go to the hotel. You want to park it, you go to the valet, and you say what's your name? Oh, I'm Joe. You try and add them to the car, and it turns out you can not. And now either I have to make you an administrator so you can add anyone as well. So not only can you park my car, you could sell it. Or you come home, you know, SOL. Instead, the O2 model is, here's my key. You now get into the car, drive the car. That doesn't give you access to my house. It doesn't give you access to my money. It gives you access to my car. You go to the hotel. You hand the key to the valet. You don't need to know who the valet is. You just need to know that they're now responsible for the car. They go off duty, they hand the key to the next valet, you come out, take the key you drive home, you give it back to me. We're all done. And there was no discussion of who these people were. There was no problem of administration. There was no giving you rights to sell the car. There was just the easy hand off of an asset as a barer instrument. And the el cap model.