CIP Proposal for discussion " Market CNFT policyID verification "

[havealoha]

CIP Proposal for discussion “Market CNFT policyID verification”

Simple Summary

A community standard for market CNFT policyID verification utilizing a no name asset with tag 808 correlated with an augmented ADA Handle (Handle), both referring to each other. Handle correlation relies on the future release of augmented Handles and their support for adding policyID’s. Failing augmented Handles, additional social media tags could be added for semi manual verification. The current verification system would be a fallback for artists without a Handle or those choosing not to participate.

Abstract

This proposed standard will allow for verification of CNFT policyID’s across the secondary market space. Consumers are aware of Handles and prominent artists have already chosen to display those Handles on social media platforms. Being similar to CIP-0027, the ecosystem is already familiar with part of this proposal.

Motivation

CNFT marketplaces struggle to keep up with verifying new collection policyID’s due to the influx of new artists and projects. This standard would relieve the market spaces from verifying new policyID’s and would instead display the Handle of the artist who owns the collection. From here the consumer is left to do their due diligence. This process also provides the marketplace with the collection name and possibly an Avatar\PFP if one is available in the augmented Handle. A marketplace could even choose to only allow assets to be listed if they come from a wallet that has the corresponding Handle. Additional social media tags could be added for out of band manual verification like Twitter, Discord etc.

Specification

A new tag of 808 is proposed for this implementation.

The 808 verification tags are to be written to an unnamed asset, using the policy to be used for the intended Cardano Assets. 2) Updates or rewrites are allowed. 3) Within this created asset will be the metadata for verification. It will use a tag of 808, and then have four tags to identify the name of the collection, the name of the artist, the Handle, and contact. Those tags will be “collection”, “artist”, “handle” and “contact” respectively. 4) The “collection”, “artist” and “handle” key tags can be any base-16 value or array. “contact” can be a base-16 array of social media user names. By allowing for an array, any tag can exceed the per line 64 character limitation and include other encoded characters. 5) The artist adds the corresponding policyID to a list in the augmented Handle. 6) All markets will be instructed to look for the latest minted 808 asset on a policy and cross reference the Handle and policyID between the 808 asset and augmented Handle. If they match, the project is either flagged as verified, the Handle is displayed or the avatar\PFP is displayed or all of the above.

Example JSON with string

{ “808”: { “collection”: “416c6f6861”, “artist”: “c49277652068c4816e6175206f206b6120cabbc481696e612e”, “handle”: “2468656c65”}, “contact”: [“74776974746572”, “646973636f7264”, “66616365626f6f6b”] }

Example JSON with array

{ “808”: { “collection”: “416c6f6861”, “artist”: [ “48c4816e6175206b6120cabbc481696e612c2068c4816e6175206b652061”, “6c69cabb692c2068c4816e6175206b65206b616e616b612e” ], “handle”: “2468656c65” }, “contact”: [“74776974746572”, “646973636f7264”, “66616365626f6f6b”] }

Process Flow

Create policy for planned assets. 2) Mint no name asset with 808 metadata. 3) Mint planned assets using this same policy. 4) Existing policies can mint an appropriate 808 asset. 5) The policyID is added to the augmented Handle. 6) The 808 asset can be burned.

Rationale

By creating a new tag for the distinct purpose of policyID verification, Cardano Asset makers, and Marketplaces can uniformly verify their policyID’s with predictable results. By creating the instructions on a single, no name asset, all marketplaces will know the correct location of the policyID verification asset, without having to further locate it. By enforcing the requirement of honoring only the latest mint, cardano artists can move or change their Handle and if necessary, update the artist and collection name. It is easy to work with this new standard, and does not require an in depth understanding of smart contracts. The relationship from policyID to Handle in 1 to 1 however the relationship of Handle to policyID can be one to many. Marketplaces could choose to have these automated collections queue into a human review.

