LinuxCommandLibrary

clef

SYNOPSIS

clef [global options] {command} [command options]
Common invocation as a daemon:
clef --keystore /path/to/keystore --chainid N --rpc --rpcport 8550 --rpcaddr 127.0.0.1
To manage accounts:
clef account new
To get help:
clef --help
clef command --help

PARAMETERS

--config <path>
    Specifies a configuration file for clef settings.

--keystore <directory>
    Required. Sets the directory where encrypted private keys are stored.

--chainid <N>
    Required. Specifies the Ethereum network chain ID for transaction signing.

--rpc
    Enables the RPC server for clef to accept incoming requests.

--rpcport <port>
    Defines the port number on which the RPC server listens (default: 8550).

--rpcaddr <IP>
    Specifies the IP address the RPC server binds to (default: 127.0.0.1).

--allow-origin <url>
    Sets the Access-Control-Allow-Origin header for RPC requests.

--policy <path>
    Provides the path to the Javascript policy file for transaction signing rules.

--lightscrypt-scryptn <N>
    Adjusts the ScryptN parameter for key derivation, impacting security/performance tradeoffs.

--dev
    Runs clef in developer mode, often with simplified security prompts.

--nousb
    Disables support for hardware wallets (e.g., Ledger, Trezor).

--passphrase <password>
    Provides a passphrase to unlock accounts non-interactively (use with caution in production).

--version
    Prints the clef client version and exits.

--help
    Displays help information for clef or a specific command.

account
    Subcommand. Manages Ethereum accounts within clef's keystore (e.g., `new`, `list`, `import`).

attach
    Subcommand. Connects to a running clef instance via RPC or IPC for interactive console access.

chain
    Subcommand. Manages chain-specific settings or information within clef.

DESCRIPTION

clef is an integral part of the Go-Ethereum (Geth) client ecosystem, designed as an external signer for managing and signing Ethereum transactions securely. It operates as a separate process, decoupling private key management and transaction signing from the main Ethereum node. This separation significantly enhances security by preventing the main node, which might be exposed to the network, from directly accessing sensitive private keys.

clef maintains its own keystore, where Ethereum accounts and their private keys are encrypted and stored. When a transaction needs to be signed, the main Ethereum client (or any other dApp) sends the unsigned transaction data to clef via its RPC interface. clef then applies its configured policies, potentially prompts the user for confirmation (e.g., via a UI or console), and if approved, signs the transaction with the appropriate private key. The signed transaction is then returned to the client for broadcast to the Ethereum network.

Beyond basic signing, clef features a powerful policy engine that allows users to define granular rules for transaction approval, such as limits on gas prices, transaction values, or recipient addresses. It also supports hardware wallets and various account management functionalities, making it a robust solution for secure key management in the Ethereum space.

CAVEATS

clef significantly enhances security by isolating private keys, but its effectiveness depends on proper configuration. Misconfigurations, especially concerning RPC access (`--rpcaddr`, `--allow-origin`), could expose the signing service to unauthorized access. The policy engine, while powerful, requires careful scripting in JavaScript; an incorrect or poorly written policy could lead to unintended transaction approvals or rejections. Users must secure the keystore directory and manage account passphrases diligently, as `clef` itself does not protect against a compromised operating system.

POLICY ENGINE

clef incorporates a sophisticated policy engine that allows users to define custom rules for transaction signing. These rules are written in JavaScript and are executed by clef before any transaction is signed. Policies can dictate conditions such as maximum gas price, allowed recipients, value limits, or even require manual confirmation for certain transaction types. This provides a highly flexible and secure way to control how and when clef signs transactions, acting as a programmable firewall for your private keys.

RPC INTERFACE

clef exposes a JSON-RPC over HTTP/IPC interface, enabling other applications (like geth, dApps, or custom scripts) to interact with it. Clients can send requests to clef to list accounts, sign transactions, or manage policies. This standardized interface makes clef interoperable with a wide range of tools and clients in the Ethereum ecosystem, facilitating secure remote signing without compromising key security.

HISTORY

clef was introduced as part of the broader Go-Ethereum (Geth) project with the primary goal of improving the security posture of Ethereum clients. Prior to clef, main Geth nodes typically held and managed private keys directly, making them a single point of failure if the node's security was compromised. clef emerged as a dedicated, standalone signing service, allowing the separation of concerns: Geth handles blockchain synchronization and transaction broadcasting, while clef focuses solely on secure key management and transaction signing. This architectural shift reflected a growing emphasis on enterprise-grade security and the need for robust key management solutions in the evolving blockchain landscape.

SEE ALSO

geth(1), solc(1)

Copied to clipboard