You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As suggested by @aishairzay in #28comment, the bridge should enable projects to specify their own ERC721 symbols. However, there isn't a standard metadata view that includes a symbol field. One such view was proposed for review, but it can't be counted on that this view will be immediately or even widely implemented if accepted.
Suggest A Solution
Require projects implement the proposed view to specify their symbol. This would be least preferable as it would prevent bridging NFTs that don't implement this view.
Derive a symbol based on the fields that are accessible. This could be done on the first n sanitized values of the NFTCollectionDisplay.name value so ExampleNFT Collection where n == 6 would be Examp. This is also not ideal, but at least provides some notion of an identifier. This could be taken further, removing vowels, lower case all characters, etc.
Assign a random symbol defined from a random string derived from Cadence's runtime randomness at the time of bridging. Again, not ideal, but it preserves the permissionless nature. This could be done with a simple util method like
Assign the same symbol for all bridged NFTs unless otherwise defined in EVMBridgedMetadata. This is certainly not ideal as I'd imagine project want to avoid having the same symbol as others.
Since the symbol isn't as important for non-fungible as it is in fungible tokens in all existing products I know of (since they usually just use the full name of the NFT collection in most display references), I am okay with either option 2 or 3 you put up there. I think i'd go with #2 (take first n characters).
We should definitely still support and document an optional way to set the symbol yourself in a view though.
Completed in #52 according to @aishairzay suggestion - slicing the first (up to) 4 alphanumeric characters from the defining contract name. We may revisit this approach in the future when we have some user feedback on which to better inform the decision path forward. For now, the implementation unblocks NFT bridging for those without a symbol defined.
In addition, EVMBridgedMetadata was merged in onflow/flow-nft#203 and the MetadataViews contract has been updated to include it on Testnet. Next steps include folding that view into NFT documentation and guides.
Issue To Be Solved
As suggested by @aishairzay in #28 comment, the bridge should enable projects to specify their own ERC721 symbols. However, there isn't a standard metadata view that includes a
symbol
field. One such view was proposed for review, but it can't be counted on that this view will be immediately or even widely implemented if accepted.Suggest A Solution
n
sanitized values of theNFTCollectionDisplay.name
value soExampleNFT Collection
wheren == 6
would beExamp
. This is also not ideal, but at least provides some notion of an identifier. This could be taken further, removing vowels, lower case all characters, etc.EVMBridgedMetadata
. This is certainly not ideal as I'd imagine project want to avoid having the same symbol as others.The text was updated successfully, but these errors were encountered: