3 ms·

https://opensea.io/collection/nickelodeon-rugrats-heyarnold-eth https://opensea.io/collection/nickelodeon-rugrats-heyarnold-... My company is one of the larges

https://opensea.io/collection/nickelodeon-rugrats-heyarnold-eth https://opensea.io/collection/nickelodeon-rugrats-heyarnold-... My company is one of the largest NFT companies. This is one of our projects. Millions of dollars in secondaries on OpenSea and our hosted marketplace at https://Nickelodeon.xyz/ https://Nickelodeon.xyz/ We collect all royalties and remit payment to the rights holders which include all artists and creators with residuals on Rugrats, of which there are many. They get their check quarterly along with all the other payments (movies, tshirts, video games, etc.) This isn’t exactly rocket science

polygamous_bat 4y ago
So, are you saying that you run a centralized third party that is charged with collecting the royalties and passing it on to the artists? Because nowhere in the ERC-721 standard is there a way to differentiate between a "sale" and a "transfer between wallets". So tell me, please, exactly how "blockchain" is bringing "decentralization" to the art field. I am all ears.
- seibelj 4y ago
  A sale happens in a marketplace. Marketplaces collect royalties and forward them to the address specified. We are indeed a centralized player, just as all NFT creators are centralized entities (i.e. people) but the assets trade on decentralized networks. I think you have a fundamental misunderstanding of how all of this works and have a sneering, dismissive affect because this is something you don’t understand embraced by people who don’t care what you think.
  - kareemsabri 4y ago
    So if they don't use your marketplace are the royalties not collected?
    - seibelj 4y ago
      There is an Ethereum protocol standard (similar to RFCs in the internet context) that defines a standard for NFT royalties https://eips.ethereum.org/EIPS/eip-2981 https://eips.ethereum.org/EIPS/eip-2981 FYI I am an author of this standard. It is widely supported across the ecosystem https://royaltyregistry.xyz/ https://royaltyregistry.xyz/ My company doesn’t care where our NFTs travel or trade on. We get our royalty regardless.
      - polygamous_bat 4y ago
        > The royalty payment must be voluntary, as transfer mechanisms such as transferFrom() include NFT transfers between wallets, and executing them does not always imply a sale occurred. So how is this an improvement over what we have right now? If the buyer and the seller may wish to do so, out of the goodness of their hearts, they can always send part of their sale price to the artist. So why are NFTs necessary in any way, if you cannot programmatically enforce it? (And you never can, the reason of which you already know: if I wish to do so I can make a transfer between my two wallets and a sale look exactly the same.) At which point do these selective, and potentially intentional misleading claims about NFTs go from ignorant to fraudulent? Especially when you may stand to earn a lot by making people believe in your misleading claims?
- jonnydubowsky 4y ago
  The Rarible exchange contract supports all kinds of external royalty interfaces, among them two that Rarible defined themselves, being an early player in the NFT space: https://hackernoon.com/enabling-nft-royalties-with-eip-2981 https://hackernoon.com/enabling-nft-royalties-with-eip-2981 ERC721, 1155 & 2981 together act as a toolkit for the encoding of royalty administration. For example, if an NFT collection owner only implemented one of Rarible’s royalty distribution schemes mentioned above, another marketplace that’s not aware of that interface can simply call the common registry’s getRoyaltyView function. It tries to query all known royalty interfaces on the token contract and translates any response to a commonly useable result. Collection owners who haven’t put any royalty signaling scheme into their contract can deploy an extended “override” contract and register it with the common registry. This registration method will ensure that only collection owners (identified by the owner public member) can call it The Rarible exchange contract supports all kinds of external royalty interfaces, among them two that Rarible defined themselves, being an early player in the NFT space: For example, if an NFT collection owner only implemented one of Rarible’s royalty distribution schemes mentioned above, another marketplace that’s not aware of that interface can simply call the common registry’s getRoyaltyView function. It tries to query all known royalty interfaces on the token contract and translates any response to a commonly useable result. Collection owners who haven’t put any royalty signaling scheme into their contract can deploy an extended “override” contract and register it with the common registry. This registration method will ensure that only collection owners (identified by the owner public member) can call it ```function royaltyInfo(uint256 _tokenId, uint256 _salePrice) external view returns (address receiver, uint256 royaltyAmount);``` The interface also completely works off-chain, so marketplaces that trade assets on alternative infrastructure can still query the creator fee without knowing anything else besides the interface signature of the EIP-2981 method. PaymentSplitters: Sending NFT Royalties To More Than One Receiver. Open Zeppelin's PaymentSplitter primitive allows setting up individual split contracts that keep funds safe until their payees claim them, and their receive function requires the bare minimum of gas to run. NFT collection builders can create an inline PaymentSplitter containing the wanted list of beneficiaries and their respective share amounts and let their EIP-2981 implementation yield the address of that split contract.