20220209 21:24 Discussion on Discord in Blade adahandle channel:
Special thanks to gorath for suggestions on making additional tags available for manual verification or those not wanting to use a Handle.
Thanks to BenOJosh for asking hard questions.

[LonacheG]

A few general comments. Brace yourself.

First, social media handles are ephemeral and poorly defined. They are also subject to arbitrary revocation and change. They can expire. People can lie. Their definition is also unclear, so it is therefore also unclear how to verify any of it and therefore utilize it. It would need to be curated off chain somehow, and we’d somehow also need to understand who curated it and whether they themselves are trustworthy. You seem to understand these issues, and treat social media handles like a grab bag of data to be used in arbitrary ways off chain. I’m having a hard time understanding how this belongs in a formal standard. I think my issue is that they are just one metadata element out of many that a consumer might use to verify a collection and perform due diligence.

This brings me to a second point: your limited fall-back metadata standards for identifying the provenience, authorship, etc. of items in a collection look a lot like amateurish versions of what libraries and museums are already doing (check out metadata standards like Dublin Core, Spectrum, CIDOC, etc.).

If you’re going to start down this road, do your homework first, I would advise. Talk to a librarian or museum curator. They deal with this sort of problem every day. There is a lot of metadata that a consumer might want to use to verify a collection and do their due diligence. Social media handles are one thing, for sure. But there is a wider issue here. Identities aren’t the only identity-related (and other) metadata that NFT collection maintainers have a hard time maintaining.

In this proposal you also need at least a basic definition of what a Handle is.

Last thing: you mention verifiability, but I don’t see this concept formalized well except specifically with respect to policies. I can imagine the 808 tag as specifying things like private keys. And what about hashes and locations/URIs of legal or other documents that define the collection off chain? (This also is a kind of information that changes; actually I’m not even sure that there is any way to authenticate NFTs in general, as was pointed out in an early C Hoskinson. YouTube video,)

[havealoha]

Thank you for your input.

The goal of verifying an NFT collection is to confirm that the creator of the policyID can be associated with an existing social media persona. At least that is what jpg.store and cnft.io are doing. jpg.store is correlating policyID with email and twitter accounts. CNFT.io is correlating with policyID with github commit and twitter. 808 does the same but via an ADA Handle (those are already documented in great detail). What any given marketplace does with the data in 808 and how they choose to interpret that is up to them.

Yes, the broad and open ended metadata could be interpreted as amateurish but this also gives it great flexibility. You can include as much or as little data as you like, let the marketplace specify what they want in there. One marketplace may like one social media account vs another, leaving that array open offers flexibility. Sure, theres room to tighten the metadata down, this is your opportunity to make a concrete contribution, show us your .json.

Its not like we are going to take a blood sample, scan pupils and ask for national identity papers but this proposal goes above and beyond any existing effort or system.

Yes, I am not an expert, but I am here. The current verification system is broken. I am doing what I can because nobody else is tackling the problem or even admitting that it exists. In my opinion, the store developers should be in here doing this. Please use some of your expertise and energy to add some revisions, it appears you have the time and interest. I really appreciate your feedback and ideas.

[HeptaSean]

I don’t think that this can be solved by on-chain technology.

Much as anybody could take an image, put it on IPFS, and mint an NFT for it, even if its not their image at all.

Even if we would have a metadata standard for policy IDs (why not just include it in the NFT metadata?), anyone could write any link to a website or social media profile in such metadata.

The verification would have to be done the other way round: The known website or social media profile of a creator has to link to the policy ID and assert that it is valid. But for that we don’t need any changes on the chain side of things.

A lot of the problems that are discussed as being solvable by blockchain technology have similar problems: The blockchain can only prove things that are already on it, but if something should be proven from outside – being the creator of something, having an identity, educational credentials, … – there needs to be trust in someone outside. And then, we don’t really need a blockchain anymore in many cases.

[havealoha]

@HeptaSean and @LonacheG, I think you are both failing to recognize what is being attempted here. I agree that neither the chain nor any automation can eliminate copycat nft’s or an artist from mimicking the identity of another. What the 808 asset attempts to do is offer additional data to marketplaces and consumers so that they can decide for themselves if the person who owns the social media account or ADA Handle and policyID are correlated. If I own the policyID, and either the social media channel or the ADA Handle then I can edit attributes of the pair so that they confirm each other. A bad actor will not own both the keys to add an 808 asset to a policy and make augmentations to the ADA Handle.

Here is the logic:
IF $policyID.808.handle = $handle.augmentation.policyID OR IF $policyID.808.contact = $twitter.username+(manual verification) then the consumer or marketplace can assume that the person in control of the policyID and Handle or twitter account are one in the same.

This needs to be proven from both ends. Its not one or the other.

Adding this data to each NFT would be silly when it could be done for the entire policy.

For instance, I know and trust $conrad on twitter. I know he owns and controls the $conrad ADA Handle. if he creates a new NFT Collection with a policyID of “123456789” and the policyID 808 asset says Handle=$conrad and if I check his $handle and it has the augmentation policyID=“123456789”, then I know he is the legitimate creator of that collection. So what if its NFT’s of my grandmas hot sauce recipe that he managed to get. I trust Conrad by the sight of the $conrad ADA Handle.

A marketplace can then choose to display the fact that the policy and Handle are correlated and if so, they could even choose to show other attributes gleaned from 808 or handle like a social media contact, PFP, avatar, other related policies in that handle.

Here is some good material on how a marketplace would further integrate with the ADA Handle Standard .

Introduction

A blurb from the ADA Handle page:

Handle Augmentation

& A Composable Future

ADA Handle has an in-depth roadmap for the future including a future DAO for governance, and community-voted on Handle Augmentation support.

Aside from the countless use-cases for standardized naming (such as an integrated mobile wallet experience similar to Cash App), Handle Augmentation will allow users to opt-in to additional metadata added to their unique Handle, providing an extendable pattern for Partners to build upon.

[HeptaSean]

“ADA Handle” looks more like a business than an open standard to me. I would never support something like that. Paying at least 10 ADA so that they mint a named NFT for me? Are they completely nuts?

And, since they own the keys for the handle policy that they want to be the one and only (and hopefully won’t succeed with it), the augmentation can only be done by them with at least the possibility to charge additional fees every time the metadata of the handle should change.

And it still doesn’t give much more assurance. The external source (website, Twitter account, whatever) saying “Yup, that ‘handle’ is mine.” is not much easier than the external source saying: “Yup, that NFT is mine.”

[havealoha]

ADA Handle is an open standard. You can mint your own Handle right now. But, the policy of your Handle won’t be trusted by wallets and dapps that have integrated Handle unless you convince them to trust your policyID. This trust, integration and relationship building is what you are paying for. I see your point, totally valid.

Again, 808, weather using Handle, social media or some other 2nd factor isn’t about positively identifying who the original artist is or who a copyright holder is. It’s about matching a persona or social reputation with a projectID. You could just as easily post some json as a tweet and then put that tweet address in the 808 instead of a Handle . There is nothing that says 808 has to be Handle based. These discussions are how we identify opportunity and innovate. Thank you for staying engaged and sharing your concerns!

[HeptaSean]

@havealoha

You can mint your own Handle right now. But, the policy of your Handle won’t be trusted by wallets and dapps that have integrated Handle unless you convince them to trust your policyID.

They rather specifically do not want that: “Official Policy IDs. Ensure that you always reference the correct Policy ID’s when looking up a Handle.” Official Policy IDs - API Docs

@havealoha

This trust, integration and relationship building is what you are paying for.

They do not do any verification on the people they mint handles for. They don’t do anything that warrants any trust. They keep full control over the policy the handles are minted under. I will quite surely not pay for this totally artificial scarcity with no technical merit.

