0zk Address Support / Kohaku

Feature Requests
1

Description:
Add support for 0zk addresses: the shielded address format used by the RAILGUN protocol. At minimum, this could mean recognizing 0zk balances, 0zk addresses as valid send targets (similar to ENS resolution) and routing the transaction through RAILGUN’s relay infrastructure or even “self-broadcasting” or a paymaster solution. A deeper integration could include a “shield” flow directly within the send UI from the standard 0x address to the user’s own 0zk address.

Purpose:
Privacy is a legitimate and increasingly mainstream need for Ethereum users. RAILGUN is a non-custodial, fully audited ZK privacy layer deployed on Ethereum, Arbitrum, BSC, and Polygon, and unlike older approaches, it ships with built-in compliance tooling (PPOI) that lets users cryptographically prove funds don’t come from sanctioned sources.

Kohaku recently added native RAILGUN + PPOI support, and MetaMask supporting 0zk addresses would be a meaningful signal that privacy is a first-class concern.

If a full native integration isn’t feasible short-term, a MetaMask Snap could potentially cover this. I’m curious whether that path has been explored or what the team’s thoughts are on developing this internally or being open to review a community contribution for either Kohaku integration or just integrating the Railgun SDK.

Extension/Mobile/Both:
Extension

Images/Attachments:
N/A

1 Like
2

Hi! Thanks for creating the feature request.

4 Likes
3

Any updates on this? Would love to have a discussion, especially with everything thats been happening with ZEC and the wider ZK space.

4

Hey @danlipert ! Thanks for checking in!

Feature requests are a long-term game. After a post is made, it gets logged internally for our teams to review during their planning cycles.

Because of this, there won’t be a specific update after just a few days. However, please be assured that we have seen your suggestion and it’s been added to the list for consideration.

We really appreciate you taking the time to share your ideas with us!

2 Likes
5

Snaps would be a perfect fit.
Snaps are mostly developed by external teams. They’re currently only supported on Extension, but we’re working to bring them to mobile as well.

Docs are here: Snaps introduction | MetaMask developer documentation
But the TL;DR: If it interacts with keystore, the Snap needs to be reviewed by one of the approved external security auditors, then submitted for allowlisting, then it’ll be shown on the Snaps directory and users can install it.

3 Likes
6

Thanks Hiro for your reply. I spent some time looking into this last week, and it seems it would require support for custom curves and derivation paths. Maybe it could be a external-hardware only system, where key generation and signing could be done on a ledger, etc., but also I think there would be some problems with proving, specifically the keyfiles used I believe are larger than the snaps sandbox would allow. What do you think?

7

Anyone have any thoughts on this? I’m starting to think the only way forward is by using a ledger etc., without some deeper integration with MM…

1 Like