CHIP-0046: Handling Dishonest NFT Offers

[trgarrett]

No description provided.

[justinengland]

The only note I have here is that you are conflating the ability for people to commit fraud (and by doing so devalue their own assets) with a security issue in which someone would be able to take an asset that doesn't belong to them from someone else who it rightfully belongs to.

This sort of over statement doesn't add weight to your proposal in my opinion and lessens the impact of the valid points you do make. Words have concise meaning and this is not a security issue. Labeling it as such is a misrepresentation of the actual issue.

I do acknowledge there is (as in all transactions) the potential for fraud. I think this is otherwise a solid suggestion. I urge you to stop calling this a security issue and define it more precisely as an opportunity for fraud.

Losing out on royalties because of transaction fraud is troubling for nft creators no doubt. It does not rise to the level of impacting the security of those assets or the chain.

[trgarrett]

You're assuming the royalties are only owed to the creators on a best effort basis. Fraud is theft. Theft is a security issue.

The only note I have here is that you are conflating the ability for people to commit fraud ( and by doing so devalue their own assets) with a security issue in which someone would be able to take an asset that doesn't belong to them from someone else who it rightfully belongs to.

[trgarrett]

Withdrawing this CHIP submission.

[trgarrett]

Given chia-blockchain contains both a blockchain, which I am not claiming is itself failing here, and what amounts to user-defined smart coins (and CNI is only a special user in this case), it seems that there should be latitude to categorize the two separately.

I acknowledge a security issue in a puzzle requires different steps than a security issue in a blockchain. I refuse to acknowledge there is not a security issue in a puzzle, because the puzzle is functioning below expectations set in public by CNI, and the resulting risk is loss of funds. I guess CNI could also “patch” their marketing docs to make them accurate. That would not undo the damage of previous expectations set, but it could help.

Regardless, an issue of some type exists. The feedback from CNI engineers seems to be that this needs to be handled as a "social" consensus through visibility, flagging, tracking, and resulting stigma. As such, I will reopen this issue. It can not have visibility if I don't continue to spread the message.

I am willing to refine the commentary calling it a security issue, but only to clarify the blockchain itself does not have an alleged security issue.

[greimela]

I wanted to add the following procedures to MintGarden a few months ago:

• Flag trades without trade prices as transfers instead of trades. This would also exclude them from volume etc.
• Decline offers without trade prices from being uploaded

Unfortunately, one commonly used wallet (Pawket) doesn't set the trade prices list when creating offers, so it would have flagged something like 20% of all offers back then.

All wallets still correctly pay royalties on the taker side, even if the price list is not set, as far as I can tell.

As soon as all wallets set the trade prices correctly, I am open to deploy the code changes above.

[SlowestTimelord]

All wallets still correctly pay royalties on the taker side, even if the price list is not set, as far as I can tell.

Even if all wallets correctly calculate and pay royalties, the other issue this CHIP raises is what the "correct" calculation even is. In the example of bundling an offer with "undesirable assets", an offer maker may bundle a high value NFT with a bunch of worthless but high-royalty NFTs they minted themselves -- and the taker's wallet would default to splitting the price evenly across all NFTs thereby greatly diluting the royalty paid to the high value NFT.

Would your suggestion here be to also exclude multi-asset offers from volume, provenance etc.?

[grigb]

I understand some of this may not be technically feasible, but I wanted to be sure it was included in the discourse somewhere.

• Watchtower feature: Add support for creators (DID minters) to get alerts to add additional incentive to act right
• Royalties enforced in puzzles
• Royalty-on-transfer flag: Forces royalties on all transfers, not just sales.
• Standardized licensing: Adds clear legal terms for consistency. (I have a lot of additional ideas about enforcing licensing but its not in scope)
• Creator protection fund: Crowdfunded cash to help creators fight royalty dodgers

[joshpainter]

Unfortunately, one commonly used wallet (Pawket) doesn't set the trade prices list when creating offers, so it would have flagged something like 20% of all offers back then.