@havealoha

It’s about matching a persona or social reputation with a projectID. You could just as easily post some json as a tweet and then put that tweet address in the 808 instead of a Handle . There is nothing that says 808 has to be Handle based.

In your proposal above, handles are quite prominent and other possibilities only mentioned as a fallback.

A specification of what to put on a website or social media profile to do the verification in the opposite direction would be interesting. (I’d still do it per NFT and not per policy, but that’s probably matter-of-tastey.)

Some details of your proposal:

• Why do you hex-encode everything? It’s not needed at all. JSON can perfectly deal with UTF-8 strings.
• The strings in contact should not just be user names, but full URLs to social media profiiles. User names can be owned by different people on different networks. It should probably not even be restricted to social media. Why not the URL of the creator’s website?
• “The relationship from policyID to Handle in 1 to 1 however the relationship of Handle to policyID can be one to many.” Technically, relationships do not have different cardinalities per direction. Policy ID to handle is many to one.
• Personally, I would use “creator” instead of “artist” throughout the proposal. It’s more neutral and does not open the question if the NFT has something to do with “art” at all. There is not only the question if ugly apes are “art”, but there are also NFTs that are not even intended to be art by their creators.

[havealoha]

Wow!
Now this is the type of productive feedback that excites me!

I’ll revamp the proposal so that Handle isn’t primary and instead an array of URIs,paths can be used. I like this even better because the creator could add as many as they want and the market could have a score based on how many methods were used.

I wasn’t suggesting Handle verifies minter’s, only that many wallets and dapps trust the Handle project. Yes, anyone can mint a Handle just as anyone can create a Twitter, GitHub or website. You can fork handle despite their wishes. It just takes convincing wallets and dapps to add your policyID.

Why not allow either 808 or per NFT?

Hex not friendly, I thought that’s the direction developers were going as to allow all character sets but yeah if it’s a URL, it doesn’t matter
Although I wouldn’t be surprised to see some crazy non utf-8 stuff in Handle in the future.

Policy ID to handle is many to one.

Creator

The creator would produce 808.json (only content necessary might be policyID) and host it via some social media account.

The 808 asset metadata would be something like this:
URI to Twitter account,path to tweet with policyID
$handle,augmentation node with policyID
URI to a landing page of choice,URI to some 808.json
URI to GitHub account,path to 808.json
Etc

Based on the URI prefix, the marketplace can assume what type of entity they are verifying. Marketplace would be responsible for parsing the array and determining the matching up with the policyID

[HeptaSean]

@havealoha

only that many wallets and dapps trust the Handle project.

Do they? Haven’t heard of them until this thread. They claim to partner with some wallets, e.g., ccvault, but I haven’t seen any handles in ccvault by now. The project did not even properly start. At the moment, I can’t get a handle, because pre-sale has ended and proper sale not started.

@havealoha

You can fork handle despite their wishes. It just takes convincing wallets and dapps to add your policyID.

Wasn’t planning on doing any business on Cardano.

I’d prefer a standard, which does not need some third party – be it adahandle.com or adadomains.io (a quite similar, half-started project) – but does it with regular transactions, purely on the chain, completely under my control. But that would be non-trivial to specify.

@havealoha

Hex not friendly, I thought that’s the direction developers were going as to allow all character sets but yeah if it’s a URL, it doesn’t matter

That’s a misunderstanding. Only cardano-cli moved to taking hex strings, because parsing human-readable UTF-8 strings from the command line can be error-prone. And these hex strings still are UTF-8, but the hex representation of the pure bytes stored in memory or transmitted over the network instead of the human-readable strings these bytes represent.

Inside the transactions nothing changed at all. It always was UTF-8 and if you looked at it at a very low level, it always were the bytes you can see in hex strings.

Since JSON (and HTML and nearly every other application) can deal with human-readable UTF-8 strings just fine, we should use them everywhere, except for the cardano-cli command line.

