Ethereum Cat Herders PEEPanEIP, 12 Jun 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #110: ERC-6220 Composable #NFTs utilizing Equippable Parts #erc #smartcontract

Description

Topics covered
-------------------------
0:20 - Meet the co-authors
0:50 - ERC6220 requires
1:31 - Presentation begins
2:40 - About ERC6220
6:50 - ERC6220 Use cases
14:00 - Project implementation
16:25 - Tools for dapp developers
17:25. - Why is this EIP unique?
21:27 - EIP process for ERC6220
27:55 - Additional resources
29:10 - End of presentation
33:31 - Recommendation to new authors
34:34 - Slot types and part types
36:46 - Catalog vs supporting direct NFT equipping
39:37 - Thoughts on other composable NFT proposals
43:43 - Word of advice for new authors

Follow at Twitter
---------------------------
Steven @stoicdev0 | Jan Turk @JA_JanTurk | Bruno Skvorc @bitfalls | Pooja Ranjan @poojaranjan19

Support us
-------------------
Wallet: EthCatHerders.eth

Resources
-----------------
Slides: https://www.canva.com/design/DAFk_B1fSC4/dj1z0dDWtY34Loia2OQKmw/view
EIP: https://eips.ethereum.org/EIPS/eip-6220
Discussion: https://ethereum-magicians.org/t/eip-6220-composable-nfts-utilizing-equippable-parts/12289
ERC-721: https://youtu.be/X0qPai9qPL0
ERC-5773: https://youtu.be/ju5U-iMEz4M
ERC-6059: https://youtu.be/2C7mKNK5f9s
ERC-2981:https://youtu.be/hTbcw0rhLto
PEEPanEIP Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
ERC Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K
NFT Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxpUmj2UjD4BtfgC1nAAyv3p

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/

A

Hello, everyone: we are back with another nft standard overview. This is your host pujaranjan and I. Welcome you to p penny episode, 110.

A

Today we are joined by team remark to discuss ERC 6220 composable nfts, utilizing equipable Parts erc6220 was documented in December 2022.. The proposal is moved to fund status in April this year. I'm super excited to invite Ian, Turk, Stephen, Pineda and Bruno from the team to share this EIP with us. Welcome back on people need.

B

Hello thanks for having us back thank.

C

You nice to be here. Thank you. Well,.

A

This proposal suggests that erc6220 requires a EAP, 165, EAP, 721, eip5773 and eap6059. That means it is highly recommended to follow these proposals and we do have episodes recorded with Ian and Steven on 5773 and 6059 and, of course, eip721 with William in trichin. You may find that a link in the description below please check it out moving on I suppose we have got a presentation to be shared so without further Ado, let's peep in right.

B

So welcome to people.

B

So composable nfts utilizing equippable parts. Let's talk about a team for just a brief minute. I know that we've done this in the previous two people needs, but just to get on the same speed. So before we started with our proposals, we're mostly still unique digital tokens. They could contain audio files, images, computer code, art and many other things, but and their ownership was secured on blockchain and they had unique IDs.

B

So you the tour owner of this exact token, but the problem was that nfts were static, so that meant, you only have one file and it's presented the same everywhere and no matter what you did. This wouldn't change. There have been attempts at proprietary attempts to tackle that, but we wanted to build kind of a universal solution to that. So remark: standards are our set of standards that allow nfts to move into the next step of the evolution.

B

So we call that nfts 2.0 and with composable nfts utilizing equippable parts we kind of bring together the previous two ercs that we talked about so multi-asset DRC, a 5773 as well as nestable, ERC, so 6059 and in essence erc6220.

B

The one that we're talking about today is nfts equipping nfts, and you know we could stop here and say thank you and go our separate ways, but let's dive into it so equippable Parts facilitate composing of entities, and this allows you the owner to kind of narrate where you want your entity go or how you want your entity to look, or you know how you want it composed, because it's not necessarily that your nft is an image that is being composed.

B

It could be a song, it could be a house, you know, so this proposal actually standardizes two smart contracts or rather two interfaces. One is the equippable collection interface and the equippable collection interface is really quite similar to 721, with the equipment logic added 721 yeah with the equipment logic edit, but there is also catalog and catalog is what powers. The equipping kind of you know because catalog contains bars that can be cherry-picked to compose your nfts and a cool thing about.

B

