The Ethereum Foundation officially announces a detailed analysis of Kohaku's end-to-end privacy solution and user experience.

Author: Zhixiong Pan

Source: chainfeeds

Although the Ethereum Foundation officially announced the privacy wallet tool project Kohaku yesterday, it was actually confirmed through some channels as early as June this year.

Kohaku will span multiple team collaborations, integrating various components to create a complete browser wallet plugin for reference by other wallets, enhancing end-to-end privacy. This includes the Helios light client developed by a16z, the PSE team from the Ethereum Foundation, and projects like Ambire, Railgun, and Wonderland.

The origin of the word "Kohaku" is quite interesting, as the project is a fork of Ambire, so the Japanese word for Amber was chosen: Kohaku. However, in Japanese, it also has the meaning of "koi" (specifically the red and white ones), so the project also used koi as its image.

What is Kohaku?

Kohaku is a set of privacy and security primitives and SDK for "wallets," along with a reference wallet (browser extension) aimed at advanced users, designed to actually implement these capabilities.

Kohaku is not aiming to create a mass-market C-end wallet, but rather to provide composable privacy/security building blocks for various wallet teams, allowing you to connect to "all" or "part" (plugin-based) as needed. The initial focus is on privacy features, with the reference wallet being a browser extension branched from Ambire. The official emphasis is on prioritizing the mainnet, and then gradually supporting L2 (with attention to the capability of "fast withdrawal").

The core objective of Kohaku is:

1. An SDK for a strong privacy/security primitive;
2. A reference wallet based on this SDK, aimed at heavy users;
3. Collaborate with other wallets to access all or part of the capabilities as needed;
4. The reference wallet is a fork of Ambire, prioritizing the mainnet, and then adding L2.
5. Both the SDK and reference wallet come with a plugin system, allowing each wallet team to select features as needed.

Core Direction: Not only "on-chain privacy", but also "end-to-end".

Kohaku's privacy is not simply about "putting transactions into a private pool"; rather, it considers trustlessness and exposure at every step from device to node. The roadmap lists a very clear "privacy/security checklist:"

• Built-in Helios light client (WASM): Bring blockchain state verification to local execution, minimizing reliance on centralized RPC. (Helios is a multi-chain Ethereum light client developed by a16z that can be compiled into WASM, suitable for embedding in wallets and dApps.)
• Minimum execution client + private eth_call: Even if it's just reading the on-chain state (common eth_call), it should "not let the server know what you're reading." The roadmap states that "TEE + ORAM (Trusted Execution Environment + Oblivious RAM) will be implemented first, with the long-term goal being pure cryptographic PIR."
• Private Sending / Private Receiving / Private Payment Request: The wallet has built-in multiple privacy protocols (including Railgun in the first batch), supporting "private sending/receiving" and "encrypted payment requests".
• Unified view of private balances (multi-protocol aggregation): If you have funds across multiple privacy protocols, the wallet will provide an aggregated view.
• Avoid IP leakage and hide traffic, optional P2P broadcast transactions (bypassing traditional RPC broadcasting).
• Default "One dApp One Account" when connecting to dApp: naturally reduces address correlation.
• Social Recovery (ZKEmail / ZKPassport, etc.): Using zero-knowledge to perform "recovery" without disclosing identity.
• Post-quantum "Emergency Switch": Can switch to post-quantum signatures such as Falcon/Dilithium when necessary (Solidity validator optimization) to guard against quantum security risks.
• General Hardware Ethereum App / ZK Hardware Signer / Spending Limit Policy: Create an open-source reference implementation for hardware capabilities to break vendor lock-in and introduce more detailed "spending strategies."

You can understand it as follows: Railgun and other "on-chain privacy pools" are one of the foundations, but Kohaku also needs to address the "leaks of privacy" from node trust, network broadcasting, front-end connections, recovery, and hardware signing, in order to achieve "end-to-end minimal exposure."

Roadmap and Collaborative Ecosystem

• Phase 1: Privacy/Security Basic Capabilities.
• Continuous Direction: Keep the wallet as "close to the device/kernel" as possible, and even explore a "native Ethereum browser" in the future, combined with deeper integration of IPFS front-end, P2P, and local AI transaction security scoring (without leaking data), etc.
• Collaborative teams: Ambire, Railgun, Wonderland, Helios, PSE, Oblivious Labs, ZKnox, etc. 

Product form: SDK + Reference Wallet (Browser Extension)

• SDK: A "Privacy/Security" composable module for other wallet teams.
• Reference Wallet (Kohaku Extension): A browser extension branched from Ambire, designed to "activate these privacy and security capabilities, demonstrate and prototype," targeting advanced users rather than a final product for the general public.
• On the GitHub side, we can see that the main repository (ethereum/kohaku) is a monorepo that lists the @kohaku-eth/railgun package ("railgun privacy protocol lib"). Additionally, there are the kohaku-extension and kohaku-commons repositories, where the former is the extension code (based on Ambire), and the latter is the public logic library of Ambire (which has been branched in).
• The warehouse homepage also提示: still under development, not ready for production environment.

