Ethereum co-founder Vitalik Buterin has disclosed that he is increasingly using local command-line tools rather than web-based interfaces for specific Ethereum activities. In an essay published on October 31, Buterin explained that he utilized an AI-generated tool for updating content hashes on the Ethereum Name Service (ENS) and a separate command-line wallet for executing payments through privacy protocols. This shift reflects a broader concern about the security implications of relying on websites, which can deliver new application code to users each time they visit, creating recurring exposure risks.

By maintaining local applications, Buterin argues that users can retain control over which software revisions they install and use. This approach moves the decision of when to update software from the server to the individual, potentially reducing the attack surface associated with dynamic web environments. However, this method introduces new complexities regarding software provenance and dependency management.

ETH / USD
Source: CoinGecko. Prices are indicative.

Security trade-offs of local execution

The specific wallet Buterin referenced, kohaku-cli, is described in its documentation as unaudited and under active development, with significant portions written with AI assistance. The project’s developers explicitly warn users to avoid using the tool on the mainnet unless they fully understand the risks, including the possibility of catastrophic fund loss. This warning applies to the specific application level rather than serving as a verdict on the underlying protocols like Tornado Cash or Railgun, which the tool supports.

According to CryptoSlate, the practical gain of using a local interface is the ability to pin a specific software revision. However, this requires users to manage their own software supply chain. The installation process involves using npm to install dependencies and build the application, meaning the user must trust the integrity of the resolved packages and the build tools. A familiar project name does not guarantee that all accepted code is safe, as the dependency set and build parameters are critical factors in security.

Complexities in transaction signing

The internal mechanics of kohaku-cli reveal nuanced differences between public and private transaction paths. For standard public transfers, a dry-run simulation can be performed without submitting the transaction, allowing for verification before broadcasting. In contrast, private operations such as Railgun unshielding can generate a prepared UserOperation that is already signed, even if the broadcast is withheld. This means that withholding submission does not necessarily prevent a signed operation from being submitted later by compatible tooling.

Buterin’s essay highlights that software capable of constructing, signing, and submitting transactions represents distinct sources of authority. While the CLI coordinates these functions, users must assess each component separately. Additionally, the tool supports non-interactive modes that allow for automated submissions, a feature relevant for scripting and agents but requiring careful configuration to prevent unauthorized spending.