Catalogs is also that you can have one catalog for multiple equippable collections, so you can have multiple equip smart contracts that all utilize the same catalog and that can be useful for or many different use cases.

B

For example, metaverse I know it's not as hot of a term as it was half a year or a year ago, but still you could have a Sandbox metaverse, where you know there would be a bunch of collections building their own microcosmosis and their own ecosystems there, but then they would go back to the catalog and they would all use the same one. So this is really cool because then the assets or the parts could be shared between those collections without any additional logic needed.

B

So there are also different types of parts that we Define in the catalog.

B

One are fixed parts and one are slot parts and fixed parts are fixed, so this means that they contain their metadata and they cannot be replaced once equipped and they are similar to assets in 5773 and those also have their own metadata and Slot Parts allow other tokens to be equipped into them so based basically, once you equip a slop once you add a slot bar to your nft, it doesn't add an asset to be displayed there, but rather specifies where other tokens Can Be nested into.

B

So that's where dependency on erc6059 comes in, because then you can Nest nfts into that slot part and essentially equipping them. So that's where equippable Parts comes from and as always, we designed this proposal with owner Focus pattern.

B

So you cannot expect the the game or the issuer of the collection to just be able to do all this on your behalf, without your knowledge, because this way we're protecting the owners of the tokens to have the tokens that they expect, they cannot be forced to equip items that they don't want or that are possibly illegal to have.

B

Or you know items taken away from them if they worked really hard to obtain them, and you know shout outs to one other non-dependent ERC, so with the addition of transferable interface of erc6454, then you could have soul bound items, so this this guy can come really handy in gaming and also in other aspects that we'll highlight in the next slide. But this means that similar to RPGs, where you can have sold bound items and if the equipped nfts can also be sold bound to the pre to the owning nft.

B

So this also adds kind of a new mechanic that can be explored here. So I I also appreciate out the use cases, but let's jump right into them. So one is composing and I. Think I I kind of spoke about this in the previous slide along so and if multiple nfds can work together to create a greater construct so, prior to this proposal, you could do that, but in a proprietary way you would check the wallet and either assume what the user wants to render.

B

Let's say you have a collection of you know five compatible tokens. One would be the character and then you might have two weapons and three armors. If you we're talking about a web 3 game, and this here would be that if you just looked at their wallet and rendered, you know compatible items one on top of another, then your character would have three armors equipped and two weapons, which would be unpredictable.

B

So another solution would be to kind of keep track of which items does the user want to have equipped uh in either a centralized way so on a server somewhere or in a separate smart contract? But up to this point, a proprietary, smart contract, and this actually allows us to get the predictable composition of nfts? And this is really important, and you know gaming is the easiest to explain. So that's what I'm focusing on it, but it really can be so much more.

B

Let's say you have a web 3 architecture company and you have a base blueprint and then you allow the customer to kind of equip e room by itself and then different features into that room. So this would be separate, nfts that are kind of pieced together and based on you know the detail or the complexity of the room. The prices could have vary.

B

There could be additional constraints, and it's important to know that where you placed different rooms, so usually the dining room is next to the kitchen and if they were in the wallet- and there was also a bedroom in the same wallet, we don't want bedroom to be rendered next to the kitchen and then dining room somewhere North facing so this kind of allows us to do a lot of predictable composition and some really cool contracts.

B

Another one is token progression, so I'm regressing back to the gaming so as the token progresses through various stages, it can attain or be awarded various parts. So in a gaming sense, this would mean that you know, as you progress through the game, you get better gear regret you get new skills and all of that can be equipped into your base. Token, your base character. If we are talking about a Dallas, then this would mean that your base dial membership nft can also attain different parts.

B

So this could mean that if you have an elephant that you use to kind of get into the dial limited spaces, then this elephant could get a headgear that symbolizes that you're an active member of the community and allows you even further. So this can also tine it to different aspects, not just gaming, and with that I'll. Let Steven talk for a while. Okay.

C

So next use cases is near tracking. There was a really nice experiment that happened on the chain that gave there to to this standard, which is was Kazama so in that blockchain people could participate in governance with the native tokens. So what we did was that we sent a shelf to people every well, the first time they participated in governance and then every time they voted on a referendum, which is how it works there. They would receive an nft related to that referendum.

C