This answers my question of "is this actually happening out there right now?" Apparently YES, whether intentional or accidental, and quite a large % of them. Has Pawket just never enforced royalties? Are Pawket->Pawket trades royalty-free? Or do I misunderstand something...

[joshpainter]

• Royalties enforced in puzzles
• Royalty-on-transfer flag: Forces royalties on all transfers, not just sales.

@grigb I'm still not convinced this is possible without giving up a lot of NFT functionality. Wouldn't every spend of the NFT coin itself require royalties? Including adding to your own DID, fusing a MZ NFT, etc. And you'd also need a minimum price, or else dodgers would just use 1 mojo as the price and royalties would round down to zero. So every time you spend your NFT coin for any sort of functionality now or in the future, you'd be subject to a minimum fee. It starts to feel more like a tax than a royalty.

[SlowestTimelord]

Are Pawket->Pawket trades royalty-free?

No, because Pawket correctly adds the royalty on the taker side afaik. I would still be surprised if we've seen a substantial number of instances of royalty circumvention in the wild.

[trgarrett]

I would still be surprised if we've seen a substantial number of instances of royalty circumvention in the wild.

I actually agree with this. I may be a bearish bull or a bullish bear, but if billions of new liquidity comes on our chain, I do expect it to devolve rapidly into a mirror of the other ecosystems. I think this is likely an important but not urgent issue.

[joshpainter]

I'm still not convinced this is possible without giving up a lot of NFT functionality. Wouldn't every spend of the NFT coin itself require royalties? Including adding to your own DID, fusing a MZ NFT, etc. And you'd also need a minimum price, or else dodgers would just use 1 mojo as the price and royalties would round down to zero. So every time you spend your NFT coin for any sort of functionality now or in the future, you'd be subject to a minimum fee. It starts to feel more like a tax than a royalty.

Weird, maybe naive idea: I certainly am no expert in the NFT1 standard, but I think I understand the concept of the "transfer program." AFAIK, the whole point of using a "program" here instead of just a target xch address is so that the transfer of the NFT itself can theoretically be customized and/or validated. In the vanilla NFT1 standard, it enforces royalties with some compromises that enable royalty-free transfers. Could a new "royalties-guaranteed-4-sure" transfer puzzle be built that creators could optionally use when minting NFTs? Wallets would need to be updated for support of course, but if this is possible then it would give the choice to the creator, and ultimately the market.

[SlowestTimelord]

I also think the "well transfers are royalty-free" argument has not been well articulated nor well understood. The argument is not that anyone can trust-me-bro trade NFTs or use a centralized escrow service utilizing transfers. The argument (as Josh more eloquently explained in spaces) is that the existence of the transfer program allows it to be wrapped in any number of trustless mechanisms to bypass royalties.

So we should all align on what the goal is with any code fix. It may very well be limited to just "royalties are guaranteed when parties are following standards X and Y for P2P trades". Regardless, the social/platform changes proposed seem to be no-regret changes to me.

[Rigidity]

I'll give my perspective from the Chialisp and coin set model point of view. I want to be clear up front that my intent here is not to debate the validity of any of the problems mentioned in the CHIP, or to tell anyone they shouldn't come up with solutions for them. I just want to give some context on why this is an issue on-chain, how the evasion works at a technical level, and what some of the proposed code changes are. I'd propose that some of this be added to the CHIP for clarity.

How royalties are enforced

When Alice makes an offer, she should add an assertion (in the trade prices list of the NFT transfer program) that the royalty is paid by the taker. This assertion directly influences the validity of the offer, so if the taker decides not to pay the royalty, the offer cannot be accepted.

However, if Alice uses a wallet which decides not to respect NFT royalties (does not include any trade prices), there's nothing on-chain that prevents this.

When Bob takes the offer, he should simply pay and assert the royalty, calculated in an identical way as what Alice did. Regardless of whether Alice requested the royalty be paid. So if Alice didn't assert the royalty, Bob will still pay it, if he's using a standard wallet implementation.

When and why royalties are not enforced

