Ekubo Wallet 1.4.0 — First Public Release

Ekubo Wallet is a native desktop wallet for EVM accounts used by three kinds of caller: a person at the keyboard, local AI agents over MCP, and dapps over WalletConnect. One tray-first process owns the encrypted state and the private keys. This is the first public release.

Read this before installing

Windows and Linux store account keys in a credential service that does not isolate them to this application. On those platforms, same-user malware — including a prompt-injected local agent allowed to run programs as you — can read raw account keys and the database key directly from the OS credential store, without going through the wallet at all. That path bypasses policy, native review, and the wallet's own audit records, and closing the wallet does not remove the credentials.

This is an open defect, not an accepted guarantee. It is tracked in #112 and the redesign is required work. Until it ships, do not keep valuable accounts on Windows or Linux unless you can be confident nothing untrusted runs as your user.

macOS is materially stronger: the Keychain backend ties item access to the creating application's code-signing requirement. It still does not defend a compromised wallet process, signing identity, authenticated owner session, or operating system.

The full analysis is in the threat model.

The Windows installer is not Authenticode-signed in this release, so Windows will show an Unknown publisher prompt and Microsoft Defender SmartScreen may warn you. Verify the installer against the digest and detached signature published with it rather than trusting the prompt. macOS builds are signed, notarized, and stapled.

What it does

Policy decides what signs without you. An ordered list of rules matches each call in an execution plan and the exact transaction envelope prepared to carry it — chain, target, calldata by decoded ABI argument, native value, nonce, gas, fees, and EIP-7702 delegation. The first matching rule wins: allow signs automatically, review sends it to you, deny refuses outright and cannot be approved. Anything no rule covers goes to you as well, so the safe default is silence. Nothing an RPC endpoint reports can reach a policy decision.

Rules can also constrain who asked. A rule may name the channel that delivered the plan — an agent, a WalletConnect dapp, or one of your installed automations — and, within it, the harness that identified itself, the TLS-verified host that served the plan, or the automation's own id. Fields that are the requester's word rather than something the wallet proved are named as claims, and constraining a source can only ever narrow a rule, never grant it new authority.

Local agents get a narrow surface. Harnesses launch a small stdio bridge that connects to the wallet over same-user local IPC. The bridge never receives a key store, an arbitrary signature operation, owner authorization, or key export — only the ability to persist requests and ask for guarded execution. Agent input is treated as hostile throughout.

Automations run unattended, under the same policy. Installed automation bytecode emits calls on a schedule; every call is evaluated against your installed policy at send time, so installing one grants no authority the policy has not already given.

Changing the policy is its own decision. You review a minimized diff of the authority that moves, in your own words rather than as JSON. A change the wallet can prove only tightens authority installs without a fresh OS challenge; widening or ambiguous changes require owner authentication.

Every send is simulated first, through standardized eth_simulateV1, and the exact envelope that will be signed is prepared from that result. Simulation IDs grant nothing: submitting always re-simulates, re-prepares, and re-evaluates the current policy.

WalletConnect sessions are approved per dapp with the dapp's self-asserted identity presented as claims rather than laundered into an identity card, with a fixed seven-day deadline. Personal-message and typed-data requests always require your review.

Supported agent harnesses

Codex, Claude Code, Claude Desktop, Gemini CLI, Cursor, OpenCode, and Grok Build.

Verifying what you downloaded

Every artifact ships with a detached Minisign signature, and latest.json binds each version, target, canonical URL, SHA-256 digest, and artifact signature. The updater public key is published as a repository variable. Release artifacts are built by a workflow with read-only repository permission and no credentials; a separate trusted stage verifies GitHub's artifact attestation for every byte before any signing key is available to it.

Updates are downloaded and verified before shutdown, and always ask you before installing.

Platforms

macOS (Apple silicon), Windows x64, and Linux x86_64 as AppImage or DEB. DEB installations update through the release page rather than in place.