So people started building those shelves showing how they were active participants of the decisions that were taking for the blockchain, and that was a really good incentive for people to actually participate. It's not. uh It doesn't have a value, although they were sold and for for Value, but the the more important thing is that it shows that you are in that, in this specific case that you're an active member that you care about the blockchain.

C

So this can be applied in several other spaces where, for instance, if you review smart contracts or a few uh do opens our staff or different actions in the web tree blog space or whatever other real-life blog space Sorry space, you would get married there could a registry or a dial which provides this Merit tokens, and then you can equip them into your into your reputational avatar, for instance. So this is a very cool thing that erc's 60 to 20 opens another one. That I like a lot is a provable digital scarcity.

C

So here I'll go back to gaming because it's the simplest to explain. Let's say: I have a sword: nft I have a collection of swords and there are a thousand swords and they can go into a thousand Monsters of some collection. Now since this, since we can share the catalog between different Collections and the catalog defines this like this, not only the fixed parts that you can generally pick to build nfts, but also there's lots where things can get can be equipped.

C

Different collections could use the same catalog, so they Define instance that the these swords can be equipped either on the right or the left hand of the character, and that could happen not only for the original Monsters collection but for other two or three collections with different Mac supplies. So initially you had a sword that you could.

C

If you had a sword, you could put it in one of a thousand monsters, but as more collections start adding the disk compatibility, then you could end up with a sword that it's equivalent to 10 000 or more different characters. So it becomes much more value and you don't need the idea that we want to to a shift with. This also is to create a higher sense of community.

C

So we don't want people to start building older collections in in, like every game has uh I, don't know, 10 different assets like the game, character and the armor and the weapons we could start seeing very interesting collaborations, and even if the games uh have different styles, thanks to the multi-azid ERC, they can also like each of them can propose an asset that will match nicely with the style of each of the game, but they could reuse each other's collections.

C

So, for instance, I can, let's say Ian and I have our own Collections and they are both. You know: fighting characters and I create a collection of source and he creates a collection of uh shields for his collection and my software for mine. We can create this like we can expand the utility of our nfts if we talk and agree that my source should be equippable to his uh monsters and his Shields should be equivalent to mine.

C

So this I think it's something really powerful that we don't talk about uh enough, uh but I I think this will create uh bigger communities in collaborations between projects. Okay, so same as in the other two eips. We already provide this npm package, which is open source. All the code is is uh of open in GitHub, so you can use the package we already. We also provide evm template installs this package in hardware and all the tools that you need. So it's really easy to start developing and using these contracts.

C

This all these ercs the same way as you would do with uh installing open Zeppelin package and importing their implementation of ERC 721. With just a few lines of code. You can deploy a contract using that we do exactly the same with each of our ercs. This package already has four erc's in final, which is the multi-azid nestable, this equippable and the non-transferable and here in the package.

C

An important thing that we do is that we have an extension between non-opinionated and opinionated implementations, so we provide for each of the packages a core version where we don't make any assumptions on how you want to use the things like how you want to Mint or burn or any other gating or restrictions that you may want to add.

C

So if you want something more specialized, you can build on top of that, but you don't have to reinvent all the wheel, just the final parts and we have three opinionated implementations, which are absolutely ready to use you just deploy that setting the like Max, Supply symbol and name and contract metadata, all this stuff and you're ready to go just with a few lines of code. All these packages uh highly tested, it's close to 100 coverage in different ways.

C

It is measured and this project implementation is already being used by different games in evm, such as next holders and everloot and I. As I mentioned. This was a not the evm implementation, but a nice example of how memory tracking can be used for governance was done in kusama and we could use exactly the same on any chain. Also.

B

I just like to add one more implementation, which we're kind of super excited about that we just went, live on Monday right, so all of our ercs are also implemented in singular Marketplace. So or you know, if you have multiple assets, if you have nestable tokens that can also also be seen there. So there is also already a Marketplace that supports our erc's nice.

C

Nice reminder okay, so what tools do we have? For example, we have extensive documentation of this ERC and all the implementations and extensions and utilities we have in the package. We have some video tutorials of going to the creation of uh an advanced nft collection using 60 to 20, 60, 59 and 5773, and also 64 54, which is for non-transferable. We had a few developer Journeys where to share more focus on how to interact with the contracts we have.

C

