modifications to 3074 that ensure that royalties cannot be circumvented
This is well outside the scope of your EIP, so please feel free to entirely ignore this question, but how would you modify 3074 (or similar) to ensure royalties cannot be circumvented?
As an ecosystem, we need to ask ourselves if we want to exclude a whole class of assets that are royalty bearing to be excluded from onchain usage because we allow mechanisms that allow circumvention of legal requirements imposed not by nation statest but by the asset originators. […] If I tell you, you are not allowed to do certain things with my asset you should not be able to do that.
While I fully agree with you in principal, there are certain realities we must accept. I do not believe there is a technically sound way to enforce collecting a percentage of a sale price and transferring that to the creator. There are just too many ways to get around it.
There is no magic oracle which can give the true price of a particular NFT. As far as I am aware, there is no way to prevent a dishonest buyer and dishonest seller from colluding and transferring the “real” value in a backchannel, while submitting a much lower price to the NFT contract.
Again, I’m only going from an extremely short read of the contracts, but it looks like the only protection against the above collusion is that if an NFT is listed for below its true market value, a bot might come along and snatch the token before the dishonest buyer is able to get their transaction included. Is there another protection I’m missing?
Also, forcing users into one class of wallets is not a good idea. Give people choice. They will utilize the wallet type they prefer. Who are we to restrict choice unless there are overriding security concerns which I do not see but I might be missing something.
I think I can flip this back on your proposal Forcing users to use EOAs to be able to use these NFTs is not a good idea.
Having said that I would be happy to adjust the language in the standard to abstract it more to remove calling out not having to be a contract specifically
As a potential user of these, if I accidentally bought a token coded to this standard, with all the caveats it brings, I’d be pretty upset. That said, as an EIP editor, the concerns I’ve raised in this discussion thread are unrelated to whether the EIP will be merged.