Payouts standard #192
Payouts standard #192
Conversation
A flexible implementation of a royalty standard
| @@ -0,0 +1,58 @@ | |||
| # Standard for a Multiple-Recipient-Payout mechanic on NFT Contracts | |||
|
|
|||
| A standard for supporting structures that allow for NFT's to inform financial | |||
There was a problem hiding this comment.
| A standard for supporting structures that allow for NFT's to inform financial | |
| A standard for supporting structures that allow for NFTs to inform financial |
Apostrophe only needed here to indicate possession. We wouldn't write "Non-Fungible Token's," so we don't write "NFT's."
Change needed thoughout document.
| # Standard for a Multiple-Recipient-Payout mechanic on NFT Contracts | ||
|
|
||
| A standard for supporting structures that allow for NFT's to inform financial | ||
| contracts to payout multiple addresses on sales. |
There was a problem hiding this comment.
| contracts to payout multiple addresses on sales. | |
| contracts to pay out multiple addresses on sales. |
"Payout" is a noun; "pay out" is the verb. (Similar to "What's your login?" vs "Please log in")
| A standard for supporting structures that allow for NFT's to inform financial | ||
| contracts to payout multiple addresses on sales. | ||
|
|
||
| Currently, NFT's on Near support the field `owner_id`, but lack flexibility for |
There was a problem hiding this comment.
This is written from the perspective of the present, but is meant to be a reference document for the future. Should it be worded to tell people why they would want to use this NFT extension, rather than telling the repository maintainers why they should merge it?
| ownership and payout mechanics with more complexity, including but not limited | ||
| to royalties. Financial contracts, such as Marketplaces, Auction-houses, and | ||
| NFT Loan contracts, would benefit from a standard interface on NFT producer | ||
| contracts for querying whom to pay out, and how much to pay. |
There was a problem hiding this comment.
| contracts for querying whom to pay out, and how much to pay. | |
| contracts for querying who to pay and how much. |
| contracts for querying whom to pay out, and how much to pay. | ||
|
|
||
| Therefore, the core goal of this standard is to define a set of methods for | ||
| financial standard set of methods to call, without specifying how NFT contracts |
There was a problem hiding this comment.
| financial standard set of methods to call, without specifying how NFT contracts | |
| financial contracts to call, without specifying how NFT contracts |
I think this is what you meant?
| financial standard set of methods to call, without specifying how NFT contracts | ||
| define the divide of payout mechanics. | ||
|
|
||
| The `Payout` interface is should be a simple collection of unique addresses that |
There was a problem hiding this comment.
| The `Payout` interface is should be a simple collection of unique addresses that | |
| The `Payout` interface is a simple collection of unique addresses that |
| ```rust | ||
| // return fractional ownership | ||
| pub struct OwnershipFractions { | ||
| pub fractions: HashMap<AccountId, MultipliedSafeFraction> |
There was a problem hiding this comment.
I like your suggestion to go with the latter. I think in a proposal of a new standard, you could just propose your best guess in the main PR, and offer alternatives as PRs targeting the main PR. Or in comments, if a second PR seems like overkill or is hard to pull off for non-maintainers of the repo.
| ```rust | ||
| pub trait Payouts{ | ||
| fn nft_payout(&self, token_id: String, balance: U128) -> Payout; | ||
| fn nft_transfer_payout( |
There was a problem hiding this comment.
I saw @mattlockyer implement this interface as a modification to the core nft_transfer method, since balance argument is optional and returned Payout is also optional. This keeps the interface minimal and keeps backwards compatibility with current standard. I think I like that as a starting point for the discussion.
There was a problem hiding this comment.
There was a problem hiding this comment.
Let's not change the return value on a core method. Payouts are very specific to a subset of NFTs using marketplaces and royalties. Let's stick to having it a separate method.
|
@thor314 it doesn't look like you've been able to work on it since my initial review 3 months ago. Do you anticipate having time to move it forward soon? I'd imagine there's been lots of discussion and clarification on this standard in the past 3 months. |
A flexible implementation of a royalty standard