The GitHub template I mentioned we're just Fork it and you're ready to go, and the thing I always like to make emphasis on is the forward compatibility. When you build something with any of these ercs, you don't have to know beforehand all the options, all the functionalities that you want to have because can add more tokens, add more assets, configure new ways to equip the the items into the others. So this is the more powerful thing. In my opinion,.

A

C

Is this EIP unique? So first thing is that it works with any type of asset. We always give examples with images and mostly gaming, because it's the most common thing for nfts and it's the easier to explain, but you could have, for instance, an nft which is a Bass track for music and you can have different nfts. For instance, one is the base and one is a guitar, and since uh we well in our implementations, we use an ERC also for Realties and as in the marketplace, the Jan mentioned singular.app, we pay nested royalties.

C

So this is really cool because, for instance, artists which create music could bundle their nfts like they could equip uh different, sounds into a Bass track, and then they list for sale in the Bass track. And when the nft is sold, we will pay royalties to each of the nfts, not only the base, but also the children nfts that are attached and equipped into it according to to the interface for royalties, which is widely used.

A

C

Other thing that this is called Jan already explains that all this is kept on chain and being a standard people don't need to do custom stuff for it if they agree and they like this standard, they can just start using it and start using it, and you could create equippable nfts, which, in the future, will help will be rendered in most marketplaces, at least in the most important ones, without the need of a centralized party or custom logic.

C

I also explained how nft has become valuable, as they add more compatibility, or they do collaborations with other projects. I think this is something very cool. Jan also mentioned how you can reuse assets, and one thing he didn't mention is that this is huge for gas savings, so especially Unitarian we know gas is is a huge problem, so it's really cool, because we just want to uh like every single part that we add or every asset for for the equippable parts. It just needs to be added once so.

C

For instance, one thing that we see in nft projects is that they have different traits like, for instance, different, skin and differing arms and and legs and heads- and it's like I, don't know eight to ten parts and each of them has 10 options. So let's say it's 10 parts with 10 options. We upload 100 part fixed Parts into the catalog, and that's it. We don't need to upload anything else.

C

All the other assets for the for each of the nfts can be composed by cherry picking which of the arms which of the heads which of the legs from the catalog. So they can also be done randomly, for instance, and without no need for for additional logic or to create the the assets then offline to upload the combinations and it's the same with slot parts. So, for instance, I may have, uh as I mentioned a sword that can work well for different projects.

C

I just need an asset and I just defined in what slot it should go. So the the different projects can also use this like set of rules that can be defined in a catalog of which collections can be equipped into wish Collections and to wish slots, because we don't want, for instance, to equip a sword into the helmet slot. It wouldn't make sense right and we don't want them to us to equip more than truth more than two swords.

C

So all these rules can be defined a single time on a catalog, and many projects can reuse it and, at the same time, I can have a collection which uses a catalog for one thing and uses another catalog for another thing and then a third for here's another thing, so it's very flexible, okay, I think I mentioned their own chain, Advanced and chain logic and again forward compatible. It's my favorite things from the Erp I think we can move forward here.

B

Just to jump in again so the ERC for royalties that we are using is 29.81. yeah.

C

So all our implementations that I talked about in the package they have by default this or royalty standard.

B

Okay, so let me conclude this by talking about our EIP process for 60 to 20.. So when writing this proposal, we learned that less is more, so we prepared quite extensive assets, which is basically example, implementation uh with a lot of tests and a lot of dependencies that you could use to just you know: copy paste, the assets, folder and start building your projects from there. But we had to purge that, so we ended up with only the most necessary smart contracts and simple tests and that's okay.

B

We get why it should be like this, because you don't want to bloat the example repository and you don't want to blow the folders of the people that just want to run simple examples, but yeah. It took three proposals to learn that.

C

Now you may add something there, yeah yeah, of course, so one of the reasons we we started, removing a lot of the 9 functionality or utilities that we had on this ERC initially was actually gas size like contract size limitation, since this ERC Builds on top of other two ercs and for implementations. We also use, for instance, ownable, and we use the like ERC 721 metadata and we use royalties. So when we start adding all this logic, we started getting dangerously close to the size limit on evm chains.

C

So that was one of the of the purposes of the reasons we started trimming but, as Ian said, yeah less is more. It's it's usually better to have the minimal interface, which is powerful enough. So it's like a trade-off. We're always looking for, but uh one thing, I didn't mention and I think I haven't mentioned about the package is that among the utilities that we provide on our empm package is that we have different render utils.