@havealoha

Although I wouldn’t be surprised to see some crazy non utf-8 stuff in Handle in the future.

Hopefully not. UTF-8 can encode the whole Unicode character set. It took decades for (nearly) everyone to finally accept that as the better standard and replace all these encodings from ISO8859 via Windows codepages to the various encodings for Chinese and Japanese characters.

@havealoha

The creator would produce 808.json (only content necessary might be policyID) and host it via some social media account.

The 808 asset metadata would be something like this:
URI to Twitter account,path to tweet with policyID
$handle,augmentation node with policyID
URI to a landing page of choice,URI to some 808.json
URI to GitHub account,path to 808.json
Etc

Yes, exactly that. Don’t know if we really need two items or if just a single link to the page containing the policy ID is not enough. It usually contains the information to which Twitter or Github account or which website it belongs implicitly.

I can tweet „I just minted this collection as NFTs under the Cardano policy ID: policy:12345678901234567890“ and put the link to that specific tweet into the 808 metadata of the empty asset name of that policy.

Likewise, I can put a similar sentence in the README of the corresponding Github project or on the page on my website describing the project. And just give the URL to the specific page.

Clients and market places could then just search the web page for “policyid:” followed by a bunch of numbers looking like a policy id and put a green check mark at the URL if this checks out.

Not requiring JSON, but just this simple string is easier to do for people, especially if it is Twitter, Insta or something like that, where they don’t control the technology, but can decide on the text.

And as you said it just has to be the policy ID.

[havealoha]

@HeptaSean

Do they? Haven’t heard of them until this thread.

Many projects do, yes. SundaeSwap, DripDropz, WorldMobile, PhotoChromic, Flint, Nami, Ccvault. Am I living in an echo chamber? They have posted all of their integrations and partners here ADA Handle

@HeptaSean

That’s a misunderstanding. Only cardano-cli moved to taking hex strings,

Oh! I just assumed it was chain wide. Thanks for clarifying!

@HeptaSean

I can tweet „I just minted this collection as NFTs under the Cardano policy ID: policy:12345678901234567890“

I like the pretext of “I just minted”. This way someone can’t trick me into just posting a policyID if somehow they had gotten control of my policy keys or they were trying to make it look like I minted their collection. Yes, json is not friendly to new creators.

[HeptaSean]

@havealoha

Many projects do, yes. SundaeSwap, DripDropz, WorldMobile, PhotoChromic, Flint, Nami, Ccvault. Am I living in an echo chamber? They have posted all of their integrations and partners here ADA Handle

Have you seen any of them really integrate it?

These are all just declarations of intent.

I’m very wary if a single project shall get the power to decide on these handles and can charge anything they like for me getting such a thing.

[havealoha]

@HeptaSean

Have you seen any of them really integrate it?

Ive actually used it in the wallets and DripDropz. I used it on Sundae Swap testnet but I understand they added it to prod. I use it every day at pool.pm . I love being able to tx\rx with my $handle without copy and pasting addrjdjdjdjdjdjdjdjdjshagsheurktmfjhsycyfkrnejdujfjrjjsjxcjje

[HeptaSean]

@havealoha

I use it every day at pool.pm

Interesting.

But also already shows the problem with this thing:
https://twitter.com/pool_pm/status/1472168890654502918?s=20&t=tlTSmMhHgvRrtoaBhIJ5xQ

[havealoha]

Lol, yeah, I bought some handles of high profile names that Ive since resold. It’s no different than domain names and the good old days of domain squatting. On secondary markets some of these are going for 1k + ada. It’s no different than verifying with you that your Hande is $HeptaSean not $HeptaShawn before I send you a million ADA. People need to DYOR, verify then trust. It is very clear that $Sean is not $Shawn. Not as easy to compare addrjdjdjdjdjdjdjdjdjshagsheurktmfjhsycyfkrnejdujfjrjjsjxcjje with addrjdjdjdjdjdjdjdjdishagsheurktmfjhsycyfkrnejdujfjrjjsjxcjje
You make some valid arguments about Handle. But let’s stay focused on the proposal.

