CIP - human readable token alternative for wallet addresses

Is there a discussion in the community / in CIPs for a open human readable alternative for wallet addresses, similar to adahandle or a DNS service, with a good chance for major adoption?

If no: Should I first describe the idea in more detail here in the forum or submit a CIP draft on GitHub directly?

[italic text edited 16:53 GMT to state key goals more precisely]

Things you maybe look for: (Work in progress of mine) (Unstoppable domains seems to want to expand to Cardano.)

1 Like

@HeptaSean Thanks for your reply.

Maybe I didn’t state my goals quite well. I’m looking for a solution to pursue the following two key goals:

  1. an open solution – versus any solution with a business model, like some of the ones you mentioned
  2. one standard, supported by the whole community, maybe moderated by IOHK. You know, like in smartphone chat solutions: If I use SMS, I don’t need to know which app you prefer.

That’s why I think a CIP might be the place to start, not an existing solution – except there is already an initiative for an open standard, with good chances to rule them all. That’s the point of my question

1 Like

Okay, then the closest is the third: My attempt at a CIP that specifies how to validate the connection between a Cardano address and a DNS domain.

Got some critique in the CIP review. So, I will do an overhaul in the coming weeks.

EDIT: Actually, they wanted more motivation and use cases in the review. And my motivation was exactly that: I don’t want to be dependent on a centralised commercial service like ADA Handle, but want to use my existing domains without more costs than a few transactions and with full control.

Maybe also consider the discussion in the pull request linked at the top. That’s where CIPs are discussed more technically.

Okay, “my” solution only works if you have a domain to connect to.

I should mention that there is work currently done to connect decentralised identifiers (DIDs) to Cardano wallets somehow.

IOG has announced that that shall come with Lace:

Didn’t see any technical documentation up to now. And I don’t know if DIDs are really more user-friendly than addresses. :crazy_face:

1 Like

I was there at the meeting when this particular motivation was presented, and one of the best known developers in the Cardano community responded as if he wished he’d recognised the significance of this idea. So the decentralising quality of this proposal, once some issues like validation and metadata dependency can be addressed, will definitely make an impact:

1 Like

I feel you are giving me a bit too much credit here. :blush:
I just heard that that would be a more satisfying motivation to go on with it.

But in fact, it was in the motivation the whole time:

Maybe just too humble and too abstract. Will work on it.


Maybe the Lace wallet DID implementation is a technical solution for the given problem (to link a DID to a wallet), like Cardano wallets implement a eUTXO wallet. Maybe the solution has the same usability flaws: while every DID will have an ID, it doesn’t necessarily have a user-friendly nickname.
The Lace speculations shouldn’t stop us from discussing nickname solutions meanwhile.

Registering nick names in an open, decentralised way is non-trivial.

“My” CIP proposal circumvents that by reusing the existing DNS domains.

ADA Handle mints everything under their well-known, centralised policy.

Even if you would attach nick names to DIDs that would have to be done by some kind of centralised issuer of verified credentials that checks that they are not doubled and provides a lookup service.

We could think about a Plutus contract openly accessible by anyone as that central registry. But I also don’t see how that could avoid collisions, since it is not really possible for such a contract to check that something is not there. We would have to give it all registered names as datum and that quickly grows too large for the transaction size. …

1 Like

«requirements engineering» from a business prespective and «implementation design» are different tasks. Our individual task (yours and mine) is to bring up the requirement and to ignite the discussion. With the method of a CIP, the community can then discuss possible implementations.

Regarding the decentralised database:
If a «standard record to represent an alias» is established, this record may be issued as an NFT and placed in the corresponding wallet. Since the blockchain is an open database, anyone may build an index containing all records. Probably it is better if IOHK would build and publish the index and make it accessible over a (distributed) API. – But as mentioned above, this is just an idea to be discussed by the experts in the community.

I think this «alias meccano» is a fundamental building block for the Cardano Blockchain usability, and so it’s tied very much to the Cardano brand. That’s why I think IOHK should be the issuer of the smart contract (if that’s part of the solution) and IOHK should operate the register.