If neither Alice nor Bob asserts and pays the royalty, there's no on-chain mechanism preventing this scenario. I think the obvious next question is typically something along the lines of "why can't this be enforced in the puzzle".

Here is why it can't:

1. When you spend a coin, there are no side effects other than Conditions. There is no condition to figure out what the other spends involved in a transaction (specifically an offer in this case) are. This is because,
2. Every mempool item (transaction) should be valid on its own without any other mempool items being included at the same time. They should also not become invalid by nature of being included with other mempool items (unless those items are in direct conflict with each other, and spend the same coins).
3. So, in order for a coin to know that something is spent alongside it, it must be told so. This means asserting an announcement or message from the "settlement puzzle" to check that the royalty was paid to the creator. But how does the NFT know what the price is? It has to be told the price by the maker, which is the root of the issue here.
4. As such, the price told to the NFT does not necessarily match the price it's being sold for in the offer, and there's no way for it to verify the correctness.

Note that this is not a Chia specific problem, and I would argue that Chia's implementation of royalties actually exceeds that of other blockchains where you rely solely on a centralized marketplace to enforce them, rather than also the maker and taker of the offer.

I hope this makes it clear that this is not a trivial problem to solve within the current constraints.

Within the current constraints

So what are the current constraints of the NFT1 standard? How do NFTs work?

Here are things you can do with NFTs currently:

1. You can send/transfer an NFT to another person or between multiple of your own wallets
2. You can add a URL to the NFT if one of the old ones is now expired, which necessitates spending the NFT
3. You can assign your DID profile to your NFT, which spends the DID and the NFT
4. You can trade the NFT to someone else for another NFT (which does not require a royalty, since NFTs are inherently non-fungible)
5. You can trade the NFT for fungible assets such as XCH and CATs (for which royalties should be paid if the NFT requires them)
6. You can lock up the NFT inside of a fusion puzzle, which requires a transaction
7. Sending the NFT to the "settlement payments puzzle" which is used as an implementation detail for offers, is also itself inherently a transfer of the NFT
8. Really, you can do whatever you want with your NFT provided it "stays the same NFT". It can be sent to any puzzle hash (address) without restriction

Keep this in mind for later.

What if we change the constraints?

There are a few potential ways in which royalties and the functionality of NFTs can be modified to make it easier to enforce royalties on-chain.

Fixed price

If you require that the NFT always be traded for a fixed price, this will completely eliminate most of the utility of NFTs right off the bat. We could have an exception that updating the DID or metadata doesn't need to involve an offer. Even still, it would prevent direct transfers to other wallets or users, NFT to NFT trades, price fluctuation and market making, and things like MonkeyZoo Fusion.

Flat royalty

Instead of a fixed price, we could allow arbitrary transactions and just apply a flat royalty (more like a fee) to everything. However, this doesn't scale well for speculative or high value assets, and it means that even direct transfers, fusion, and NFT to NFT trades would be taxed just the same. Possibly more than once, if intermediate coins are required in the transaction. Hopefully it's clear why this isn't very desirable of an alternative.

"I think I've found a way to enforce royalties (somehow)"

Unfortunately, it's not that simple. Even if you are able to work around enforcement for offers and calculate the price on-chain, there are many other issues with this and ways to evade royalty payments.

Here is a non-exhaustive list of ways I've thought of:

1. You can wrap an NFT inside of a fusion NFT that doesn't have royalties, and trade that instead
2. You can send the NFT to someone and receive payment through a (still trustless and atomic) side channel
3. You can lock up the NFT with a vault send sell the vault itself, which doesn't have a royalty requirement
4. You can lock up an NFT with a p2_singleton pointing to another NFT and trade the new one without royalty
5. You can sell the keys directly to someone in person, which there is truly no way to prevent, although this isn't as trustless

So it's my opinion that trying to somehow enforce royalties on-chain, almost certainly by restricting a lot of the functionality of the NFT1 standard, is not worthwhile due to these additional ways of doing so.

So is it doom and gloom?