C

So these are utility contracts that can be deployed just once per Network and they provide a bunch of utility functions which are just read only but make it very convenient for from end developers. So, for instance, on on the multiasset EIP, we have a price. We have assets which have different priorities, but we don't have a way to get the asset with the top priority directly from the contract, because that that would blow that would it's an unnecessary thing for the interface.

C

So this there's a render util, which we'll call the or get all the assets get all the priorities and get the top one for you and for equippable we have a really cool functionality that will compose an nft by reading all the children. Reading the catalog and reading the assets for each of the fixed bars and Slot parts, and when there are slot bars that mean a child can be equipped into there. So it will read the asset of the child.

C

So all this we're trying to make it as easy as possible for front-end developers and smart contract developers. Also, so that's something you may want to look at it's on the remark. Utils equipment in their YouTubes I think it is, but then you will find other YouTubes there.

B

Yeah, so this is something that we've been doing. Also, we have two implementations of year, 6220 one is merged and another is split. So basically, we further split the operation into an additional smart contracts that nestable and multi-asset parts of equippable smart contract are separate.

B

In this way there is more space for custom logic, but what I was talking about in less is more was you know the assets folder that you add to the to the proposal, because this was The Proposal that wouldn't get interdraft if we didn't remove them right, so I remember, uh Panda, looked at our assets and.

A

B

It was basically a complete project, a hard hat project using 60 to 20, ER, c6220 and yeah that that I was talking about here or so, and less is more. So. Basically, we we needed to tone down, because we had quite a lot of you know. Prettier options and I know that our hard hat config had a lot of configuration that would allow you to run gas, profiling and stuff like that. So we removed a bunch of configs and stuff like that.

B

So right now it's just you can compile and you can run tests and that's pretty much it and another thing that that kind of stood out compared to our other eaps, with no activity in the discussion Trend. So we might have gotten discouraged here because you know if you don't get any feedback, that either means that you weren't clear enough when writing a proposal or that it's too complex to be explained easily. But what gave us confidence to push through is that we have projects implementing with 60 to 20..

B

uh We've talked to the developers that implemented it equippables before going into the EIP process already, and we we've had experience with equipping from polka dot ecosystem. So we we kind of had this feedback from the developers and from the users that this is useful and they want to use it. It's just that it probably got drowned by a bunch of threaded threats that got opened when we posted, and this way we didn't get any any feedback on it. Recently.

C

On on the threat of another proposal, we saw someone asking if they could do if they could equip nfts into another one. So I mentioned this ERC to him and he seems really happy with it. I think. Another thing that happens is that people don't expect nfts to be able to do so much so, but it's it's a good problem to have anything. Yeah.

B

Yeah I agree, I, I I mean definitely and that's why we're here right? That's why we're we're talking about erc's every week, not just us, but the authors as well, the other authors as well right. So hopefully, hopefully more people learn about it before it goes mainstream, wishful thinking or reality we'll see but yeah. So we also prepared the link through with additional resources and handy links.

B

So you know you can either scan the QR in the presentation or you go to link3, slash, ERC, dot, remark and there you have the links to all of our erc's and our EIP. That is still not finalized. A link to the template repository a link to the npm package to the documentation on how to use all of our ercs and other extensions and various guides from you know how to develop the smart, the smart contract using solidity to usability using typescript once you deploy how to use them.

B

Steven has a really nice YouTube series about our Legos as well, so yeah feel free to look further and with that I'd like to thank you for your time and as always, we're available Twitter we'd like to talk about erc's eaps. Whatever questions, considerations or complaints, you might have, we are ja, underscore Jan Turk, and it's like that. Zero and we're looking forward to talking to you.

A

Thank you. Thank you so much as usual, I love the presentation, the documentation of EIP and truly appreciate your effort to increase awareness of available standards and the npm packages. They are really great support for other developers. We have heard a lot of words about the standardization process, some encouraging some, not very positive, but I'm so happy to see that you stayed with us, not one, not two, but over five proposals to the repo. That's really great.

A

We are hoping to create a page at ethereum Caterers website to maybe share more information about eips I was going through the presentation, and you mentioned about projects already adopting this proposal, so it would be nice to have it listed and make this information public. So people can.

C

A