A CIP has to be a solution, has to be the implementation design. A CIP just stating some requirements that can maybe never be fulfilled won’t have any chance.

How would you ensure that no two people/wallets can register the same name? Who would have the right to issue/mint those NFTs?

Centralising at IOG is not one iota better than centralising at ADA Handle in my book. But if it is just an index that anybody else could also build it might be okayish.

Cardano is not owned by IOG and should grow independent of them in the mid-term.

1 Like

Implementation design: In the final stage, the CIP describes the implementation. But we start on the other end.

Centralising Infrastructure: An integrity check requires the whole open ledger to be verified. That’s a basic constraint. But you won’t hold a copy of the whole blockchain for this application, and browse the whole soup to find a nickname. That’s why you’ll create an index. In fact: anyone can create an index, and anyone can verify if an index is correct.

IOHK or not: As I wrote above, I am sure IOHK is willing to provide the required smart contracts and API services, since nicknames are an essential usability feature. Together with low fees and robust implementations they have strategic brand value.

Double handles: maybe the smart contract prevents creating doublets. If not: What about a timestamp: first come, first serve. Since you must create an index to make the system usable, you may check for doublets as well.

1 Like

What about if a smart contract applied a hash function to the nickname to produce a blockchain address (“nickname deposit address”) and required this address to have no UTxOs. If the address has no UTxOs then the smart contract mints an NFT representing the nickname and deposits some Ada to the “nickname deposit address”. Nobody would be able to remove this UTxO at the “nickname deposit address” because there is no known payment key for it.


In the last hours, I wrote my idea following the pattern of @HeptaSean:

  1. I created a Pre-Draft on my personal GitHub account here OCAWAN: Open Cardano Wallet Nicknames
  2. I can now post a Pull request on Pull requests · cardano-foundation/CIPs · GitHub, referring my draft
  3. When ready, I can cross-post the source to the official CIP repo
1 Like

Nice proposal. I need to think about it more.

However, one thing that I think you should do to improve it is to basically remove everywhere you suggest that IOHK should do something. The community is really trying to become more decentralised and less dependent on IOHK. Where we do need a central authority for something, it should probably be Cardano Foundation or maybe use future Voltaire voting so the entire community gets to decide.

I think you will find that the IOHK company and team members would also be more likely to approve of the CIP, if modified as described, for the same reasons.


Is it possible to have a smart contract attached to the UTxO that can enable spending without requiring the payment key for the address that the UTxO is stored at?

If so, then the UTxO could attach a smart contract that enables the creator’s own private key to spend the UTxO. This would then enable the creator to spend the UTxO if he didn’t want the nickname anymore, or if he wanted to transfer it to someone else.

@Terminada: Nice input, thanks.
You seem to more literate in blockchain implementation aspects than I am.

Is it essential to have all records distributed over the blockchain? At some point, some elements must be centralised. In your example, there’s only one smart contract. What if this smart contract maintains its own database, which is always accessible for everyone?

AFAIK, an NFT may contain a reference to an asset published on IPFS. And that file may be owned / signed by a smart contract, right?

What do you think about the following setup:

  • We have three roles <issuer>, <registrar> and <owner>.
  • The <issuer> creates a <catalog> of nickname classes and verification methods and a <smart contract> to register a nickname.
  • The <registrar> may register a nickname on behalf of a wallet <owner>. Typically, a <registrar> is an application to create and provide an interface to wallets of an <owner>.
  • The <smart contract> is available for every <registrar>. He may register a nickname by providing a simple JSON structure to the smart contract, where entities of the <catalog> are referenced, among others. He avouches to have fulfilled the verification procedures claimed.
  • The <smart contract> validates/verifies the content in the <JSON> and notably ensures the uniqeness of the nickname. On success, the nickname is added to the <index>.
  • The index is published on IPFS in three parts:
    1. A big file containing the whole index at a certain point of time in the past, maybe a day or a week old.
    2. A small file to patch the big one, with all recent mutations, updated every minute or every hour.
    3. A document containing references to the current two files mentioned above
  • Any party may read the IPFS files and implement an index, accessible within an application or over an API.