No, I don't think so. NFT marketplaces on other blockchains such as Ethereum have been thriving just fine, and they don't have a magical way to enforce royalties on-chain either. It's not really been a solved problem.

I also wouldn't consider this as a security issue with the blockchain (or even the NFT1 standard, in my opinion). More so, a known limitation that extends even beyond blockchain and into the real world.

There are other solutions that can be enacted, similar to what other chains' marketplaces do, to mitigate the risk of people doing this due to financial incentive.

What I think we should do

I think wallets like Pawket should make sure they are enforcing royalties on the maker side. Not doing so going forward should begin to be socially considered an unacceptable practice.

Eventually, display services like Dexie and MintGarden should reject offers that don't display royalties, show the malfeasance in the public history of the NFT's sales, and not include trades which partake in royalty evasion in the volume calculation.

We should look into the potential of an on-chain auctions standard, which may better incentivize paying royalties for high value assets.

The community can also build a watchtower service which monitors the blockchain and reports these fraudulent trades.

We need to create a set of standard licenses that specifically mention royalties being required. This should be enforced through contract law, although the effectiveness of this for small creators without a lot of legal resources might be limited.

We should make it clearer and educate through discussions and CHIPs like this one, that this is how royalties work, so that creators are not confused or misled.

And finally, we should continue having open dialogue about potential solutions and better ways of doing things, since this is the only way we'll find new innovative solutions for problems like this.

A summary

I don't think that this is a major flaw of Chia, although I do feel for people who may have believed that royalties were 100% impossible to evade on-chain. I think we've identified some good improvements that can be made in the ecosystem to limit the spread of the issue over time.

Hopefully I've managed to articulate my thoughts on the subject, and why I believe what I believe.

[Rigidity]

No, I did not write this with AI. Maybe I'm just a bot.

[grigb]

• Royalties enforced in puzzles
• Royalty-on-transfer flag: Forces royalties on all transfers, not just sales.

@grigb I'm still not convinced this is possible without giving up a lot of NFT functionality. Wouldn't every spend of the NFT coin itself require royalties? Including adding to your own DID, fusing a MZ NFT, etc. And you'd also need a minimum price, or else dodgers would just use 1 mojo as the price and royalties would round down to zero. So every time you spend your NFT coin for any sort of functionality now or in the future, you'd be subject to a minimum fee. It starts to feel more like a tax than a royalty.

I agree about the trade-offs here. The core issue is trying to create a universal solution when different NFT use cases have conflicting needs. While enforced royalties on all transfers would hamper functionality in many scenarios, they might be crucial for specific business models. We should consider providing options that creators can choose based on their needs, rather than forcing one approach that inevitably creates problems for some use cases. The ecosystem benefits from flexibility that supports diverse innovation paths.

Engineers often miss the broader potential of these features because they prioritize technical elegance and unified solutions. They see the complexity and edge cases as problems to eliminate, rather than as opportunities for creators who think differently. What looks messy from a code perspective might be exactly the flexibility that enables unexpected business models and use cases we haven't imagined yet.

These are all suggestions rather than critical requirements. It's worth remembering that at one point, none of the changes being discussed were considered necessary for the ecosystem to function.

[justinengland]

• Royalties enforced in puzzles
• Royalty-on-transfer flag: Forces royalties on all transfers, not just sales.

@grigb I'm still not convinced this is possible without giving up a lot of NFT functionality. Wouldn't every spend of the NFT coin itself require royalties? Including adding to your own DID, fusing a MZ NFT, etc. And you'd also need a minimum price, or else dodgers would just use 1 mojo as the price and royalties would round down to zero. So every time you spend your NFT coin for any sort of functionality now or in the future, you'd be subject to a minimum fee. It starts to feel more like a tax than a royalty.

I agree about the trade-offs here. The core issue is trying to create a universal solution when different NFT use cases have conflicting needs. While enforced royalties on all transfers would hamper functionality in many scenarios, they might be crucial for specific business models. We should consider providing options that creators can choose based on their needs, rather than forcing one approach that inevitably creates problems for some use cases. The ecosystem benefits from flexibility that supports diverse innovation paths.

