HIP-17: HTS Non Fungible support

[kenthejr]

This discussion is designated as the discussions-to target of hip-17. Use this thread to further develop the HIP and move it through to its final lifecycle state.

[ijungmann]

Will the serial numbers be randomly generated, incremented, or defined in some other way? And will they be globally unique, or only unique to their own token types?

[kenthejr]

It's my understanding that it will be incremented and thus unique to the token type only. @Daniel-K-Ivanov can you confirm?

[Daniel-K-Ivanov]

Yes, serial numbers will be incremented and unique per Token instance

[bugbytesinc]

Serial number as an int64 seems to restrictive, why not an array of bytes? That will make it easier for integration with other systems without having to create a (possibly untrusted) mapping of asset hashes to integers.

[bugbytesinc]

As an alternate, why not use Shard.Realm.Num mapping instead - the whole of hedera uses this for identifiers. That way the NFT would be uniquely identifiable in the whole of the DLT.

[ijungmann]

Are there any details about how NFT balances will appear in the balance file? I assume the structure will look something like GetAccountNftInfoResponse

[Daniel-K-Ivanov]

That is a good question. I will update the HIP once we have more information/clarity on the approach that we will be going for

[Nana-EC]

How will we capture shared metadata amongst serials of the same token type?
I'm leaning towards a shared metaData (non-memo) field at the token level for NFT's and a separate serial level (non memo) field to capture the unique details of the serial.

[Daniel-K-Ivanov]

Capturing shared metadata amongst serials of the same token type can be done by utilising the memo field on the Token level. As far as I know, the intention behind having memo fields on every entity is exactly for that reason.

The metadata on a serial level is captured with a memo field. At least that were the intentions so far. I think that the topic of memo vs meta is brought up a couple of times. Adding it for discussion

[Nana-EC]

Yeah. I think they should be broken out for more flexibility as memo is general purpose in definition and metadata at least in the space of an NFT has a certain intent and expectation behind it. There will be cases where users will want to capture both intents cases.

[bugbytesinc]

Why deprecate new protobuf functionality just released and complicate it with a union structure. Why not have a DestoryNftTransactionBody instead of rewriting TokenBurnTransactionBody? I am concerned about the inconsistencies in the suggested changes to the protobuf, in some places this hip overloads and changes existing protobuf, but then in other places add parallel functionality. For example, the TokenWipeTransactionBody is re-written with an union overloaded implementation, while transfer list adds nftTransfers field, which is only for nft type tokens, fungible token transfers are required to use the present protobuf. These inconsistencies will leak into the SDKs may lead to confusion by parties attempting to use them. An NFT is not the same thing as a preexisting fungible token.

[steven-sheehy]

I agree with you about the breaking change of using the oneof. I suggested we flatten it and make it non-breaking. This is why there's an open question for this item in the HIP.

[Daniel-K-Ivanov]

The following conclusions based on IWA specification have been outlined:

• unique: needs separate state object to represent it (f.e MerkleUniqueToken); Must have serialNumber to identify the representation.
• common: We do not need a separate entity to represent it. There are no serial numbers.
• fungible: Transfers must be specified by amount and not serialNumbers
• non-fungible: Transfers must be specified by serialNumbers

When it comes to implementation:
Common Fungible - What HTS represents at the moment.
Unique Fungible - There are performance challenges in implementing it since every unit of the token must have a serialNumber (identifier) and an owner. At the same time, the owner can choose to transfer amount 100 thus the owner of those 100 serial numbers must be changed to the new one.
Unique Non-Fungible - There are 3 options use-cases here:

1. Singleton - There is no problem in terms of implementation. It is represented by Leemon’s design and that was the direction that we were going for initially.
2. Whole - Same as Singleton.
3. Fractional - Significant API changes are required (defining new types of transfers and querying for balances). The design presented by Leemon does not support such types of tokens. It is questionable whether we should add that support at all. Example:

The following use-case goes to Unique Non-fungible, Fractional:
1. TokenEntity represents building
2. Each UniqueToken minted represents an apartment of that building
3. Each UniqueToken has "shares" and there might be 5 owners, each owning 20% of the UniqueToken aka NFT
 Even in the TokenTaxonomy framework, they are stating that additional thought is required to figure out whether it wouldn’t be better to create a separate TokenEntity for each Apartment and have the shares represented as a fungible token, instead of using this structure

Reference: link

The team is going forward with the following plan:

1. Continue with the concept of COMMON / UNIQUE and FUNGIBLE / NON_FUNGIBLE
2. Focus only on Common Fungible, Unique Non-fungible Singleton and Unique Non-fungible Whole
3. Do no implement Unique Fungible and Unique Non-fungible, Fractional in this upgrade of HTS as it will require a lot of design work and will push the delivery with quite a lot

There are still open questions related to overloading vs adding parallel functionality that will be discussed further. In this update, we are describing the concepts that we will be introducing in terms of redesigning the Store(s) in hedera-services in order to prepare for a more flexible HTS service