1 Like

I think you need to design out the need for an additional database since the blockchain is already a database.

What I am confused about is where @HeptaSean said:

A specific NFT can only be created once. I don’t understand why you can’t create a function that takes as input the nickname + a minting policy ID to produce a unique output that is the specific NFT. If the NFT already exists then the attempt to create it again will fail.

Isn’t it possible to make the “nickname minter” smart contract own the minting policy so that it is only possible to create the specific NFT representing that nickname through the “nickname minter”? Also, won’t this allow anyone to apply the same function of nickname + minting policy ID to look up the NFT. People could then use a blockchain explorer to see what address holds a particular NFT and if it exists.

Or maybe the nickname NFTs could all be stored at a particular address - the “nickname address”. Then the cardano-cli tool can look up the UTxOs without needing a blockchain explorer. This “nickname address” is specified in a CIP and wallets are configured to look there for nickname NFTs. The private key for the “nickname address” is controlled by the “nickname minter” contract and metadata is attached to each UTxO holding a “nickname NFT”. The metadata is the references the person wants for that nickname and a separate smart contract is also attached to the UTxO which permits the owner to spend it in order to update his metadata.

@HeptaSean would already know all this so I assume there is some error in my logic. He is likely asleep now so we may need to wait a few hours for some education.

I think you need to design out the need for an additional database since the blockchain is already a database.

This was pointed out in the thread: That’s because an index to scan all nickname records is key.

  • Without an index, it is «not really possible for a smart contract to check if something is not in the database.»
  • Think about a light wallet app implementing OCAWAN: How could the app retreive an OCAWAN record to a given nickname without scanning the whole blockchain?

That is something that can not be enforced by the Cardano chain.

Without Plutus, it was done by NFT projects promising to only mint one and using policies that are locked at some point in time, so that nobody can mint or burn after that point. But that would not be suitable here, since other names should still be mintable.

With Plutus, you have some more possibilities than just requiring some signatures and before and after slots, but it is still restricted to information given to the contract in UTxOs of the execution transaction.

That is possible, but it still doesn’t solve the “only one” problem. The contract would still need the information about all previously minted names and that is too much to be held in the datum of one UTxO, but if it is distributed in many UTxOs the contract cannot verify that all of them were given to it, and it would still be too much data for the size limit of one transaction.

Requiring that an address has no UTxOs is something that a contract cannot do. It only works on UTxOs given to and coming out of a transaction. And it only restricts the spending of UTxOs on its own address (which is the hash of its code, so only known after the fact) or the minting/burning of tokens for its own policy (which is the hash of its code) depending on the type of contract.

A smart contract cannot read external data. A smart contract is just a very small piece of code executed by every single node that verifies the transaction and it just says “Yes, this transaction is okay.” or “No, this transaction is not okay.”.

The off-chain part of a contract could read external resources from IPFS or somewhere else, but it would then have to prove to the on-chain part that that external resource really contained (or did not contain) the information that the off-chain code claims it does.

Otherwise, in a truly decentralised application, anybody could write their own off-chain code and get the contract to do what they want.

If it is not truly decentralised and the on-chain code requires some special permission and we trust the holders to do “the right thing”, we could just throw away the “smart contract” marketing, be honest, and say that that centralised entity is in control of the thing and their signature is enough.

Hard thing to do for the reasons stated above.

Instances of tokens are not distinguishable. If just the nickname is the asset name, it could not be told who of the holders of two tokens with the same name holds the first.

There could be a rather complicated construction: Encode the timestamp in the asset name and allow minting only by a smart contract that ensures that the timestamp is correct (this is a local property that can be checked by a contract). Then whoever wants to build the index can take the one with the oldest timestamp and ignore all others with the same name.

There, in fact, has been a CIP for off-chain metadata for over a year:

It does work without any on-chain shenanigans and just honestly keeps the metadata off-chain, but it does not call for a centralised service either. There could be many different services according to that standard – one by IOG, one by ADA Handle, one by me, one by you, …