Reach it and may be able to use this proposal for their projects. One other thing that you mentioned I I made a note of that is like less, is more I. Think probably it's enough. Definitely for an EAP, because when we are trying to have an EIP, we want the proposal to be short, so it could be. You know, moving forward easily. It should not have a lot of complexities around. So that's a good thing and I would say that we should not consider that to be a reason of not getting a lot of feedback.

A

Probably it is clear enough. Don't get confused that it is not clear but yeah I. Think probably it was clear enough because it was like shot and we already had learned a lot of things, new things: the concept of nft 2.0 with earlier proposals, I'd.

B

Just like to add a note on the length of the proposal or extensity of it and how it compares to the time needed to go to final. This one was relatively long proposal. I mean it contains a lot of data, a lot of specification and the process went smoothly really smoothly. So we could have had this proposal finalized about probably two months earlier.

B

We just wanted to wait because we were building an indexer and we wanted to make sure that all of the events are there, so that marketplaces and wallets can properly present equippable tokens compared to erc's 6454, where we started with a single method. We ended up with two, but that one actually had way more discussion. It took way longer to finalize and way more effort to finalize than the longer EIP right.

A

And there is an interesting part when a proposal comes with some of the eits is required. It cannot be moved until all of those proposals which are in required section are in final, so that is another case. Probably the time it took was good enough and I am happy to see it. It was less than six months, so that was incredible. Like people say a lot of words about duration, that it takes, but doing it in less than six months was great great. To have.

B

Honestly, it's at some point. It felt kind of you know that it's taking a long time, yeah.

A

Believe me, I have seen proposals waiting for years here so for this, like the entire team, I mean kudos to you guys you have been showing in multiple. um You know, meetings that we organize for EIP editing office hours, showing up here to talk about the proposal and do whatever is needed. I have seen you guys active on fem as well like responding to it and even following up for review process. Those are great things because we say this EIP process is ordered event process.

A

If it author is around, we will be able to push the proposal because we want a standard to be created, so it can be used. So we want to make sure whoever is champagne. The Proposal is around that's great. That's great thing to have here. uh You did mention about proposal 2981, uh that is, for royalty standard, I'm, happy to share that we had the author of The Proposal Blaine Blaine Malone, on our show to talk about this proposal.

A

This I think is one of the earlier proposal, which is good for having a royalty so good to know that you are also implementing existing standard to kind of build projects in association with proposals you are proposing here, yeah.

C

One thing I would recommend to people who are trying to propose on a proposal. A new ERC is to to go through the list of erc's, even in the discussion and search for some keywords like if you go to to the ethereum. The slash ercs I think it is by looking like nft is our soul, Bond or composable, or these kind of things you can know if there is already something.

C

So it's ideally, we don't want to reinvent the wheel and to have many similar, erc's and I think that's also part of what you guys do from The Cottages, but yeah. Just a good thing to keep in mind before you put too much effort into something that maybe there's already something better out there and it's I know it's hard to to give up what you have done to jump onto another train. But it's it's for the best. I think.

A

Really good suggestion XP against matters, I think with the presentation we have got answered to many questions that I had on my list. uh I have a few more probably I can take some of them. One thing that I would like to understand: it looks like the slot type of Parts, like a slot type of Parts fixed type of Parts. They are optional. Are there any? um You know suggestion for project developer like who should be using both or is it always recommended to use both in the implementation? No.

B

So we don't, uh you know, we don't enforce the use of either so you can use slot types. If you just want the ability to Nest other nfts, it is predefined positions or you can use only fixed types if you have multiple different trades that comprise the base nft and you want to use that or if you know you could use both if that makes sense, it's it's important to identify which work for you and that's how we design all of our proposals.

B

We give you the ability to so we give you the the ability best of our ability to do as you wish so similar to what we talked about two weeks ago for uh masterable ERC there we have Nest transfer method that can do six different, different things and you can decide which of those six you want to support, or you know, if you don't want to support some, you don't need to allow them. So it's similar here we don't require.

B

So if you are using our standard, you need to have slots and as well as fixed Parts, you can just have either or both one.

C

Thing to newcomers to people who's just getting to know 60 to 20 to identify if they need fix or slot Parts. uh It's really simple. So if you're trying to compose your nft from different parts and when you build it, that's it and it won't change. Then you want to use fixed Parts. If you want to Define slots or like places or placeholders to where other nfts should be able to be equipped, then you want the slot parts. So that's that's the basic difference and of course you can use both.

A