Engineers often miss the broader potential of these features because they prioritize technical elegance and unified solutions. They see the complexity and edge cases as problems to eliminate, rather than as opportunities for creators who think differently. What looks messy from a code perspective might be exactly the flexibility that enables unexpected business models and use cases we haven't imagined yet.

These are all suggestions rather than critical requirements. It's worth remembering that at one point, none of the changes being discussed were considered necessary for the ecosystem to function.

Nothing is stopping anyone from proposing changes to the open source code base that would support your suggestions. If someone made a PR to this effect, I am sure it would get a solid review and would spark a ton of discussion. We at CNI likely do no have time for upgrading the NFT standard currently. But that is the beauty of open source. Any other interested party can.

[trgarrett]

Every mempool item (transaction) should be valid on its own without any other mempool items being included at the same time. They should also not become invalid by nature of being included with other mempool items (unless those items are in direct conflict with each other, and spend the same coins).

@Rigidity

Where does that leave oracles in Chia? I know there’s not a standard per-se, but even if they are anyone-can-spend to ensure announcements, it seems unnecessary to force them to be duplicated throughout the block.

Since some conditions specifically refer to “in the same block” it would seem that the mempool would have to handle dependencies now. I know the spend bundle ceases to exist as a concept during block formation.

I have been pondering if there are use cases to have a SANDBOX condition with an aggregate signature that allows a spend to opt in to any more stringent context rules, like no external dependencies. The trick seems like it would be: how do you calculate an aggregate signature that commits to the aggregate signature without knowing the aggregate signature. I’m not a cryptographer, though.

[Rigidity]

There is a feature called Identical Spend Aggregation which allows spends for the same coin and same solution to be deduplicated during block construction.

[SlowestTimelord]

Excellent summary and write up @Rigidity

Flat royalty

Instead of a fixed price, we could allow arbitrary transactions and just apply a flat royalty (more like a fee) to everything. However, this doesn't scale well for speculative or high value assets, and it means that even direct transfers, fusion, and NFT to NFT trades would be taxed just the same. Possibly more than once, if intermediate coins are required in the transaction. Hopefully it's clear why this isn't very desirable of an alternative.

Could a flat royalty be enforced for Offers only? An offer may not know the trading price of the NFT but can it assert a specified flat royalty amount in the NFT? If so, could offers default to a minimum flat royalty if no (or low) trading price is specified in the price list?

[OverActiveBladderSystem]

@SlowestTimelord Even if all wallets correctly calculate and pay royalties, the other issue this CHIP raises is what the "correct" calculation even is. In the example of bundling an offer with "undesirable assets", an offer maker may bundle a high value NFT with a bunch of worthless but high-royalty NFTs they minted themselves -- and the taker's wallet would default to splitting the price evenly across all NFTs thereby greatly diluting the royalty paid to the high value NFT.

Would your suggestion here be to also exclude multi-asset offers from volume, provenance etc.?

I have made multi-item offers containing a high value item with low value items (none of which I made) not thinking of the way royalty fees are calculated and would weight each item in the multi-item offer, its another educational moment.

For example: You make an offer file for 100 XCH, within that offer file is 1 NFT valued at 99 XCH and 4 other NFTs valued at 1 XCH in total, each of the 5 items in that offer file are weighted as 20 XCH for the royalty fee calculation to apply to, which would "unfairly" reward the lesser valued items over the primary item driving the sale.

So in this example any "social markings" on those NFTs would not be the result of intentional goosing of the system but just a lack of thought and understanding on how things work as people learn whats done under the hood.

[danieljperry]

Thank you @trgarrett , this CHIP has been assigned CHIP-46 and is a Draft.

[danieljperry]

Feel free to continue discussing it here, or on our Discord. Given the level of interest in this CHIP, if at all possible we should set up a public Zoom call to introduce it and answer questions.

[danieljperry]