polygamous_bat 4y ago

So, are you saying that you run a centralized third party that is charged with collecting the royalties and passing it on to the artists? Because nowhere in the ERC-721 standard is there a way to differentiate between a "sale" and a "transfer between wallets". So tell me, please, exactly how "blockchain" is bringing "decentralization" to the art field. I am all ears.

seibelj 4y ago
A sale happens in a marketplace. Marketplaces collect royalties and forward them to the address specified. We are indeed a centralized player, just as all NFT creators are centralized entities (i.e. people) but the assets trade on decentralized networks. I think you have a fundamental misunderstanding of how all of this works and have a sneering, dismissive affect because this is something you don’t understand embraced by people who don’t care what you think.
- kareemsabri 4y ago
  So if they don't use your marketplace are the royalties not collected?
  - seibelj 4y ago
    There is an Ethereum protocol standard (similar to RFCs in the internet context) that defines a standard for NFT royalties https://eips.ethereum.org/EIPS/eip-2981 https://eips.ethereum.org/EIPS/eip-2981 FYI I am an author of this standard. It is widely supported across the ecosystem https://royaltyregistry.xyz/ https://royaltyregistry.xyz/ My company doesn’t care where our NFTs travel or trade on. We get our royalty regardless.
    - polygamous_bat 4y ago
      > The royalty payment must be voluntary, as transfer mechanisms such as transferFrom() include NFT transfers between wallets, and executing them does not always imply a sale occurred. So how is this an improvement over what we have right now? If the buyer and the seller may wish to do so, out of the goodness of their hearts, they can always send part of their sale price to the artist. So why are NFTs necessary in any way, if you cannot programmatically enforce it? (And you never can, the reason of which you already know: if I wish to do so I can make a transfer between my two wallets and a sale look exactly the same.) At which point do these selective, and potentially intentional misleading claims about NFTs go from ignorant to fraudulent? Especially when you may stand to earn a lot by making people believe in your misleading claims?
jonnydubowsky 4y ago
The Rarible exchange contract supports all kinds of external royalty interfaces, among them two that Rarible defined themselves, being an early player in the NFT space: https://hackernoon.com/enabling-nft-royalties-with-eip-2981 https://hackernoon.com/enabling-nft-royalties-with-eip-2981 ERC721, 1155 & 2981 together act as a toolkit for the encoding of royalty administration. For example, if an NFT collection owner only implemented one of Rarible’s royalty distribution schemes mentioned above, another marketplace that’s not aware of that interface can simply call the common registry’s getRoyaltyView function. It tries to query all known royalty interfaces on the token contract and translates any response to a commonly useable result. Collection owners who haven’t put any royalty signaling scheme into their contract can deploy an extended “override” contract and register it with the common registry. This registration method will ensure that only collection owners (identified by the owner public member) can call it The Rarible exchange contract supports all kinds of external royalty interfaces, among them two that Rarible defined themselves, being an early player in the NFT space: For example, if an NFT collection owner only implemented one of Rarible’s royalty distribution schemes mentioned above, another marketplace that’s not aware of that interface can simply call the common registry’s getRoyaltyView function. It tries to query all known royalty interfaces on the token contract and translates any response to a commonly useable result. Collection owners who haven’t put any royalty signaling scheme into their contract can deploy an extended “override” contract and register it with the common registry. This registration method will ensure that only collection owners (identified by the owner public member) can call it ```function royaltyInfo(uint256 _tokenId, uint256 _salePrice) external view returns (address receiver, uint256 royaltyAmount);``` The interface also completely works off-chain, so marketplaces that trade assets on alternative infrastructure can still query the creator fee without knowing anything else besides the interface signature of the EIP-2981 method. PaymentSplitters: Sending NFT Royalties To More Than One Receiver. Open Zeppelin's PaymentSplitter primitive allows setting up individual split contracts that keep funds safe until their payees claim them, and their receive function requires the bare minimum of gas to run. NFT collection builders can create an inline PaymentSplitter containing the wanted list of beneficiaries and their respective share amounts and let their EIP-2981 implementation yield the address of that split contract.