Understanding NFT royalties | Michael Blau

Transcript

So there is a fundamental misunderstanding about the about the mechanics of NFT royalties. And in the ecosystem, there are many ideas, a lot of people that have a lot of different theories and concepts, and maybe even a little bit of drama around how NFT royalties work. But that is not what we're going to talk about today. Instead, we're going to focus mainly on the technical aspects of how NFT royalties work, and why it might be important for you guys if you might want to use NFTs in your projects or companies in the future. So, what is this misunderstanding?

Back when NFTs started to become really popular, the big question that everyone was asking was, "So what?" Right? Like, why are NFTs so special? Who really cares?" And amongst several different answers, and of course there are lots of reasons why we all love NFTs, one of the main ones was that NFT smart contracts enforced secondary royalties on chain, so creators can earn money whenever their NFTs trade on a secondary marketplace. Now, if we pause and think about that for a second, that's kind of awesome.

Like, you can have this asset floating around on the internet, and anytime it changes hands, or anytime it sells on a marketplace, the original creator gets a portion of that sale, right? Which is a pretty powerful and new primitive that we've never really seen before in technology. However, the reality is, smart contracts do not enforce NFT royalties on chain. So, what are we going to talk about today? First, I'll give you some background. We'll talk about NFT royalties, how they work today, things like that.

And then we'll go through the evolution of different royalty standards and potential solutions to this problem that we just outlined. And hopefully by the end of this, I'll give you some recommendations that you guys can all take away to incorporate into your own projects. So, first I think it's important to define what is a what is a royalty. And taking this directly from Investopedia, a royalty is a payment made to an individual or company for the ongoing use of their assets. Now, how does this relate to NFTs? What's an example? Well, let's look at an artist, right? Let's say you're an artist, you create this really cool piece of art, and you sell it as an NFT.

The idea is, because we love composability and interoperability in the ecosystem, if that NFT changes hands or trades or sells on any marketplace, a percentage of that sale price will be taken and go back to the original creator. Okay, that's that's like the high-level of what what a royalty is and what we're going to be talking about today. Now, I'm sure many of you have heard about this thing called ERC-721, okay? But for those of you who haven't, ERC-721 is the standard. It is the specification of what actually is an NFT on chain. What's what's the code? How is state managed? What's what's the function interface?

And if you actually went and read EIP-721 or ERC-721, what we would recognize is there's actually no requirement at all for there to be any enforcement of payment or royalties on chain. So, up here on the screen I put a snippet of code. Hopefully it's it's not too hard to see. This piece of code is the OpenZeppelin implementation of the ERC-721 transfer function. Essentially, it defines the logic of how an NFT will move from one wallet to another.

If you went through this piece of code line by line, every single bit, what you would recognize is at no point in this code does it say anything about a sale price, a percentage, taking a percentage of that sale price and giving it back to a creator, that's not included in this at all. Okay? Now, if you did actually go nitpick the standard, what you would also notice is it does say that you may put a fee into this transfer function. It's certainly something that you can do, and there are a few ways that that you could do it. It's not a, you know, super technical lift.

But even still, there is no standard around it. So, if a project did want to enforce a fee in the transfer, it would be project-specific, and chances are everybody would be doing their own thing. There would be no composability, and there would be no interoperability between projects. So, given all of this, why hasn't anyone done this yet? Like, why hasn't someone just said, "Okay, well, let's just make this royalty standard and and actually enforce a fee on transfer?" Well, it's because there are a few challenges. Now, the whole Again, the point of this talk is to not go through these challenges in detail, but I'm going to give you a high-level overview of what some of them might be, and afterwards, I'm happy to answer some more questions.

So, the first is that let's say you wanted to enforce a fee, and let's make it simple. So, maybe instead of doing a royalty percentage, we just made it $1. Anytime you transfer this NFT, the creator is going to take $1 from you. A user in the ecosystem can always just wrap the NFT, right? So, they can kind of pay this sort of exit fee. And what I mean by that is, let's say they pay you $1, but instead of sending this NFT to another wallet, they send it to a smart contract, and that smart contract locks that NFT and issues a new one to you, thereby, you know, wrapping it, that has no royalty restrictions at all and can trade completely freely across the the ecosystem in the blockchain. Okay? So, that's wrapping.

