Vitalik Buterin Uses Private Ethereum Payments via Kohaku-cli Tool

Ethereum co-founder Vitalik Buterin said in an October 31 essay that kohaku-cli handled many of Buterin's payments involving privacy protocols. Buterin also said an AI-written command-line tool handled recent updates to IPFS content hashes on ENS, Ethereum's naming system. The ENS updater was a different application from the payment wallet. Buterin objects to websites supplying application code anew on return visits, which makes users repeatedly dependent on the server's delivery.

A locally retained application lets the user keep a selected software revision and decide when to install a replacement. The accepted code mediates between payment instructions and the signatures that authorize payments, so dependencies and signing access remain consequential. Kohaku-cli's documentation describes the application as unaudited, AI-assisted and under active development. The documentation advises users against mainnet use unless users understand the activity and the risk of catastrophic fund loss. Kohaku-cli supports public Ethereum accounts and private balances through Tornado Cash, Railgun and Privacy Pools V1. The wallet is separate from the broader Kohaku toolkit of protocol libraries and wallet infrastructure, so the application's warning is not an audit assessment of every underlying component or protocol.

The installation instructions require users to fetch dependencies with npm install, compile the application with npm run build and execute a local launcher. At commit 0ef5c44, the documentation, manifest, lockfile and implementation correspond to one application revision. The manifest specifies version 0.1.0 and Node.js 22 or later, but Buterin did not identify the revision installed for Buterin's use. The manifest pins direct dependencies, including viem and several Kohaku packages, and fixes the separate kohaku-artifacts Git dependency to a commit. The lockfile supplies resolved registry packages and integrity hashes, demonstrating that a local interface still depends on a software supply chain. Accepting a replacement through this source-build process therefore involves accepting dependencies and build tools, not merely a familiar project name.

For an ordinary public transfer without batching, the implementation simulates the transaction and produces dry-run results without submitting the transaction. Broadcasting requires the sender's private key and a locally constructed wallet client whose signing account comes from that key. A Railgun unshield command can instead produce a prepared, already-signed UserOperation without broadcasting the operation. A UserOperation contains an account-operation payload that compatible tooling can submit, and the separate broadcast implementation sends a signed operation through a Pimlico bundler. Withholding submission therefore does not always withhold a signature, because compatible tooling may later submit the signed operation. Authorization construction, signing and submission represent distinct forms of authority even when a single command-line application coordinates the activities.

In the inspected public-transfer implementation, a properly configured caller with wallet access can combine --non-interactive and --broadcast to submit without another confirmation prompt. Wallet unlocking, mandatory parameters, chain matching and simulation checks remain applicable. This capability matters for scripts and agents but does not establish that Buterin makes unattended payments. The README describes disk storage for an encrypted seed and password files restricted to the owner for POSIX automation. Those protections control secret storage and process access, but the protections alone do not impose independent spending limits or recipient rules after a process gains signer access.

Software provenance records an artifact's origin and build process, providing a way to assess application delivery. The SLSA verification standard calls for validating the provenance signature and artifact digest, recognizing a trusted builder, and checking source and build parameters against expectations. These checks can help identify substituted artifacts or unexpected build sources, but their effectiveness depends on the verifier's trusted builders and source expectations. SLSA treats recursive verification of resolved dependencies as an optional extra, so authenticating the main artifact does not automatically authenticate every build input. An application with valid origin and build records can still contain behavior that the user would reject.

The CLI documentation specifies default Tor use for some non-RPC traffic, while Ethereum RPC traffic uses the normal network connection. A local interface consequently does not make every external interaction private. Retaining application code and controlling replacements gives users a concrete form of control, but the benefit depends on extending that control to dependency choices and signer authority.