Providing access to the Public Key of a wallet and the ability to decrypt messages encrypted with that public key will create a good platform for having “p2p” on-chain encrypted communication channel.
More details: Trying to find equivilent for encrypt with public key web3auth
Hi 0xOZ,
Thanks for reaching out with your interest in enabling “p2p” on-chain encrypted communication using Web3Auth. It seems like you’re exploring how to access a public key for encrypting messages.
Currently, Web3Auth focuses on user authentication and wallet management rather than directly facilitating encryption and decryption processes. However, if you’re looking into creating such a feature, you might need to extract the public key from the user’s wallet and use additional libraries or services to handle the encryption and decryption.
Here are a few steps you could consider:
Extract Public Key: Once a user logs in via Web3Auth, you can use Web3.js or Ethers.js to access their wallet public key.
Use Encryption Libraries: Libraries like eth-crypto or ethereumjs-util can be used to handle encryption and decryption with the public key.
Since this is a feature exploration, there isn’t a direct example or support from Web3Auth for this use case. However, community feedback and suggestions like yours are valuable for shaping future enhancements.
Feel free to check out the Web3Auth Developer Documentation for more on available functionalities: Web3Auth Docs.
If you have more questions or a different scenario to discuss, keep them coming. We’re here to help!
Note: This response was generated by an AI bot and may require further verification. The Web3Auth support team has tracked this issue and will be responding as soon as possible.
Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. Web3Auth Developer Office Hours
This is an interesting idea and it’s great to see creative thinking around on-chain communication. That said, there are a few important technical and practical challenges that might make this approach less ideal in practice:
1. Asymmetry in Encryption/Decryption
Using a public key for encryption works well when sending private messages to someone, but not for mutual two-way communication. Each participant would need to share and use each other’s public keys, and manage encryption/decryption accordingly. This introduces complexity that’s not immediately obvious from the original concept.
2. On-Chain Data Visibility
Even though encrypted messages would be unreadable to third parties, the fact that they’re stored on-chain means the data (e.g. metadata, sender/receiver addresses, timestamps) is still publicly accessible. This could lead to unintended privacy leaks, even without decrypting the messages.
3. Cost and Efficiency
Storing any data on-chain, especially encrypted messages, comes with gas costs and can quickly become expensive. Over time, this could lead to significant inefficiencies and make the solution difficult to scale.
4. Security Considerations
Without additional layers like forward secrecy or ephemeral key exchange, messages encrypted with static public keys could be vulnerable if a private key is ever compromised. This is especially concerning for long-term or sensitive communications.
5. Existing Alternatives
There are off-chain protocols (such as Waku or Libp2p) designed specifically for secure, encrypted P2P messaging that can integrate with on-chain identity systems. These can offer a better balance of scalability, privacy, and user experience.
In summary, while the vision of on-chain encrypted communication is compelling, there are some architectural and cryptographic concerns that might limit its effectiveness. Exploring hybrid solutions—where identities and permissions live on-chain, but messaging happens off-chain—might strike a better balance between decentralization and practicality.
Thanks for the reply,
Considering only my specific use case is limiting how it could be used, however, here is a reply to your chatgpt-generated considerations:
I am working on a small project for my graduation, which resolves the issue of sharing/managing these keys.
That’s right, these metadata are annoying and still need long-term development for few months to see if it’s possible to solve it with similar technology to tornado cash,
That’s for Ethereum Mainnet only; if used on an L2, that’s not going to be an issue, and using a good encoding and considering data encoding for large/all messages will solve part of the issue.
If your private keys were ever compromised, there is much more to worry about than your communication with others; PKs leakage is always an issue related to itself, not how critical the application that uses them is.
For that exact reason, I was considering using a wallet SDK like this (web3auth) instead of normal wallets like MetaMask and others.
So, regarding that, will there be any support for such API calls? The only need is to have a function/message call that will request the Public Key, and another that will try to decrypt a message using its own private key, and the above discussion is to not worry about.
Thanks for the detailed follow-up — appreciate the clarification!
Your graduation project sounds intriguing! 
Out of curiosity, could you share a bit more about it? Always interesting to see fresh approaches, and who knows — your idea might just be what the space needs. What makes you confident the method you’re exploring can solve the key sharing/management issue?
Totally hear you on metadata — it’s the kind of “fine print” that ends up being a headline problem. The Tornado Cash-like approach is ambitious. Definitely a spicy angle for privacy on-chain. Curious to see how that pans out, especially on L2s where some of those data constraints ease up a bit.
You’re absolutely right: once a private key is compromised, the barn’s already on fire — it’s not just about messaging at that point. Still, building systems that minimize blast radius is always a win.
And yes, that’s exactly where Web3Auth wallet SDKs shine — abstracting the key management away from end users without compromising usability or security. We like the way you’re thinking. 
As for the on-chain solution and the API calls you mentioned — that’s a really cool idea. Having a standardized way to fetch the public key and perform decrypt operations would open up a lot of interesting use cases. We’d love to hear more about how you envision it working, and how Web3Auth can support it.
Let’s keep this conversation going — sometimes graduation projects end up being the next big thing 
It’s a bunch of issues to work on, and it’s more about connecting different things, so it’s not worth much of a mention here, but…
The public key management part is not that difficult, It doesn’t need any complex or innovative approach to solve. my simple approach is to simply store the public keys on the chain.
For example, whenever you are trying to send someone an encrypted message on chain or if you need access to their public key for any reason, you can request it from a universal contract. With basic features added to that contract, you can make it work the way you want. Whether you want to share an encrypted secret or whatever, the public key being accessible is your entry for that whatever.
And when the private keys are being handled using technology like Web3Auth, that’s going to make it more comforting to use such technology.