That's a good summary of it. Thank you so much for that. My next question is with respect to the catalog or suggests that the proposal use catalog instead of supporting direct nft equipment, I understand, probably it is helping us and verification, and also in defining the function. Do we see any kind of trade-off or any downside of not using direct nft equipping here I.

C

Think the one of the powerful things that the catalog provides is that it helps you define rules. So it is you as the collection issuer who Define or if in the catalog owner, will Define what can go into your nft. So it is I cannot just simply go and say: I want. I will put this sore on top of this Punk, because I want it and I own both of them. It doesn't work like that.

C

We want always holders to have the power of not of their nft, not being altered without their approval, but we also want to give issuers the way or the power to guide how they want to use their things. So, for instance, as I mentioned earlier, we don't expect a server to be equipped as a helmet because it doesn't make sense, so it also having these rules also helps a lot marketplaces and wallets who want to showcase or display these nfts to know.

C

For instance, if you have a parent token in their children, you can easily search through the catalog or the render YouTube that I mentioned, where it can be equipped. So it's it's really important to have a set of rules of a basic set of rules, so so people don't do mess things. That's.

A

Good, that's good to know yeah, it's important that whenever we are choosing alternative over something, then we should have like solid backup reason for that why we are doing that. So it's good to know that.

C

Initially, at some point, the catalog was part of the same equivalent, all contract, and but this was like over a year ago. So we saw that like because we saw the need of the catalog, but then we saw like well what, if we take it out, then more people could reuse it so that that was the a step forward. An improvement uh back then and I think that's as I mentioned, I. Think on nestable's presentation.

C

That's one of the of the things that helped us more during this process and it's the fact that, although it's a valid to just arrive to the Forum with an idea in a draft in the community will help you build it. When we arrived to The Forum with our draft, it has been tested for over a year in a in another blockchain, and we have been working on the AVM implementation for also about a year so yeah that that was pretty helpful.

C

And, of course we saw some improvements and that's it, the Beauty and the objective of the Forum. But there were really there were really big changes. Due to that.

A

My next question is with respect to other proposals. Other composable nft proposals, which are there in their repository I'll, be curious to hear your thoughts if it is up to you, which will you promote to move towards final ERC, 998, composable, non-fungible token standard ERC, 4883, composable, SVG, nft, ERC, 5633, composable Soul, bound nft, EIP extension. 1155.

A

um I would also like to hear your thoughts like. Why would you support any proposal? If you do okay,.

C

I know the first two, but not the other, so 998 was what we found when we were going to propose nestable and it had some of the features that we wanted, and it also had some other features like hold in years 20s.

C

But the way they did it is that they did Define an interface where, if you wanted an nft to have children, if there was an interface or if you wanted an nft to be owned by other, you define on other interfaces and what we found on the creation of our nestable proposal is that you need the interactions like the the governance to be only one way, because you cannot trust both parties.

C

If, if we gave per power to the children and I, receive a malicious child nft, then it could affect the parent token that I own. So that's why we were discouraged to use it and also because it's like trying to solve many things at the same time like it, proposes four interfaces, so I I'm not sure that that's the best spot to go. I think it should be one thing at a time and well.

C

The other thing is that when we arrived there it was already uh stale like there was no activity for a while and I think there hasn't been any so with 60. 59 I actually don't see a reason to move forward with the other with 998. uh the other one about composable, svgs I, think it focuses more on metadata and and well it it's fixed. Only on like it's limited to svgs, whereas, for instance in multi-asset we can work with any type of asset and same with equippable, but yeah I don't know.

C

Maybe if your use case is only svgs May, maybe it could be simpler and the third one I'm not sure I know it I think I saw it, but I don't remember what the interface looked like.

B

Yeah I just checked it so it basically, uh the interface defines a single event. Called soulbound and function is sold one. It doesn't really compose nfts. It doesn't really compose uh 1155 tokens, it's just ads on top of them. So.

C

It's maybe that's a question for for when we present a transferable EIP, but.

B

We have an answer.

C

Sorry yeah go ahead.

B

Yeah yeah I I agree. This is uh kind of similar to what we did for 6454. We. We also have opinions on that, but I think it's best to to kind of save, say something so that you'll you'll invite us back to talk about transferable interface for non-fungible tokens. That's.

A

