Vitalik is making private Ethereum payments without a crypto website

Vitalik Buterin is moving some of his Ethereum activity out of website interfaces. In his October 31 essay, the Ethereum co-founder said he had used an AI-written command-line tool for recent IPFS content-hash updates on ENS, Ethereum's naming system, and kohaku-cli, a command-line wallet, for many payments through privacy protocols. The ENS updater and payment wallet were separate tools.

His objection goes beyond screen clutter. A website can deliver application code again whenever someone returns, leaving the user dependent on what the server supplies each time. Keeping a local application can reduce that repeated delivery exposure. It also moves a consequential decision onto the user: which software revision to install, retain and eventually replace.

The wallet he linked makes the trade-off concrete. Its documentation warns that the CLI is unaudited, under active development and written with AI assistance. It tells users to avoid mainnet unless they understand what they are doing and the possibility of catastrophic fund loss.

Control over a downloaded interface matters because the accepted code sits between a payment instruction and the signature authorizing it. Choosing when that code changes can reduce one recurring exposure, while its dependencies and signing access determine what the installed software can do.

The practical gain is the ability to keep a chosen application revision rather than obtaining the website interface again on each visit. Accepting a replacement revision creates another delivery decision. For this source-build route, that decision also involves the dependency set and the tools that turn source into executable software. A familiar project name alone does not describe all the code being accepted.

Kohaku-cli handles public Ethereum accounts and private balances on Tornado Cash, Railgun and Privacy Pools V1. It is a particular wallet application, distinct from the broader Kohaku toolkit of reusable protocol libraries and wallet infrastructure. Its warning should be read at that application level, rather than as an audit verdict on every component or protocol it uses.

The documented installation route also shows what “local” entails. The project's instructions call for installing dependencies with npm install, building the application with npm run build, and running a local launcher. At commit 0ef5c44, the documentation, manifest, lockfile and implementation describe the same application revision. Its manifest identifies version 0.1.0 and requires Node.js 22 or later. Buterin's account does not identify his installed revision.

The manifest fixes direct dependency versions, including viem and several Kohaku packages. It also pins a separate kohaku-artifacts Git dependency to a commit. The corresponding lockfile records resolved registry packages and integrity hashes. The application therefore has a software supply chain even when its interface runs on the user's machine.

Kohaku-cli's public-transfer and Railgun unshield paths show why a pause before submission can mean different things. An ordinary public-transfer dry run returns without sending the transaction; a prepared Railgun unshield can already contain a signature.

For an ordinary, non-batched public transfer, the transfer implementation simulates the transaction and returns dry-run output without submission. The broadcast path requires the sender's private key, constructs a local wallet client and sends the transaction. The wallet-client code derives its signing account from that private key.

Private operations expose an additional wrinkle. The unshield command can output a prepared Railgun UserOperation that is already signed, even when broadcasting is withheld. A UserOperation is an account-operation payload that compatible tooling can submit. The separate broadcast implementation expects a signed operation and then sends it through a Pimlico bundler.