CIP - Decentralized Native Asset verification

Developers CIPs
1

Native Asset Verification

Problem

Currently, all dApp/marketplaces that offer the verified asset feature

has its own process for verifying projects/tokens. This has a number of downsides.

  1. The NFT/token creator must actively seek out dApps and create individual processes for each dApp and project they have. So an artist of 10 NFT projects (policyIds) across 20 dApps would have to go through 200 verification processes. This is a huge ask of most creators and puts a lot of responsibility on dApps.

  2. Users don’t care about the verification of NFTs/Tokens they are not interested in purchasing. So to the individual user, 99% of all verifications on a platform don’t matter. What actually matters is that the spacebud I’m about to buy is the real one and not a fake.

  3. It teaches users to trust the image/Icon/metadata of a token and not take responsibility for checking the policyID and assetID themselves.

  4. It creates a fragmented user experience where the same NFT/token can be verified on one platform but not another.

  5. It assumes that every user in a dApp considers the same projects to be legit and doesn’t account
    for different users having different opinions on whether or not a project should be verified or not.

Solution

(This will be very web-centric)

Instead of asking dApps to verify projects on the behalf of users we can turn it around and have the user verify the projects for themselves. The user would install a web extension (this could be the user’s web wallet) and be able to curate two lists of policyID/assetID. One for whitelisted assets and one for blacklisted. The extension would inject an API similar to how CIP30 works exposing a very simple endpoint (feel free to add more endpoints/change the type signature)

api.getVerification(id: policyID | assetID): -1 | 0 | 1

where -1 means it is blacklisted, 1 that it is whitelisted and 0 means that it is in neither list.

Considerations

  1. I don’t think it would take too long before users would start asking for the ability to sync their list between different devices/implementations. We would need to think about what happens if a policyID is
    whitelisted in one place but blacklisted in another.

  2. Users might want a way to share lists between multiple people and have trusted parties verify projects on their behalf perhaps similar to PGP?

  3. If users can share lists with one another there must be some mechanism for verifying the authenticity.

2

Sounds interesting approach for me. However, an API for exchange of verification risks to be centralised again!
Walter

3

Very true! Thinking about it, I doubt most users would ever need to keep track of more than a handful of policyIDs/assetIDs. Maybe it would be wise to (at least in iteration 1) not include any API for exchanging verifications.

4

I love your ideas. It appears we are getting closer aligned to the same idea. Please come check out this new proposal especially the latest post.

5

Hi,
In theory this sounds like a promising solution, but in practice what would protect projects from being wrongfully blacklisted, either intentionally of unintentionally?

6

Depends, If we go with the simplest solution where each entry into the blacklist/whitelist has to be manually added by a user then I don’t expect such a thing to be a problem. If someone accidentally blocklists the spacebud collection that only matters if they ever try to buy a spacebud. And when they do they will probably be able to figure it out since every Spacebud that people claim to be legit appears as blacklisted. If a user intentionally blacklists a project then they think that that project is bad and they have the right to that opinion.