Metadata and royalty

[bjartek]

There is a pr in cadence to allow default implementations in interfaces. ( onflow/cadence#1076 )

There is a proposal to add metadata in https://github.com/bjartek/flow-nfmt

I feel that before this gets published those features should land. (How to structure metadata and add it to NFT via default implementation).That is there should be better metadata for nfts and some schemas that you can implement to create a nft agnostic ui for the storefront. Also a schema could be royalty. That is the nft itself and not the saleColllection has royalty (this is what we have in versus aswell)

Then versus could in theory use the storefront instead of our own marketplace contract.

[Droopy78]

I am very interested in both of the above topics. I feel like nailing down the Royalty standard in particular is critical to be able to deploy a global Storefront contract. I believe following the Ethereum design is a good base, but can use some modifications (for reference: https://eips.ethereum.org/EIPS/eip-2981)

A Royalty interface for NFTs (or a Royalty schema as mentioned above) could be honored in the Storefront using the same sales cut methodology. Storefront can type check if the NFT has the Royalty interface, and if so, add in the specified royalties to the sale cuts. Ethereum only allows for one royalty receiver, but in this case it could be split amongst an array of receivers as specified inside the particular NFT being sold (and enforced by the Royalty interface).

Per standard, royalties have to be specified as percentages since the royalties must be currency agnostic. So when the item gets listed, the royalty cuts embedded in the NFT being sold would be calculated and entered as additional sales cuts in the array. In total, sales cuts would consist of royalty splits + any additional sales cut splits passed during the sell_item.cdc transaction.

In theory, the Royalties % specified in an NFT could be calculated and honored in the sell_item.cdc (as opposed to inside the contract/resource code) to fit the current design of the StoreFront where all saleCuts (including royalties) are be passed together with no changes to contract code. Though I don't know if it makes better sense to enforce the royalties within the contract.

The biggest issue I don't know how to solve is what to do when the Royalty receiver does not have a fungible vault set up for the particular payment token type. For example, an NFT creator specifies a 5% royalty on their NFTs. The creator's account has vaults for FUSD and USDC, but then next year the NFT gets sold in a marketplace that listed the NFT in some other fungible token (and thus the marketplace attempts to pay the royalty out in that same currency to a receiver vault that is non-existent).

[bjartek]

Good points! In the versus profile contract I added a method to deposit any kind of FT that the profile has registered. Should there be a register for FTs so that new accounts could get them initiated when they sre created?

https://github.com/versus-flow/versus-contracts/blob/master/contracts/Profile.cdc#L328