The other issue is what happens if you want to transfer it to yourself? We're all in crypto, we all have lots of wallets. What happens if you're trying to move your NFT from one of your wallets to another, maybe from a a hot wallet to a cold wallet? It's you, right? There you should not be a fee to do that. And finally, the more stuff that you add to this transfer function, whether it be a fee or any other rules, the the you're basically limiting the composability of that NFT. Again, I know these are super high-level topics, happy to answer more questions about them.

But now that we know all of this, given that we know that we can enforce them on chain, how do royalties actually work? Like what's really going on because we've been talking about it since the beginning. What's really going on is the marketplaces are honoring these royalties behind the scenes. So as a creator, what you need to do, or I guess what you used to need to do, is you had to go to each marketplace manually and tell them, "Hey, these are my royalties. This is how much I want to charge if my NFT ever sells, and this is the address that should receive that payment."

Okay? Now, in a space that loves composability and interoperability, that's incredibly impractical, right? We know now that there are lots of marketplaces on the blockchain, and anybody can very easily fork one or deploy one, and there could be be potentially infinite marketplaces. And it's a lot to ask for a creator to actually go to each marketplace and ask them to manually recognize their royalty and store it in their database. So if we can enforce royalties in the smart contract, and we don't want to have to go and tell every marketplace what our royalty info is, what's the next best thing? What what can we do to maybe help help this problem along a little bit?

So now we're going to transition into what are the royalty standards today and the state of the art of NFT royalties. So the first is something known as EIP-2981, which is the NFT royalty standard. Now, this is super important. I cannot stress this enough. This standard does not enforce royalties on chain. A lot of people misrepresent it. It does not, okay? Rather, all it does is take your royalty info as a creator, which is who should get paid, what's what's the wallet that should get paid, and how much should they get paid, what's that royalty percentage or the royalty fee. It takes that data and

let's just put it on chain. Let's put it in the smart contract itself. Move it from the centralized databases of the marketplace in the first example that we discussed, and let's just put it in the contract. Now, all the marketplace needs to do is simply query your NFT contract to know what it should do, okay? So, the the small snippet of code I have here is that the 2981 standard, which is a function that's called royalty info. And you can kind of see it takes in a sale price and returns to you who should get paid and how much. And the idea is that if a marketplace sees your NFT contract is trading on on their marketplace, they can query this function, know the data, and hopefully honor your royalty.

So, that's great, but there's a small issue with this. The issue is it's it's not backward compatible at all. So, if you have been creating NFTs on chain since way before the standard existed, you're kind of out of luck, right? There's nothing you can do. Sure, if you made your NFT contract upgradeable, maybe it would be okay, but the reality is most people haven't done that. Most people are just using the standard, you know, OpenZeppelin or other variation of an ERC-721 contract, and they're they're out of luck with this issue. The second problem is the people who created 2981, it this is not just their idea. Actually, before this, a lot of marketplaces, such as Foundation and Zora and Rarible and and many others, have their own version of

this. It accomplished the same exact thing. It returned to you the information that you needed to pay a royalty, but what it what the difference was is maybe instead of calling it like royalty info, it was called royalty data. And maybe instead of, you know, returning the actual royalty amount, maybe it just return the royalty percentage in basis points. And they all did the same thing, but they were all kind of a little bit different. And therefore, a marketplace really has no standard to follow. It can't just go accept every single one of them. So, how do we take EIP-2981 and make it backward compatible and also solve this this problem of a lot of standards floating around that accomplish the same thing?

This is where the Manifold Royalty Registry comes into play. So, the Man- Manifold Royalty Registry is a canonical on-chain registry, but does two things. First, it wraps all these existing standards that I just mentioned. So, Foundation standards and and Rare- Rarible standards and EIP-2981 as a standard, it wraps all of them. Okay, so it doesn't matter which one you implemented, it's going to encompass everything. The second thing that it does is it makes it backward compatible. So, even if you did not actually implement EIP-2981 in your contract directly, you can go to this registry today, put your royalty information, and you're good to go.

So, let's look at a quick example of what this might look like. Hopefully, you you can see this image. This is actually a a clip from the royalty registry website. You can access all of this on chain, but this is just the the UI that they that they created. And it's it's pretty simple. You put in a smart contract address, you put in a specific token ID that lives within that smart contract, and then you put in a sale price, and the registry will just return who should get paid and how much they should get paid based on the sale price that you that you input into the into the UI. So, what's the benefit of this?

