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.
Keeping a copy changes the delivery decision
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.
Preparation can already involve a signature
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.
For that path, withholding submission can still leave a signed operation ready for compatible tooling to submit later. Calling the result “prepared” therefore does not make it universally unsigned. Software that may construct an authorization, software that may sign it and software that may submit it need to be assessed as distinct sources of authority, even when one CLI coordinates them.
Human confirmation is another separate choice. In the inspected public-transfer path, a suitably configured caller with wallet access can use --non-interactive together with --broadcast to submit without a further confirmation prompt. Wallet unlocking, required parameters, chain matching and simulation checks still apply. The capability is relevant to scripts and agents; it does not reveal whether Buterin uses unattended payments.
The README describes an encrypted seed on disk and owner-restricted password files for POSIX automation. Those measures govern stored secrets and how a process obtains access to them. They do not, by themselves, establish an independent spending limit or recipient policy once the process can use the signer.
CryptoSlate has previously covered the wallet-permission problem for local AI. Delivery control adds another dimension: a user can retain a chosen interface revision, while that code operates within whatever signing and submission authority it receives.
Provenance checks origin, with a separate question about behavior
Software provenance offers a way to examine the delivery side more rigorously. It records where an artifact came from and how it was built. The SLSA verification standard describes checking a provenance signature, matching the artifact’s digest, recognizing a trusted builder and comparing the stated source and build parameters with expected values.
These checks can help distinguish an expected build from a substituted artifact or an unintended build source. They still depend on which builders and source expectations the verifier trusts.
Dependency checking remains its own task. SLSA describes recursive verification of resolved dependencies as an optional additional step. Authenticating the top-level artifact does not automatically authenticate every input to it.
Correct origin and build history can accompany application logic that the user would still reject.
Network privacy is similarly separate from application delivery. The CLI documentation describes Tor by default for certain non-RPC traffic while Ethereum RPC stays on the ordinary network connection. Running the interface locally therefore does not make every external interaction private. Earlier Kohaku and verified-RPC coverage concerned another part of this broader trust problem.
Buterin’s experiment points to a concrete form of user control: choosing the application code that stays on the machine and deciding when to accept replacement code. Its value depends on carrying that control through dependency selection and the signer.
