The relaunched private payments wallet uses ENS-powered tags like joe.zk.money to give users a human-readable way to send and receive funds without making their financial history public by default.
zk.money is back, and this time its private accounts come with ENS-powered names.
The relaunched self-custodial wallet lets users claim tags like joe.zk.money, giving private onchain payments a human-readable destination without turning a user's financial history into a public profile.
The original zk.money launched in 2021 and reached more than 75,000 unique wallets and $100 million in volume before being retired in 2023. Aztec Labs spent the following years building and launching Aztec Network, the decentralized privacy infrastructure network that the new zk.money operates on.
Now, zk.money is returning as a self-custodial wallet for sending and receiving crypto privately.
Onchain payments usually start with an address.
That works well for machines. But a long hexadecimal string is harder to recognize, harder to remember, and particularly unforgiving when money is involved and funds can be sent to the wrong place.
zk.money replaces that part of the experience with a tag.
When someone creates an account, they can claim a name such as joe.zk.money. The tag is secured by a passkey that syncs across devices, and users can share it instead of repeatedly copying a 0x address.
Those tags are powered by ENS and resolve wherever ENS CCIP Read is supported, allowing ENS to resolve data stored on L2s or offchain. Aztec Labs also says users can receive funds to a zk.money tag directly from exchanges on Ethereum.
That makes the name more than an in-app username. It becomes a human-readable entry point into the account.
The more interesting part of the integration is what sits behind the name.
On Ethereum, once an address is associated with someone, much of the activity connected to it can usually be inspected on a public ledger. Balances, transfers, counterparties, and transaction history can all become part of the same public trail.
zk.money is built around a different default. Transaction amounts and counterparties aren't published to the public ledger, while users retain control over who can access information about their account. Anyone can send funds to a zk.money tag, but the tag itself doesn't expose the user's balance or transaction history.
That creates a useful separation between the name someone shares and the financial activity behind it.
zk.money also adds a verification step to resolution. The resolver returns a zero-knowledge proof showing that the destination was correctly derived from the user's registration, which is verified locally before funds are sent. Each resolution also produces a fresh deposit address rather than repeatedly returning the same public Ethereum address.
ENS provides the human-readable name someone can share, while zk.money can verify where funds should go without exposing a permanent public payment address behind that name.
That matters because privacy can otherwise make payments harder to navigate. With zk.money, someone can keep sharing joe.zk.money even while the destination underneath it changes.
Every resolution generates a fresh deposit address, with a zero-knowledge proof verifying that the address was derived correctly. Funds sent there are routed to the user's private account, while the Ethereum L1 deposit address doesn't reveal which zk.money tag it belongs to.
So joe.zk.money can remain the identifier a user shares again and again without requiring the same Ethereum address to sit publicly behind it every time.
The human-readable identity stays consistent while the payment destination beneath it can change.
zk.money also extends the tag beyond basic resolution.
Users can generate links to send or request funds and share them directly with contacts, including people outside zk.money. The aim is to make the payment flow feel closer to sharing an identifier or payment link than manually managing addresses.
Passkeys are another part of that experience. zk.money users can secure their tags using a passkey that syncs across devices, removing the need to rely on a seed phrase for this part of the account experience.
Together, the tag, passkey, and payment links make the name part of the product itself rather than something added after the fact.
ENS names already resolve to many different kinds of onchain resources. zk.money is another example of how broad that model can become.
zk.money shows how different the account behind an ENS name can look. Someone can keep using the same recognizable tag while each resolution produces a fresh, cryptographically verified deposit address underneath it.
Users don't need to understand the proofs or account architecture that make the payment possible. They can share a name.
For zk.money, that name is powered by ENS.