The first benefit is that you have a decentralized registry that a creator can set it and forget it, right? They can go here, this one place at one time, upload their royalty information, and they're done, right? And the idea is now all marketplaces, hopefully if they agree, will just have to come to this one registry, query this one place, and get all the information that they need. Okay? So, it it makes it both easier for creators, and also it makes it easier for for marketplaces. But, there's still a small issue with this.

The problem is that marketplaces can still ignore the registry, right? Remember in the beginning we talked about enforcing this royalty? But, this just makes the royalty data itself, that the information, decentralized. But, it's not forcing a marketplace to do anything. They still have to be honest, they still have to be good parties in order to honor honor this royalty. So, what can we do to get a little bit closer to this, you know, pipe dream vision of of forcing a marketplace to to honor our royalties? This is where the operator filter comes in. Okay? The operator filter is at a high level, it's simply a block list that allows creators to prevent their

NFTs from selling on marketplaces or interacting with certain applications. It's important that as I go into this idea of an operator filter, it's not just marketplaces, it's really any application. Okay? What's really awesome about this idea is that you can enforce this on chain. This is something you can put in your contract that enforces how your NFTs compose with the rest of the ecosystem. And the reason why that is is because not This is This is not necessarily apply to everything, but for the most part any NFT application, whether it's an, you know, NFT rental protocol or marketplace, generally requires the user to approve a smart contract to transfer an NFT on their behalf. So, in the

context of of a marketplace, they might, you know, approve their asset, their NFT, to a marketplace, thereby listing it on the marketplace. The marketplace will go, accept bids and offers, if something matches, then they will transfer you the money as the seller and remove the NFT from your wallet into the buyer's wallet. Okay, so because you have this the way this this marketplace is actually functioning as a smart contract on chain, you can block them using the operator filter. But how does it work? What's what's actually going on inside this operator filter?

It does two really cool things. The first thing it lets lets you do is block a specific address. Okay, so like I said before, a marketplace you can think of as a a smart contract on chain that is located at a specific address, and I can just block that one address outright. So if marketplace A in the image example here is, let's say, deployed at, you know, address 0x123, etc. I can just block that address. I can block 0x123 from ever interacting with my NFT. So that's great, but we also know that there's a common pattern in the ecosystem where it's pretty trivial trivial for somebody to, you know, fork a GitHub repo and redeploy code, right?

So if I go and block marketplaces 0x123, it's very easy for someone to just say, "Okay, well, I'm going to go redeploy that same code to, you know, 0x456, get around your block list, and allow people to trade your NFT on our marketplace." But there is a clever solution to that, which is something called a code hash. A code hash, for those of you who maybe aren't super deep in cryptography, is simply a a unique digital fingerprint of the source code of the application or marketplace itself, right? So we're going to take a unique digital fingerprint of that source code, and we're going to block that fingerprint.

So now, even if somebody goes, copies marketplace A 30 times on chain, it doesn't matter. The block list is still going to block all of those forks, even if it it doesn't know exactly, you know, which addresses they're deployed to. Now, this is a really good step in allowing the creator to have control over how applications interact with their NFTs, but again, you know, it's not technically perfect, right? There are still ways, a lot of ways to get around these issues, and and I'm happy to to talk talk about that again in a Q&A.

But, now that we know pretty much how to block how to create a block list to prevent certain applications from interacting with their NFTs, what do we filter? Well, there you have two options as a creator or a project. The first option is you can curate your own block list, right? You could have a lot of trust in yourself. You could be a really good on-chain sleuth. You can go, be up to date on every single marketplace and application that's coming out in the NFT space, make your own judgment about whether or not you want to allow your NFTs to to interact with that application, and create your block list on chain, okay? So, that's your first option, make your own.

The second option is maybe you don't have time to do that, and there are a lot of smart people. One of them One group is called CORI, which is the Creator Research Creator Ownership Research Institute, which is basically composed of a lot of popular companies and and marketplaces in the ecosystem, such as, you know, Zora, OpenSea, Manifold Foundation, Nifty Gateway, and others. And it just basically let's let's just let them do it, right? Let's delegate the decisions of who gets to be on this marketplace to to that to that group of to to us. And this way, as a creator, you don't have to worry about it. You just say, "Let's go let CORI figure it out.

