Is there a good way to keep personal data (e.g. name, address , etc.) in the ERC721 metadata JSON, encrpyted with the public key of the owner, so that only the owner can decrypt it with his/her private key on request?

My use case looks as follows:

  1. A user connects his wallet to a Dapp using Wallet Connect
  2. The Dapp requests some personal data from the metadata (ERC721) which is encrypted by the user's public key
  3. The user confirms the request on his wallet (Wallet Connect)
  4. The personal data can get decrypted by the user's private key

2 Answers 2


The most common wallets of Ethereum do not offer ways to encrypt/decrypt messages.

While your idea is theoretically solid and can be done in some private experiment, it is not practically possibly to have this sort of system for public use on Ethereum at the moment.


I can quickly think of a way in which this can be done off the top of my head.

You can encrypt the data asymmetrically then pin it on IPFS. The IPFS endpoint can be stored within the ERC721 URI. Your Dapp could read and download the IPFS data and asymmetrically decrypt it with the user's private key.

An issue you would have would be getting a hold of the user's public key to perform encryption. Wallet connect as far as I am aware, and I may be wrong, does not expose a public key, only an address. Your Dapp would have to reconstruct each user's public key from a transaction that they have signed. see this -> Get public key of any ethereum account

You can get around this by having your user send a transaction to a contract registering to your Dapp, store the address of that transaction then reconstruct the user's public key from there.

The same is true the other way around. Wallet connect will not expose the user's private key. The user will have to input their private key into the Dapp or perform decryption of your JSON offline.

As I said at the top, these are just initial thoughts about limitations you may have, there could be other ways in which this is possible. I think this is a very interesting use case so let me know which approach you end up taking.

  • Hi @cheethas. Thank you very much for your proposal. Sounds very promising. Another idea would be to let the user sign an arbitrary string and use then the signature as key. The signature could be triggered by calling the sign()function of WalletConnect. What do you think?
    – user66732
    Commented Mar 28, 2021 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.