HTS - Types.pdf

[ijungmann]

Considering the discussion around potentially supporting fungible unique tokens in the future, should some of the protobufs that reference NFTs (GetNftInfo, etc) be renamed to be more general, like GetUniqueTokenInfo? I would expect getting the info of a unique fungible token would look mostly identical. We're having the same discussion on the mirror node side regarding future-proofing the naming conventions.

[topshef]

What are some of the use cases for serial numbers that are better served by this hip rather than a layer 2 solution?

[topshef]

Example: NFT "LAND" by Animoca's Sandbox has parameter X and Y attributes (position of the land) which presumably could be mapped onto a serial number

[ijungmann]

How will an NftTransfer appear for minting, burning, etc. where there isn't both a sender and a receiver?

[ijungmann]

For an NFT mint, if I send a list of 10 distinct metadata fields and get a receipt with 10 serial numbers, is it guaranteed that the order of the 10 serial numbers is the same as the order I listed the metadata fields in? If not, is there any way to determine which serial number matches which metadata?

[bugbytesinc]

It just occurred to me it may be wasteful of resources to MINT a token with one transaction and then have to execute a second transaction to TRANSFER the token to the desired account holder. Should there be an option to mint a token directly into the target account (assuming association)?

[baxterjfinch]

How do I properly set metadata with this new NFT flow? On previewnet, I'm trying to call tx.addMetadata(["arbitrary_string"] but my transaction fails with failed precheck with status INVALID_TRANSACTION_BODY. I'm using TokenType.NonFungibleUnique and TokenSupply.Finite for my Token Type and my mint function is simply

const tx = await new TokenMintTransaction();
  tx.setTokenId(token.tokenId)
  tx.setAmount(1)
  tx.setMetadata([`test`])

[ijungmann]

You do not need to have tx.setAmount(1), amount is only applicable to tokens of type FUNGIBLE_COMMON, and having a mint transaction with both amount and metadata will result in the INVALID_TRANSACTION_BODY you're seeing. Remove that line and see how it behaves.

[cmdhema]

Anyone have an idea about 'approve' function on the ethereum case? I think it is necessary function for NFT marketplace case. I think improving 'AssociationTransaction' or implment new TransactionType just like 'ApproveTokenTransaction'. I think the latter is better.

[gregscullard]

You can mimic approvals by setting up a multi-sig account with a 1 of 2 threshold key (1 key is yours, the other is the key of the person you are approving) and transfer the number of tokens you wish to approve to that account. The holder of the second key can then transfer tokens from the shared account up to the amount held in the account.
You can also then revoke the approval since you can move the tokens back from the shared account to yours.

I agree it would be neat to have the feature at the token level, but this is a workaround that works now (and can even approve to multiple people at once with more keys in the threshold list ;) )

[cmdhema]

Hello @gregscullard I thnik so too. I also thought of a way to use a threshold to allow the marketplace operator to transfer token. I think this is so centeralized way to solve this issue. Also, there is a security or coding mistake issue by the developer.
Moreover, without 'approve' function (ethereum side function) It is hard to 'sell NFT' on multiple Marketplace.

If we implement these shortcomings, we will be able to make HTS more comfortable and safe.

[Tinyhbar]

How does someone who is buying an NFT know that the NFT was produced without limiting constraints.

For instance, how do I know that I bought painting, then unbeknownst to me it was actually just an NFT that gave me permission to use a painting for a week. There needs to be some clarification on the part of websites that sell NFTs, declaring the user rights, or subsequently clearing the site selling the NFTs. There WILL be court cases about this.

OR

There needs to be more than 1 type of NFT. One that is PERMANENT, and one that is CONDITIONAL.

[pckrell]

This is why the legal works will be as important in the different territories than the technology development work. The art is to create legally working contracts for each territory. And still there will be discussions. One would also have to define who is liable in cases of service lacks and there might be insurances covering any to be expected losses. Maybe Deutsche Rück...

…

Tinyhbar ***@***.***> hat am 03.12.2021 12:26 geschrieben: How does someone who is buying an NFT know that the NFT was produced without limiting constraints. For instance, how do I know that I bought painting, then unbeknownst to me it was actually just an NFT that gave me permission to use a painting for a week. There needs to be some clarification on the part of websites that sell NFTs, declaring the user rights, or subsequently clearing the site selling the NFTs. There WILL be court cases about this. OR There needs to be more than 1 type of NFT. One that is PERMANENT, and one that is CONDITIONAL. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub #74 (comment) , or unsubscribe https://github.com/notifications/unsubscribe-auth/AHWAUBFIDCUIW666ICM7KC3UPCSM5ANCNFSM43TC4BRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

-- Peter C. Krell (M.A.) Friedrich Wilhelm Str. 12 12099 Berlin 0157.30911250