Whatever they do is probably fine, and we're all good." Now, obviously, you can imagine there are some trade-offs between the two, right? In one version of this, you have complete control. In the other, you don't, and maybe you don't necessarily agree with all the decisions that CORI might, you know, add to to this block list. So, to go back from the beginning, right? We started with this idea that you cannot enforce a royalty on chain. But, maybe we could just take the royalty data on chain. Let's just put that information on chain using the Manifold Royalty Registry, and then if we want, we can get closer to enforcement using this operator filter. So, given all of this, what what's your takeaway, right? If you guys want to use NFTs in your projects,

what are things that you should keep in mind? The first, just register your royalties in the Manifold Royalty Registry. It's very simple. It costs a few dollars of gas. Very little technical lift. This should be a default for for anyone here who who does want to use royalties for their NFT. The second thing you should do is use an operator filter, even if you don't want to block anybody, right? So, it's it takes no effort to just put this operator filter code in your smart contract today, and just leave it blank, right? Because the space is changing every day. We have no idea what's going to happen tomorrow.

We have no idea what applications you may or may not want to allow to interact with your NFTs. So, just keeping this code in your contract gives you full flexibility and optionality to to change it later. Okay, so put the operator filter in your contract. And finally, like I said, the royalty discussion is literally changing every day. Some of these things that I talked about today are were created in the past few months. So, it's important that we don't make any rushed decisions and regret what they regret those decisions in the future.

So, if you're going to create an NFT, make sure that the NFT is extensible. Now, that's very different from being upgradeable. For anyone who's technical, you understand that you can very easily create an upgradeable smart contract. That is certainly an option here, but if you don't want to do that because maybe you you don't want to have all the control and you want to, you know, be more on the decentralization front, well, if that's the case, then you can make your NFT extensible. So, what do I mean by that? There are many standards in the ecosystem today, not maybe not as pop popular, but they do exist, such as modular NFTs, the Manifold NFT contract itself, the ones who made the the royalty registry. Their NFT is also extensible. And what I mean by that is you can add plugins to your NFT. So, in

the case of the operator filter example, that actually requires you to do a lot of on-chain code, well, if if I had you know released let's say a manifold NFT months ago before the operator filter even existed, because of the way that the contract is structured, it is very easy for me to literally add in a plug-in to that contract and use the operator filter today, even though I deployed this contract months ago before this idea even existed, right? So, you want to give yourself this optionality because you we really just don't know what's going to happen in the future. That's all for me, guys. I'm happy to take any questions.

Hi. Thank thanks for the great great the great presentation. Uh royalties is something I was I've been thinking about uh a lot and honestly, like when I first found out that they weren't baked into NFTs, that I was like I thought that was the whole point, you know? Um Uh have you seen any examples outside of the block list of people trying to implement like royalties or has there like research been done that shows it's like just not possible to do it at the contract level? Yeah. So, the the really funny part about it is that actually is possible and it's really not that hard. Like you could actually I did this the other day. I went to ChatGPT and I just said, "Write a smart contract that enforces royalties." And and it did it. It It's not It's not It's not that hard to

actually implement. It's more that there are so many ways to get around it, right? So, you can kind of think of it like this. If if I'm going to enforce a royalty on chain and and enforce the fee, it's it's almost like putting a whole entire marketplace architecture within the NFT contract itself, which means that the transfer function needs to be aware of what the sale price of the NFT is, right? So, you can almost think about like how how do we interact with marketplaces today? The person who owns it has to has to list it and then someone has to come and buy it, right?

You you have these two things going on. So, you could very easily put that into, you know, an NFT contract, but there are ways to get around it. So, for For let's say the ideal world is we we built it all in and and it's all good. Well, that's fine, but it's also then really trivial for me to create kind of like an OTC marketplace around it where maybe I just allow everyone to transfer for a price of zero. And if the price is zero, anything multiplied that is zero, royalties are zero. Right? So, that's like one one issue with it. The second issue is let's say I wanted to enforce anything above zero. Like whatever this sale price is can't be zero. Okay, well, you could still do point zero zero zero zero to one, right? So, that's one thing. The