Why is it more "private" than MetaMask?

Let's first talk about the current situation of MetaMask or other wallets:

• You are using a public account (EOA), the address and transactions are permanently public.
• When you interact with a dApp, you often go through centralized RPCs (such as Infura), and the RPC service can see your requests and IP.
• Using the same address to connect to different dApps can easily lead to on-chain analysis and association analysis.

How does Kohaku rewrite this path? Kohaku uses a set of "end-to-end" methods to block "associable information" as much as possible, with the core differences in these three layers:

On-chain transfer itself

• Through protocols like Railgun, you first Shield (deposit) "the money you want to transfer" to a private address (0zk), and then conduct "transfers/interactions" within the private pool; what is visible on the chain are new commitments/Nullifiers (to prevent double-spending) and other encrypted records, without directly exposing the source, destination, or amount of funds. The Railgun documentation clearly states: 0zk addresses never appear on the chain, and the system updates states and prevents double-spending based on UTXO/Note + zk proofs.
• Note: Shield and Unshield (withdrawal) are visible on-chain (because you need to deposit/withdraw ERC-20 from the contract), but the "transfer, exchange, and call" within the pool are private. Railgun currently charges a fee rate of 0.25% for Shield actions (decided by its DAO; only Shield has a fee, private transfers within the pool are free).

Interact with Nodes/Network

• Wallet embedded with Helios light client: Many read verifications are done locally, reducing trust and exposure to RPC (especially for reads). 
• The planned "private eth_call": even if it is just reading the on-chain storage, it should be done through TEE+ORAM (the long-term goal is PIR) so that the counterpart cannot see what you specifically read.
• Optional P2P broadcasting: Do not connect directly to send transactions through traditional RPC, reducing the probability of binding "your IP + your transaction."

Frontend/Connectivity and Associability

• Default "One dApp One Account": Every time you connect to a dApp, the wallet will suggest using a "new address/new account" to avoid cross-site tracking.
• Private payment request / Private receipt: The "0zk payment information" passed to the other party via link/QR code for receiving funds does not appear on the chain.
• Social recovery also uses ZK: for example, ZKEmail, ZKPassport, Anon Aadhaar, making the act of "recovery" not leak privacy.

Complete User Experience from MetaMask to Kohaku

You can understand it as: first put the money "into a private wallet room", do things inside, and then decide how to "exit the room".

• Step A: Install the Kohaku browser extension, import your mnemonic phrase or create a new one.
• Step B: Enable "Private Mode" in the settings and check the Railgun plugin (Kohaku supports multi-protocol plugins). The wallet will locally generate key materials for 0zk.
• Step C: Shield (Deposit): Deposit the ERC-20 tokens you want to use "privately" into the Railgun contract (if it is native ETH, it will be wrapped into wETH before depositing, this is the rule of Railgun). This step is visible on-chain (because it involves sending money to the contract), but this is the only "public transaction" to "enter the privacy space."
• Step D: Conduct transfers / Swap / LP / interact with dApp contracts in the private pool. A ZK proof will be generated locally here, and on-chain you will only see updates to the commitment/Nullifier, without revealing how much you transferred and to whom.
• Step E: Private Payment: You can send the 0zk payment link/QR code to others, and this address information will not appear on the chain.
• Step F: If necessary, Unshield to a new public address (preferably do not return to the original address to reduce association). Some protocols or frontends may have a configured delay window/compliance checks (for example, the Privacy Pools direction and Railgun community's proof mechanism); the Railgun ecosystem has also introduced mechanisms such as "a short observation period that can only be returned along the original route" to balance compliance.
• Step G: Optionally enable P2P broadcasting, independent accounts for each dApp, and Helios local verification, further reducing "bindable metadata".

Which part is still visible?

• The deposits (Shield) to the privacy pool and the withdrawals (Unshield) from the privacy pool are both public transactions. However, transfers/interactions within the pool are private (the sender, receiver, and amount are not visible; only the "pool status" is updated).
• If you directly transfer the "withdrawal" back to the "public address you previously deposited into", it may still be "reasonably guessed" by analysts that the two are related—it's better to withdraw to a new address or continue spending within the privacy domain.

Summary

Kohaku introduces a new paradigm of privacy and security for the Ethereum wallet ecosystem, going beyond simple on-chain privacy protocols and deeply integrating towards end-to-end privacy protection. It will significantly enhance the privacy experience for users interacting with decentralized applications, changing the current prevalent transparent on-chain behavior model, and setting a new standard of "default privacy" for future wallet products.

As its SDK and plugin system are widely adopted by more wallet teams, the way users interact with the blockchain may be reshaped: from transparency to privacy, from centralized trust to local verification, from on-chain public identity to zero-knowledge identity. Kohaku will promote the Ethereum ecosystem into the mainstream era of privacy applications, accelerating the exploration of innovative models coexisting compliance and privacy protection, and laying a crucial foundation for the decentralized internet to enter the next stage.