EIP-7526: On-chain NFT royalty enforcement

Discussion of a game-theoretic mechanism to induce truthful revelation of NFT sales and their value to allow for decentralised royalty enforcement.

Game theory relies on creating incentives that encourage rational actors to behave in a desired way. In this case, the goal is to induce truthful revelation of NFT sales and their values.

1 Like

It is a combination of incentives and disincentives that ensures honest behavior because it either achieves a Nash equilibrium of winning strategies or in n-player collaborative games (which royalties would be), the Shapley value is non-zero. That is hard to enforce because players would have to commit to hidden values with stakes before they are revealed.

In an experimental setting interesting, in the real world with real money, a total no-go based on my experience with royalties over the last 15+ years.

Just use EIP-4910. Royalties are calculated, collected, and paid out to all relevant parties onchain. There is even a reference implementation … try it out. You might like it :wink:

Thanks @highlander, we’ll take a look at 4910.

That is hard to enforce because players would have to commit to hidden values with stakes before they are revealed.

There are no such values in this proposal. Can you please elaborate?

The reference implementation you linked to entirely blocks transferFrom() and safeTransferFrom(), which breaks expected behaviour of ERC721 tokens. Is this absolutely necessary for implementation of ERC-4910 or is it just in this particular implementation?

@arrans in trustless multi-player games, there must be a commitment to an outcome that not everyone should know – a blinded commitment such as a Pederson or El-Gamal Commitment – and to which the player puts skin in the game through a stake. If the commitment is opened AFTER the game is done, then the stake is returned + a fee, typically, if the commitment matches the outcomes (correct royalty amount). If not, then the stake is slashed.

The construction avoids the nothing-at-stake problem in multi-player games.

That is intentional. When you read 4910, you see that in order to ensure not circumventing royalties, simple transfers from A to B cannot be allowed. 721 behavior is not designed for complex financial transactions – digital assets with residuals. As you will see in 4910, the owner of all NFTs is the contract and not the EOA/whitelisted smart contract – they are only approved. Because the contract must be aware of all buy/sell transactions and manage all applicable cash flows including royalties WITHIN the contract, not outside of it.

1 Like

in trustless multi-player games, there must be a commitment to an outcome that not everyone should know – a blinded commitment such as a Pederson or El-Gamal Commitment – and to which the player puts skin in the game through a stake. If the commitment is opened AFTER the game is done, then the stake is returned + a fee, typically, if the commitment matches the outcomes (correct royalty amount). If not, then the stake is slashed.

Can you please reframe this with respect to the proposal we’ve made? I’m having trouble understanding how it’s relevant but that may just be because you’re speaking more generally and I haven’t seen the connection. While I’m sure that some or even many multi-player games have the requirement you describe, that doesn’t mean that all of them must.

The construction avoids the nothing-at-stake problem in multi-player games.

Our mechanism places the NFT itself at stake. The owner attributes some (hidden) value that we want them to reveal and, If they don’t, then they may lose the token (see take-back in the EIP), which is analogous to slashing in your description. If they reveal untruthfully then they stand to lose the token in return for a sum of ETH less than how much they value the token. While there is no direct analogy with your description, this is best characterised as “partial slashing”, relative to the degree of untruthful revelation. No blinded commitment is necessary.

As mentioned in the Rationale section, a yellow paper will be made available before moving the EIP into Review. This will fully analyse the strategies.

When you read 4910, you see that in order to ensure not circumventing royalties, simple transfers from A to B cannot be allowed.

Full compliance with ERC721 is a strict requirement for us, including permissionless transfers, so ERC4910 is unfortunately insufficient for our needs.