other thing is is the dynamic start to get super weird when I'm transferring to a contract, right? Like imagine I'm doing it a transaction between a user and a contract. Maybe I'm depositing this NFT into, you know, some other NFT protocol for for something. Well, like who's paying that fee? Is the smart contract paying that fee? Probably not, right? That's that's kind of weird. So, it's not that it's impossible. It's just that it's pretty easy to to get around. Now, I what I have seen though is there are people who are thinking about other mechanisms for you know, allowing an NFT project to make money as their NFT changes hands. That might be things such as a subscription. So, some sort of, you know, subscription concept.

It could be something like a a harbinger tax. Another idea. And finally, the other um maybe not so technical solution is well, if we have a standard to just detect whether or not a royalty is paid. So, we know we can't enforce it, but let's just say we had a standard maybe like some event log that gets emitted every time there is a transfer to indicate whether or not a fee was paid. Well, then we can the the the people who are running these projects can see that happening and therefore they could come up with rules like, okay, well, if you didn't pay your royalty, then maybe we're not going to admit you to our Discord or, you know, what whatever it might be. So, lose the benefits, yeah.

Yeah so again, there's trade-offs to all of these solutions, but, you know, these are definitely a few that people have been talking about. Yeah, I'd want to send you one like implementation I was working on that um the idea is like I'm kind of like momentum based or something where basically every trade has to be within a like you keep track of the previous price it was sold for and the next transfer function would check like the the new price has to be within say 20% or 30% of the previous price, otherwise it like fails and that would let's say the last time you transferred it was like two ETH. Um it does limit it that like the next price you lowest price you can sell sell it for is like say one ETH, but it would

prevent the like the .001 like transfers. Um but yeah, I'll send the I'll maybe Yeah, yeah, sure. Yeah, I'd love to chat about it. Sounds really cool. Yeah. Um but yeah, thank you. Of course. Hey, thanks Michael. A fantastic talk. I think that was a spot on. So one question I have is um this idea of impossible to force royalties at the smart contract layer. I think you've outlined like a couple strategies that make it a more plausible than what the mainstream may think. Um for example, when when you talk about like the the filter registry, that sounds like it's a form of almost limited ownership where you're checking the EOA of like the the destination address.

I mean, in some sense you could use that to limit the ownership to not allow wrapped contracts that don't have a code hash that is kind of like proven that it's not going to you know, act um in that way. Like why not just create a new standard that takes advantage of those features and like take a stand at the contract level versus delegating this to other platforms? Yeah. So that's a great question. And by the way, just to it's not that it's impossible. It's just that again, there are challenges with it. And yeah, you know, there is certainly an option to to create the standard. And I think what what what what this is showing in my opinion, like all the drama that's kind of going on in the space is not every project is the same, right?

And it might make more sense. So for example, if I'm an artist and maybe I'm only releasing one of one of ones, it might be fine for me to just enforce a royalty and be a little bit stricter with that on chain because maybe that fits the role of an artist more. Right? But maybe some other project that has, you know, hundreds of thousands NFTs floating around, maybe that it doesn't necessarily apply to that as much, right? Because maybe that NFT wants to be a little bit more composable. Right? So, I think it just depends on the goal and what I sort of imagine might end up happening is you're you're going to see people um taking their own stance, right? So, maybe instead of there being like, "Hey, this is the standard that everyone has to implement."

artists might do this. Big brands releasing NFTs might do this. Um you know, people who are making games might do this. You're going to see like a little bit of fracturing across it. As long as if there is a if there is going to be a standard, as long as people can accept it, you know, I think I think that's fine. The other thing, too, that I'll say about the, you know, checking the EOA cuz you're 100% correct. Something that I've talked to on our team is like there are other ways to wrap an NFT contract, um which are like you could do um Darren on our on our team who who who's, you know, hopefully you'll you'll meet him here at some point, has this idea around like burning NFTs and how if you can provide a proof of burn, then then you can actually like

issue a new NFT to the owner, right? So, there's definitely a lot of ways that you can still get around it, which is which is good, by the way. Like actually that's not a bad thing. The point of crypto is you you have this decentralized ownership. If I if I actually do have control over this NFT, I should be able to do with it what I want right? But the the other side of the spectrum as well, you're you're kind of entering in with the operator filter, you're entering into like permissioned composability, right? Like the maybe the the project creator has too much control over over what what you can do with their with their your But again, I think it's going to be project specific.

