BEP 7: Bring Non-fungible Tokens(NFTs) to Binance Chain and expand the use cases.#7
BEP 7: Bring Non-fungible Tokens(NFTs) to Binance Chain and expand the use cases.#7amazingandyyy wants to merge 28 commits intobnb-chain:masterfrom
Conversation
|
It reads to me majority of the BEP is the same as the BEP2. It will be more clear and usable to highlight the commons and differences from BEP2, which is more friendly to readers and tells details for implementation and usage. |
|
@darren-liu I change some contents in the past week, the biggest difference here
|
i'm worried about the requirement of incremental id. In the spec you list ID as a string but incremental IDs make me think you imply to change to int. There are many projects which will need more fine grained control over their ID system. ERC-721 handles this well by allowing tokens to be queried by index while not requiring the token IDs to be incremental. For example I have a game where I encode some item information into the ID itself, this is a convenient way for me to store information about the NFT without redundant storage costs. Or another example might be NFTs that represent in-stock items that already have their own alphanumeric id system. It would be redundant to have multiple IDs per item and the app designer would prefer to use the same ID on both systems. For this reason I'd suggest allowing IDs to be string but create an additional qeuerier that requests information about denomination and the index of the NFT. Furthermore this could be extended into a full pagination with an index and a limit to access multiple NFTs incrementally while still preserving choice of ID. |
|
For reference here is a summary spec of the Cosmos-NFT Module: |
Moved to cosmos/cosmos-sdk#4766 |
|
@casmirconsensys I can see one major thing is unclear is about the chianId, may need to have eng from binance come in and give their idea of cross-chain/IBC/cosmos...etc technical details on this. |
|
Here's the technical diagram from the call today. This relates to lower level implementation but also brings up some of the Msg Types that a BEP-7 NFT might want to use:
|
|
Summary from zoom call with cosmos & binance team on 7/31 12pm:
|
| | **Field** | **Type** | **Description** | | ||
| | :--------- | :-------- | :------------------------------------------------------------ | | ||
| | Denom | string | The symbol of a collection - e.g. NNB-B90 | | ||
| | ID | string | The id of a token in the collection | |
There was a problem hiding this comment.
Do you think the freeze period is necessary? If there is no freeze period, the owners can freeze and unfreeze their assets at anytime, thus the freeze operation will have no limitation for owners.
There was a problem hiding this comment.
Hmm I think this may be a layover from BEP2... Agree let's toss it if it's not relevant to BEP7
There was a problem hiding this comment.
@casmirconsensys why, I think freeze is a good feature.
There was a problem hiding this comment.
@HaoyangLiu Freeze period is a good suggestion, have any idea of what time unit it should be? (blocktime, block height...etc)
| | **Field** | **Type** | **Description** | | ||
| | :--------- | :-------- | :---------------------------- | | ||
| | Denom | string | The symbol of the collection | | ||
| | Amount | int64 | The amount is positive and can have a maximum of 8 digits of decimal and is boosted by 1e8 in order to store as int64. | |
There was a problem hiding this comment.
Is it necessary to have decimals for non-fungible tokens?
There was a problem hiding this comment.
hmm... unless its a composable ERC998 or an NFT like ERC1155 that can mint multiple ERC20 & NFT from the same type of contract if say for instance we needed to represent that in a Wallet perhaps maybe @coinfork from Enjin can chime in on how representation in a Wallet like Trust Wallet with Binance BEP2 could be a potential use case..? From what I understand some ERC1155 can have ERC20 like properties as well no? @coinfork
//ERC1155 Metadata JSON Schema
Assets made on the Enjin Platform may contain metadata that is based on the ERC721 Metadata JSON Schema. We are adding an optional formatting standard to this schema to increase efficiency for games that need to manage metadata for thousands of items.//
JSON Format
Example:
{
"name": "Asset Name",
"description": "Lorem ipsum...",
"image": "https://s3.amazonaws.com/your-bucket/images/{id}.png",
"properties": {
"simple_property": "example value",
"rich_property": {
"name": "Name",
"value": "123",
"display_value": "123 Example Value",
"class": "emphasis",
"css": {
"color": "#ffffff",
"font-weight": "bold",
"text-decoration": "underline"
}
},
"array_property": {
"name": "Name",
"value": [1, 2, 3, 4],
"class": "emphasis"
}
}
}
There was a problem hiding this comment.
@HaoyangLiu yea, I am thinking just use uint
casmirconsensys
left a comment
There was a problem hiding this comment.
Is this requesting for approval from @amazingandyyy?
|
yes, @casmirconsensys it will be great if this can get merged and the community can move forward to help |
|
@amazingandyyy Let's Do This!! Who else is on board to approve this thing? @okwme @zmanian |
What have we heard from Binance Eng about this so far? @amazingandyyy |
There was a problem hiding this comment.
@okwme thanks for the screenshot, I updated it on line 150 accordingly.
For pending comments, you need to click the right top green button (finish your review)
casmirconsensys
left a comment
There was a problem hiding this comment.
Would be nice to have some XML-JSX-TSX Metadata Schemas added.
|
outdate, archive it. |




With Non-fungible Tokens, we can expand the token use cases on Binance Chain to be:
Every token is transferrable, tradable, mintable, burnable and most important, non-fungible.