[havealoha]

##This is draft 2 which supercedes the first draft at the top of the post.

CIP Proposal for discussion “Market CNFT policyID verification”

Simple Summary

A community standard for CNFT policyID verification utilizing a no name asset with tag 808 correlated with one or more online or onchain accounts by confirming policyID information from each source. This proposed standard will allow for verification of CNFT policyID’s across the secondary market space. Existing policyID verification varies by market but often relies on a multi step 3 way process involving exchanging a social media message, email or webform which contains the name of the creator, collection name, social media account, and email address. Markets could utilize this proposal to automate the collection of the required information, queue the policyID for manual verification, present consumers with a rating system and/or choose to fully automate the verification process.

Abstract

A creator would start by making a new Cardano NFT policy. Then they create document or tweet on Twitter, GitHub, webpage or any URI based online platform within their control. Additionally, an ADA Handle (Handle) with an augmentation specifying a policyID could be used. Within the Handle, tweet or document they would add the policyID of the NFT collection in question. This proves that their Handle, online persona or social reputation controls that particular account. Any popular platform could be used so long as it provides a URI for the market so that it can retrieve the account information and the document with the policyID without impediment. The creator would then create the no name 808 asset within which additional tags specify creator, collection name, and a URI array. Within the URI array, one or more URI’s resolve to the Handle, Tweet or document that contains the policyID. This two step process proves that the creator has control of both the policyID on the chain and the one or more online accounts. The current verification system would be a fallback for creators with pre-existing collections that can not be updated with an 808 asset or for individual assets where it is otherwise not feasible. Being similar to CIP-0027, the ecosystem is already familiar with part of this proposal. This same set of tags could be added to individual assets as they are minted instead of utilizing the 808 no name token. In that instance, the assetID would be utilized instead of the policyID.

Motivation

CNFT marketplaces struggle to keep up with verifying new collection policyID’s due to the influx of new creators and projects. This standard would relieve the market spaces from verifying new policyID’s and could instead display the social media accounts of the creator who owns the collection. From here the consumer is left to do their due diligence. This process also provides the marketplace with the creator name, collection name and possibly an Avatar\PFP if one is available from the platform hosting the URI.

Specification

A new tag of 808 is proposed for this implementation.

1. The creator makes a new Cardano policy.
2. They then use one or more existing online platforms where they have a social reputation, one that their potential consumers find trustworthy. On this platform they create content that contains the policyID of the NFT collection in question. If using a Handle, the owner adds the policyID as an augmentation.
3. The 808 verification tags are to be written to an unnamed asset, using the policy to be used for the intended Cardano Assets.
4. Updates or rewrites are allowed.
5. Within this created asset will be the metadata for verification. It will use a tag of 808, and then have three tags to identify the name of the collection, the name of the creator, and URI. Those tags will be “collection”, “creator”, and “URI” respectively.
6. The “collection”, “creator” and “URI” key tags can be any UTF-8 value or array. By allowing for an array, any tag can exceed the per line 64 character limitation.
7. All markets will be instructed to look for the latest minted 808 asset on a policy and cross reference the URI document policyID data with the 808 asset. If they match, the projectID can be considered validated. The market could then issue a rating system. If multiple URI’s were validated they could show a higher validation score. The creators social media handles could be displayed next to the verified collection or asset.

Example JSON with string

{
	"808": {
		"collection": "Aloha",
		"creator": "Ēwe hānau o ka ʻāina",
		"URI": [
			"https://twitter.com/hadaloha/status/1493080687959699459",
			"https://github.com/nicholseric/nicholseric/blob/master/My%20CNFT%20PolicyIDs",
			"$conrad\augmentation\policyIDs"
		]
	}
}