Yeah, I I completely agree. That's my thesis as well. I think like with share for example, we think a lot about just decentralizing decision-making. And yeah, every project might be different. But I think it's important in the space to like educate that this word impossible may be like a misnomer. It's more so are you comfortable with the trade-offs? Exactly, 100%. It's not impossible. It's just there's a trade-off spectrum and and you you just got to know what that is and be comfortable with it. Thank you. Of course. Thanks for the talk. I think it's very fascinating to see how we can just enforce these things that are outside of the blockchain.

And I was thinking, is there a way to kind of like just um incentivize people to not do that. So, maybe writing standards where the creator can claim back the NFT if they can prove that it has been traded on other marketplace. So, I think some deterrents may go a long way versus trying to enforce because just decreasing the cost of doing it, if that makes sense. Yeah. Exactly. So, that's sort of like the idea of if there was an event log that you can emit every time uh there was a transfer that indicated whether or not a royalty was paid when this NFT was transferred.

Now, the project can basically say, "Okay, well, we can see whether you did it or not. So, therefore, we're going to either provide, you know, we're going to allow you in the Discord, we'll provide you utility, etc." So, they can definitely, you know, come out with that stance. The other weird incentive too is who pays the royalty? Right? Because today, it's the seller. The seller is paying the royalty. The seller who's selling the NFT is leaving. They're leaving the ecosystem. So, they don't they don't really care if if if they pay the royalty cuz they're gone. But then the buyer is kind of like they're out of luck, right? Like, I just bought this NFT, but if they didn't pay the royalty, then maybe I won't get the utility, but I'm happy to pay the royalty. So, how do I do it? Right? So, there's definitely

certainly a mechanism that can be put in place that a project can say, "Listen, if we can see that this NFT did not pay a royalty the last time it was transferred, you know, the current owner can certainly, you know, top it top it up and and pay the royalty to get access. I would caution against giving creators too much control over, you know, pulling NFTs out of people's wallets. I think because that sort of starts to go back on a lot of what makes NFTs so incredible. If I own an NFT, I I really want to be sure that it is mine and it's in my wallet and nobody can take it away from me. As soon as you start to add those other rules around like permission to ownership, not to say that it's a bad thing and I think it might work for certain projects

depending on the application. I would just, you know, that that is a little scary to me because all of a sudden this one of the one of the key reasons why NFTs are so amazing is because of authentic ownership and if I don't actually have that assurance on chain, I might be, you know, a little scared. Okay, thank you. Um wondering why so OpenZeppelin, for example, why don't they include like a hook to the operator filter in in their in their contracts? Like if if it becomes part of a standard or it's looking like it's going to part of a standard, it shouldn't affect interoperability as much, right?

Yeah. So, they do So, what they do have is actually maybe I'll Let me just cuz it'll be good to look at this. Okay. So, like what OpenZeppelin does have is this thing called a before token transfer hook, which allows if you're just like copying and pasting a standard and deploying it, it's going to be empty. That that that piece of code, like right right here, it's not going to do anything. But if if you did want to develop, you could basically within that hook put the operator filter.

And also, to be honest with you, the operator filter is like less than a month old or, you know, maybe 2 months old, so I do think that eventually it will will be added. But, here's the thing with the the filter as well. Like I don't know if you've seen the OpenZeppelin wizard where you can kind of like plug you can like click different options. I could imagine there being an operator filter in there, you know. But even within the operate operator filter, there's so many options, right? Because like I said before, you could subscribe to somebody else's code, which is that's going to require a much different implementation. And there's also like if you wanted to curate your own, there are different ways you can do it and I don't want to get too technical, but like you can like put this curated list directly in your

contract. Or you could actually deploy another smart contract that hosts the list. And when you do that, you can the NFT and the the the the block list can like be separate from each other. So, for example, let's say you as the creator like need to transfer ownership of this block list to your community or to somebody else, you can do that. Like it gives you more flexibility. So, even within the operator filter, there's so many variations to go. But I I could imagine them, you know, putting something in for that. The other thing too I'll say is if you have I know I mentioned Manifold, if you have used a Manifold contract, they actually do have this. So, when you go and deploy a smart contract on their on their website, you can click a button and when you click that button, it will

add in this operator filter into your contract for you without you having to write any code. But by default, that version is completely curated. So, it's not you're not going to like subscribe to the Corey one, it's going to be the one that you you choose to make. Got it. Thanks. Of course. Awesome. Well, thank you so much, Michael. That was great. Thanks guys.