A smart and uh thank you for that as well I, understand proposal 6220 by number. It suggests that this proposal came later. The earlier proposals that I just mentioned was definitely something missing. That's why it was not moving proposal. 5633 is currently in stagnant status. That means we do not have author around and probably nobody is making any effort to push the proposal. However, a proposal 998 and 4883, but they both are in draft status, now uh looks like they. There have been some effort to resurrect the proposal and to push it forward.

A

So I thought it would be a good idea to collect some feedback and make sure that when these proposals are moving, we do have a solid reason to push that towards final, just not because it is proposed here, So yeah. Thank you so much for your feedback on that. It's almost time to wrap up I'll be curious to collect some word of advice, your thoughts or message that you have for the community here.

B

We've done that two times before so uh I kind of need to think about it, but uh I do have one which, which I just just came up with, so it would be to for the authors.

B

If you have more proposals, you know uh layer uh layer, the content when talking about your proposals, uh you know um focus on one I'm talking about people knee pair I get that I was confusing, so you know do not over share so that you, you can talk about the next one on the next episode that you don't you don't talk about in the next one, oh now, I now and I am just cycling, yeah. Basically what I said before like we will tell you what we think about the 56 33.

B

When we talk about our transferable interface, yeah.

C

Have a couple of things in mind, so our recommendation to URC proposers I I've been really active on the Forum and I I try to see what's new and what is not necessary. What would be good to have good to have- and one thing I've noticed- is that some proposals do not have do not include the interface which I think it's it's pretty like a minimal thing.

C

You should have when you're, using when you're, proposing an ERC and also many of them don't have a sample implementation or they have a sample implementation, but data they have no tests, so that doesn't give the best image and it makes it less easy to review and to give feedback. That would be my my recommendation for proposers and for builders in general. So this past year that I've been working with nfts, we've really been expanding.

C

The barriers of what technology can do on the nft aspect and it's been really really exciting, because every now and then either we get a new idea of how we can use these VIPs or people come from the community to ask us if some were random use case. Could be possible in and we find we usually find a way how it can be done. So it's really exciting to work with these ercs, because we're building the future we're pushing the barriers of technology and I. Invite you to be part of that very.

A

B

So I would just like to piggyback on that one. So I I think that Stephen kind of undersold uh our ideas, how to to bring nfts 2.0 to live. uh So we get new ideas weekly and at this point.

C

B

The ones that help Community the most and our ability to actually implement the implementation test them out then write the proposal and so yeah uh we'll probably be publishing another one and about a week or two, and then we all already have another one planned so or we won't leave uh editor hours just yet and another thing that you mentioned Stephen and I think it was really good. It was about the example implementations like the missing example implementations, or rather the missing tests, so example.

B

Implementation is really important because you show how to implement business logic based on the interfaces that you specified in The Proposal, but tests actually give you the Insight on. You know the life cycle of the action so which transaction should be taken in order to use certain features of the proposal like you know, if we have um so for ease of use, I'll use, nestable tokens because.

C

B

Basically, there you transfer the nft to the new parents NXT, and then you accept that new child nft into active children. So you have two transactions to kind of appointing child and in test. You can see that we can write about this and we can say: hey use those function, but in test you can actually see that in action, it's way easier to look at two lines and see what happens two lines of code and see what happens. Then.

B

You know having to go through two paragraphs or specification and then go look at the specification of the interface and figure out how all of this Dives together yeah.

C

Even just by the definition of the test, like the behavior you're testing, it's super helpful. That's actually how I started working with all these crcs by looking at the tests and writing more tests. I could start getting a good idea of how it worked so yeah, plus one on tests absolutely.

A

We are also considering uh this I, don't know if it can be a formal part of requirement of having a proposal move towards the final status, but it will be always nice to have to have tests added, so it can be helpful for implementers. Well. Thank you for this. The piece of advice, nft is a pop popular use case of blockchain having standards on composable nft and many more probably will help app developers make their life easier, with a hope to see increased adoption of this proposal.

A

I would like to thank Yan, Stephen, Bruno and team Rima for proposing multiple ethereum standards for a contract developers, and on this note, thanks to everyone watching or listening to nft special episodes. Should you have any question on this or any other proposal do. Let us know in the comment section reach us at the Discord check out description for links to useful resources and guest Twitter to follow we'll be back with another interesting proposal overview soon till then keep watching keep sharing your love with Italian cat hurdles, cheers.