Discussion for EIP-3589: Exclusive Assembly NFT

[Ungigdu]

The following is a proposed EIP to assemble Eth, ERC-20 tokens, ERC-721 tokens and ERC-1155 tokens into one ERC-721 token with assets signature as token id.

The pull request is open here: #3589

[dete]

I think this is an awesome idea! I can see this being very useful.

I'm curious why it's valuable for this to be an EIP (with the expectation that there will be many implementations), as opposed to creating a single utility contract with this functionality for everyone to use. A single contract with this functionality – soundly implemented and unencumbered by fees – would serve this purpose for all tokens matching the applicable standards. That seems more useful than having competing implementations that would all provide the same functionality.

Am I missing some aspect of how this could be used?

[Ungigdu]

Hi, dete, glad to know you like it. There are two seasons for this to be an EIP. First, it uses ERC-721 token as a wrapper, so it is actually a token. Second, there may be ERC-777 or some other standards that I didn't include, so it may have many implementaions. But you are right, this design looks like an utility contract. May be you have better ideas?

[xinqiyang]

@dete Thank you for you like it. We will do some interesting implementations in NFT field. Looking forward to your guidance.

[poojaranjan]

FYI, creating a "discussion-to" thread at Fellowship of Ethereum Magicians is highly recommended as it would increase the visibility of the proposal and this issue may get closed eventually.

[Lenoftawa]

@Ungigdu Good initiative. The subject of bundles has been discussed as part of EIP-2981 - royalties for ERC-721 tokens. The problem is how royalty payments should be split between the items in a bundle. one of the solutions is to present them as a single ERC-721 token - exactly as you propose.

However, if some or all of the NFTs in a bundle declare that they support EIP-2981 then the total royalty should be signaled and be split between them. To allow a marketplace to pay the royalty, the EIP-3589 bundle must support the royaltyInfo() function and return the calculated royalty amount and the address to pay. This amount is the sum of the royalties of all tokens that specify it. To support this, the bundled NFT would need to:

• use EIP-165 to check to see if any of the bundled tokens support royalties
• call royaltyInfo() in each token that supports it
• return an address that will receive the payment and split it appropriately

Unfortunately, the bundle would be sold as a single amount, but the royalty needs to be split according to the relative value of each token. The agent assembling the bundle would somehow need to set this proportion - perhaps as an optional argument during assembly?

For ERC-20 tokens, I 'm guessing they would be assigned a proportion of the value of the bundle, but allocated no royalties.

[Ungigdu]

Fellowship of Ethereum Magicians

thanks, will do

[Ungigdu]

@lenifoti Thanks for mentioning it. I didn't think about royalty😅. I should find a way to add it.

[Lenoftawa]

The problem is that it would ideally need to be mandatory, because bundles wont know ahead of time if a an NFT in the bundle has royalties. I guess a bundle could choose to ignore royalties (not ideal) and the standard might just 'strongly recommend' that it also supports 2981. The problem then is assigning the relative values. This would need to be an additional function/argument, and that that would need to be defined in a standard way. The NFT values could simply be apportioned evenly.

[Lenoftawa]

@dete

A single contract with this functionality – soundly implemented and unencumbered by fees – would serve this purpose for all tokens matching the applicable standards.

For the purposes of saving gas by aggregating transfers, I agree, there appears to be no reason for more than one. Assuming that tokenIDs are minted and burned for the life each bundle.

For 'collections' on the other hand, I can imagine that the bundle itself could have some unique behaviour.

[xinqiyang]

FYI, creating a "discussion-to" thread at Fellowship of Ethereum Magicians is highly recommended as it would increase the visibility of the proposal and this issue may get closed eventually.

thanks，we will join in.

[xinqiyang]

@Ungigdu Good initiative. The subject of bundles has been discussed as part of EIP-2981 - royalties for ERC-721 tokens. The problem is how royalty payments should be split between the items in a bundle. one of the solutions is to present them as a single ERC-721 token - exactly as you propose.

However, if some or all of the NFTs in a bundle declare that they support EIP-2981 then the total royalty should be signaled and be split between them. To allow a marketplace to pay the royalty, the EIP-3589 bundle must support the royaltyInfo() function and return the calculated royalty amount and the address to pay. This amount is the sum of the royalties of all tokens that specify it. To support this, the bundled NFT would need to:

• use EIP-165 to check to see if any of the bundled tokens support royalties
• call royaltyInfo() in each token that supports it
• return an address that will receive the payment and split it appropriately

Unfortunately, the bundle would be sold as a single amount, but the royalty needs to be split according to the relative value of each token. The agent assembling the bundle would somehow need to set this proportion - perhaps as an optional argument during assembly?

For ERC-20 tokens, I 'm guessing they would be assigned a proportion of the value of the bundle, but allocated no royalties.

We will research about 2981 ！thanks！

[punk9975]

any updates? @xinqiyang

[imduchuyyy]

I think this is an awesome idea !

[MicahZoltu]

Since this EIP has become stagnant, we are closing this discussion issue for housekeeping purposes. You may continue discussion here on the closed issue (it won't be locked), but if you want to revive the EIP (bring it back to Draft or Review status), you will need to create a thread over at https://ethereum-magicians.org/ and update the discussions-to link in the EIP to point there instead (that is where all discussions happen now).