My main comment at this point is that while the CHIP clearly spells out the problem, the proposed solutions currently use words/phrases like could, should, at the discretion, etc. I suggest that while this is an optional CHIP, it would be beneficial to the community to apply rfc2119 to make expectations clearer.

For example, start with requirements:
"In order for a wallet/marketplace/explorer to be CHIP-46 compliant, it must do the following: "

Then add things that, while not required, are strongly recommended whenever possible:
"<wallets | marketplaces | explorers> should do the following: "

And add things that are optional from there.

It would also be great to have a method to test for compliance, and how to report instances of non-compliance, but you might understandably deem these to be outside the scope of the CHIP.

[trgarrett]

My main comment at this point is that while the CHIP clearly spells out the problem, the proposed solutions currently use words/phrases like could, should, at the discretion, etc. I suggest that while this is an optional CHIP, it would be beneficial to the community to apply rfc2119 to make expectations clearer.

Thanks, @danieljperry. That is good feedback. Would taking steps to make the language more direct start pushing this from an Informational to Process CHIP? I was trying to walk the line between giving information and compelling action, but if we have the consensus to make it more direct, I am on-board.

[justinengland]

The more I think about this, the more I am convinced that we should have two NFT standards. The current NFT standard, which can become the NFT optional standard, which allows maximum freedom of transaction for the end user and allows people to tip via the royalty and has no post release control for the project creator.

The new hard royalty standard would be a bit more restrictive and could even allow clawback for the project creator if a royalty is circumvented somehow later or a NFT holder does something to break their agreement with the project creator.

What do you guys think of that idea?

[joshpainter]

The new hard royalty standard would be a bit more restrictive and could even allow clawback for the project creator if a royalty is circumvented somehow later or a NFT holder does something to break their agreement with the project creator.

What do you guys think of that idea?

I think it is a brilliant idea, but I'm biased. 🤣 #151 (comment)

[justinengland]

I think it is a brilliant idea, but I'm biased. 🤣 #151 (comment)

Of course you already had the idea 2 days before me. Par for the course.

[justinengland]

I also think its time for this open source project to really stretch its legs. I would LOVE to see a community champion for this effort come forward. Commit to getting a solid RFC that addresses all the concerns together, by X date.

Then commit to getting a pr put together to propose the code change, and recruit devs from the community and maybe even CNI to help write the code needed, by Y date.

Even if these dates are a year out, it would be fantastic to see someone who really has a passion for NFT projects become a foil to CNI in this effort to produce something truly community owned that serves the needs being expressed here and on social media.

[Rigidity]

We already have the Revocation Layer that can be used for this purpose. Permuto is already using it for Revocable CATs and there's no reason it wouldn't work for an NFT too.

So I don't think an NFT standard split is needed to accomplish that functionality.

[Rigidity]

I would be open to supporting it in Sage, for what it's worth

[danieljperry]

My main comment at this point is that while the CHIP clearly spells out the problem, the proposed solutions currently use words/phrases like could, should, at the discretion, etc. I suggest that while this is an optional CHIP, it would be beneficial to the community to apply rfc2119 to make expectations clearer.

Thanks, @danieljperry. That is good feedback. Would taking steps to make the language more direct start pushing this from an Informational to Process CHIP? I was trying to walk the line between giving information and compelling action, but if we have the consensus to make it more direct, I am on-board.

It's your CHIP so you can take it in whatever direction you want. However, I think it would be more useful as a Process that others can follow.

[cartastagnola]

Thank you @trgarrett for making this CHIP.

I would like to point out that there are two connected but distinct problems we are discussing here:

• what can we do to mitigate royalties evasion and wash trading with the current standard (topic of the CHIP)
• creating/discussing a new NFT standard.

Perhaps not now, but it could be a good idea to separate the discussion later on.