Example Tweet

I created this new Cardano NFT policy!
6574f051ee0c4cae35c0407b9e104ed8b3c9cab31dfb61308d69f33c

Example GitHub

I created this new Cardano NFT policy!
6574f051ee0c4cae35c0407b9e104ed8b3c9cab31dfb61308d69f33c

Process Flow

1. Create policy for planned assets.
2. Create online platform document or Handle by inserting or augmenting with a policyID.
3. Mint no name asset with 808 metadata.
4. Mint planned assets using this same policy.
5. Existing policies can mint an appropriate 808 asset.
6. The 808 asset can be burned.

Rationale

By creating a new tag for the distinct purpose of policyID verification, Cardano Asset makers, and Marketplaces can uniformly verify their policyID’s with predictable results. By creating the instructions on a single, no name asset, all marketplaces will know the correct location of the policyID verification asset, without having to further locate it. By enforcing the requirement of honoring only the latest mint, Cardano NFT creators can move or change their social media accounts and collection information. It is easy to work with this new standard, and does not require an in depth understanding of smart contracts. One URL could potentially support multiple policyID’s. Marketplaces could choose to have these automated verified collections queue into a human review.

20220209 21:24 Discussion on Discord in Blade adahandle channel:
Special thanks to gorath for suggestions on making additional tags available for manual verification or those not wanting to use a Handle.
Thanks to BenOJosh for asking hard questions.
20200213 Discussion on CIP Proposal for discussion " Market CNFT policyID verification " with @HeptaSean and @LonacheG

[honungsburk]

As I understand this proposal it is not so much doing any verification so much as associating a policyid with some metadata the user themselves can use to verify the authenticity. Great, then creators don’t need to visit a bunch of marketplaces and enter the same information again and again. But the majority of the problem still remains… someone must still manually go and verify it (dApp or user) and as a solo dev working on a project (https://atomic-swap.io/) this proposal doesn’t really help me that much. At best I can add a couple of social links when displaying assets but that is about it. Personally, I would much rather have the user tell me exactly which assetids/policyids they trust because that information would be super helpful. Then I can directly in the GUI show them that this asset is an asset you have already verified. In my opinion that would be a lot more useful.

[conraddit]

Hello, this is Conrad from ADA Handle.
Yes, presently, we own the keys but in a near future this will be decentralized from us, with augmentation minted via Smart Contracts. The cost to augment a Handle will therefore be the transaction cost and perhaps a royalty fee to keep ADA Handle operational.
Furthermore, we are going to have a DAO that will manage all things related to ADA Handle so if the DAO votes that the augmentation costs should be higher or lower, that’s what ADA Handle will implement.
Does this make sense?

[havealoha]

808 provides the data so that markets can verify by cross checking policyID between on chain and social or other platforms. It can be automated by the market. The process does not need to be manual.
I think your proposal CIP - Decentralized Native Asset verification - #4 by havealoha and this one are complimentary.

[HeptaSean]

@conraddit

Yes, presently, we own the keys but in a near future this will be decentralized from us, with augmentation minted via Smart Contracts. The cost to augment a Handle will therefore be the transaction cost and perhaps a royalty fee to keep ADA Handle operational.

So, you will transfer the handles minted so far to this smart contract and the projects using handles will update to using the policy associated to the contract?

Still doesn’t sound completely decentralised to me.

I can choose whatever wallet app, whatever stake pool, mint my own NFTs, but this handle solution is constructed as a monopoly. It might be possible to have a second or third similar service (although the problem of same handles registered to different people arises immediately), but it becomes unhandable with many more services like this.

I really would like a standard, where I can mint my own handle, owning the private key to that mint without a third party being involved.

Sorry!

BTW: How do you handle confusable characters in your solution? Can I get “$HeptaSean” (2448657074615365616e), while someone else can get “$HeptаSeаn” (2448657074d0b05365d0b06e)?