My thoughts about the first may be a bit controversial: let's open the gate and let people decide what they want to do with royalties.
I would make royalties optional in the reference wallet, with a toggle button that allows disabling them, accompanied by a large disclaimer stating that, for the maker, it doesn't change anything price-wise and that one could break laws, licenses, and the general agreement within the NFT communities.
At the same time, on DEXs, I would not ban any offers, but only flag them with the same disclaimer.
I think banning and hiding things behind missing functionalities would only lead to the rise of anarchic DEXs and wallets that will provide these 'freedoms', fragmenting the ecosystem.
Then, I also think that we could incentivize the offer creators with a cut of the royalties. After all, they are making the market and they are the ones who are truly in control of it.

About the NFT standard I don't have much to say. I am only wondering why the NFT cannot know the price of the offer if the taker has to submit the correct price to get the offer validated; he cannot lie about it.

[Rigidity]

I don't want to support royalty evasion in Sage.

The offer creator gets to decide the price they're selling it for - how would them getting a cut of the royalty be any different?

I went into detail in #151 (comment) about the technical reasons for why it's not possible for the NFT to know.

[cartastagnola]

I don't want to support royalty evasion in Sage

Evasion would always be a fork away (as you said few lines of code). You are providing a tool, then is up to the user deciding what is good or bad.

Edit: I try to rephrase it. As a community, we can decide whether to allow optional royalties through a toggle button with a clear disclaimer or by installing a forked reference wallet that claims to be royalty-free.

[cartastagnola]

The offer creator gets to decide the price they're selling it for - how would them getting a cut of the royalty be any different?

If he wants to sell at the floor price, that is the price. But in the 'dark' market, he could sell it at the floor price plus a discounted portion of the royalties to be more competitive than the fair market.

[danieljperry]

Let's keep this discussion focused on the CHIP. Tangential proposals can be discussed either on CNI's Discord or on chiaforum.com. If you have a concrete proposal that meets the CHIP guidelines and standards, then feel free to submit a separate CHIP. Thanks!

[danieljperry]

We will hold a public Zoom call to discuss this CHIP on April 17 at:
7 AM PDT
2 PM UTC
10 PM China

See the #chips channel in our Discord for the details.

[trgarrett]

I have updated the CHIP type from Informational/Informative to Process/Other.

I have updated the title from "Detecting Dishonest NFT Offers" to "Handling Dishonest NFT Offers."

I have provided some actionable recommendations for clients and display services.

[danieljperry]

I have updated the CHIP type from Informational/Informative to Process/Other.

I have updated the title from "Detecting Dishonest NFT Offers" to "Handling Dishonest NFT Offers."

I have provided some actionable recommendations for clients and display services.

Thanks!

[danieljperry]

The recording of our discussion of this CHIP is now live: https://youtu.be/nGMTZWE2O5U
Looking forward to adding the ideas from the discussion!

[Rigidity]

From the perspective of a wallet, there's only so much you can do (especially since anyone can modify the code). That said, Sage includes the trade prices list when making offers, and pays royalties regardless of the presence of trade prices, thus enforcing royalties on both ends.

However, it's still possible to combine a cheaper NFT with a more expensive one to siphon half of the royalty payment off of the other, since the trade prices are evenly distributed amongst NFTs with royalty percentages greater than 0 in an offer. Additionally, you could offer an NFT for free and combine it with an offer that has the actual combined price, thus removing the royalty entirely. I can't think of a good way to solve this - and if you were to allow the user to manually distribute the trade prices, they could manipulate it even easier (although maybe it makes it more of a conscious decision and easier to detect malfeasance).

Regardless, I think that it may be a good idea to more clearly show the trade price breakdown and royalties going to each creator when making and taking offers, to make it harder to make a mistake there. And maybe a small warning if there are multiple NFTs? Beyond that, it's hard to not break compatibility.

I'm open to ideas on what the best path forward is here on the wallet side - and certainly other wallets (such as Pawket) which do not currently enforce royalties on the maker side should do so.

[Rigidity]

I'd like to mention that if the royalty percentage of an NFT is 0%, Sage (and perhaps other wallets, I haven't checked) will set the trade prices list as empty, to save on CLVM cost. I don't think this edge case should be considered a dishonest offer.

[danieljperry]

Change "as been valued" to "has been valued"