Introducing Ekubo Wallet

Today we’re introducing Ekubo Wallet, a native desktop wallet for Ethereum and EVM-compatible networks. We built it for onchain jobs too involved for a chat window and too repetitive to do by hand.

Consider this request:

Claim all fees from my ve33 votes, sell balances worth more than their gas, and max stake the STONX proceeds.

That is not one transaction or one tool call. The agent has to find every position, inspect its claimable balances, estimate whether each claim is economical, obtain current quotes, prepare approvals and swaps, calculate the final stake, simulate the dependent sequence, submit each exact action, and follow every result. If a price moves or a transaction fails, it has to read the new state and adjust.

Ekubo Wallet lets an agent do that patient work without receiving the keys. The agent can inspect the wallet, coordinate exact actions prepared by protocol services, ask the wallet to simulate and submit them, and wait for final results. When you have installed a narrow policy for the job, matching transactions can execute unattended. Anything outside that policy stops for review or is denied.

That distinction is the product: unattended execution without unattended authority.

Ekubo Wallet puts both sides of that relationship in one tray-first desktop application. It is a wallet for people, a restricted local MCP server for agents, and a WalletConnect wallet for dapps. One signing authority sits behind all three.

Complexity is the point#

The wallet exposes two different capability surfaces.

The owner interface can create and import accounts, change networks and tokens, review requests, install policy, export a private key, and adjust security settings. The agent interface can read public wallet state, pass exact producer-prepared actions to the wallet for simulation and submission, and observe their results. The wallet itself does not prepare transfers, protocol actions, or calldata.

An agent cannot approve or reject a request. It cannot install policy, export a key, accept legal terms, or change security settings. Those are not prompt-level instructions; they are separate capabilities enforced by the wallet core.

That means you can give an agent a job in ordinary language:

/loop Manage my USDC/USDG liquidity position on Ethereum. Claim fees, rebalance when the range drifts, and ask before every transaction.

Compare moving half my ETH/USDC liquidity into USDC/USDG using current pool data. Show expected balances, gas, and range risk before preparing anything.

Withdraw 40% of my most out-of-range position, collect its fees, and leave the rest unchanged.

Find every nonzero token approval from my company wallet, rank the risky spenders, and prepare revocations for the ones I choose.

Propose a policy that can only increase stake on this veNFT, with no native value and no authority over any other tuple argument.

Each request gives the agent a different kind of work. The liquidity loop is recurring but asks for review at every transaction. The migration is analysis first: nothing should even be prepared until the trade-offs make sense. The approval audit separates a broad read-only investigation from the few revocations the owner selects. The policy request defines the narrow authority a future run may use without interruption.

The agent starts by discovering the wallet’s exact accounts, networks, and chain IDs. It does not need to guess at configuration or copy addresses out of a browser extension. For protocol-specific operations, it can pair the wallet with a service such as the Ekubo MCP server, which resolves tokens, compares quotes, and prepares unsigned execution plans. The wallet independently fetches and verifies the selected plan, simulates it against current chain state, and remains the only component that can sign it.

Simulation is evidence, not authorization. A successful simulation says that an action appears able to execute against a particular state. It does not turn a forbidden action into an allowed one.

Complex jobs can also have dependent steps. Claiming changes the balances available to swap; swapping changes the amount available to stake. An agent can open a temporary simulation fork, apply each proposed plan in order, and read the hypothetical wallet and chain state after every step. That lets the producer prepare step two against the result of step one and lets the agent explain the net effect of the sequence before anything is sent.

The fork never signs, submits, creates an approval request, or satisfies a policy rule. Real execution still happens one plan at a time, with a fresh simulation and policy check against the live chain. It is a workspace for reasoning through a sequence, not a way around the signing boundary.

Let the protocol expert construct the calldata#

No wallet—or general-purpose agent—should have to know how to construct calldata for every protocol.

We built an artifact-reference boundary for efficient tool-to-tool communication. A protocol-specific MCP server can do the work it understands best: resolve current protocol state, encode exact calls, and assemble a signer-neutral, ordered execution plan. Instead of expanding a potentially large, mostly opaque blob of calldata through the model’s context, it returns an artifact_reference whose artifact type is execution_plan.

The reference names where the plan is stored and commits to its exact bytes with a byte count and keccak256 digest. The agent passes that envelope to the wallet unchanged. The wallet fetches the plan itself, recomputes its integrity information, validates its sender and chain, and refuses any mismatch. The agent does not need to fetch, restate, or reconstruct the calldata along the way.

With an HTTPS artifact reference, the calldata bytes never become model input or output tokens. The protocol server and wallet exchange the exact artifact outside the model’s context while the agent carries only a small reference. Opaque payloads do not consume the context window or slow down a sequence of tool calls, and the wallet still gets byte-for-byte integrity rather than a model’s restatement of the plan. The wallet also accepts bounded data:application/json references, but those inline bytes do pass through the agent.

The same pattern covers prepared onchain reads. An artifact_reference whose artifact type is read_calls carries the exact batch-call input needed to inspect protocol state without making the agent copy large arrays of encoded calls between tools. This is particularly useful when a preparation server needs the wallet to check several ownership, balance, liquidity, or earnings conditions together.

When an execution plan contains multiple calls, Ekubo Wallet sends them as one atomic batch through Calibur, Uniswap’s minimal, non-upgradeable EIP-7702 implementation. Calibur uses one canonical address on its deployed networks and has been independently audited by OpenZeppelin and Cantina. The wallet does not deploy a new contract or move funds to a new address: it delegates the existing account, verifies the expected runtime code at that address, and refuses the batch if the code is absent or different. It then simulates the same batch it will sign. Every call succeeds, or the entire batch reverts.

References are an efficient handoff, not a trust shortcut. The protocol server is responsible for constructing calls correctly, but it never receives keys and cannot sign. Ekubo Wallet does not need to reimplement every protocol encoder, but it still independently verifies the referenced bytes, simulates the exact plan, evaluates every call against policy, prepares the native review, and remains the only component that can sign and submit.

That separation lets tools specialize without blurring authority: one tool knows the protocol, the wallet knows custody and execution, and the agent coordinates the two without becoming either one.

Review happens where the keys live#

If policy does not already allow an action, the request enters a native review in Ekubo Wallet. The agent waits.

Every review begins on Reject. Approval remains unavailable until you have viewed the complete review and exact payload. The wallet shows raw calldata, typed data, message bytes, digests, warnings, Unicode controls, and visually confusable characters instead of replacing security-relevant details with a friendly summary.

When you approve, the wallet requires operating-system authentication. It then reloads the request and current policy and verifies that the document you reviewed is still the document being signed.

Typed-data and personal-message signatures always follow this owner-review path. They are never made automatic by transaction policy.

Unattended execution is policy-bounded#

The default policy asks you about every transaction. That is the right place to begin: run the complete workflow, inspect what the agent prepares, and learn which calls it actually needs.

When the same job becomes routine, policy lets you authorize its shape once. A running agent can then claim, quote, rebalance, compound, submit, wait for receipts, and continue while you are away, but only for calls the installed rules allow. Ekubo Wallet does not schedule the work or choose the strategy; the agent harness supplies the loop. The wallet supplies the custody boundary that makes an unattended loop practical.

Rules are evaluated in order, and the first matching rule decides a call. A rule can allow, require review, or deny an action and can constrain its network, destination, native value, and calldata. Every call in a batch must match an allow rule before the batch can proceed automatically.

There are three practical outcomes:

• A matching allow rule permits automatic signing when every call is allowed and simulation succeeds.
• A matching deny rule rejects the complete transaction, with no approval override.
• A matching review rule or no matching rule sends the request to the owner for review.

Order matters. A narrow exception can sit before a broader rule, and the wallet evaluates the policy exactly as shown.

Agents can read the active policy and propose a complete replacement. They cannot install it. The owner sees the permission change and applies it in the wallet. A widening or ambiguous change requires operating-system authentication; a change the wallet core proves only tightens authority does not require a fresh challenge. This keeps policy authoring collaborative while preserving who has authority to expand the boundary.

A loop that has to stay running is not the only shape unattended work takes. An agent can also install an automation: a small program the wallet polls on a schedule and turns into proposed calls, so a job can react to something onchain within seconds instead of waiting until you are next talking to the agent.

Installing one grants no new authority. Every call an automation proposes goes through the same simulation, policy evaluation, and review path as any other request, and an automation is bound to the policy revision it was installed against, so a later policy change stops it until you look at it again. The Automations tab shows each one with the account it spends from, its schedule, and every tick it has run. Any automation can also be dry-run against live chain state, which reports the calls it would send and whether your policy would allow them without scheduling, signing, or broadcasting anything.

Policy is deliberately about exact calls, not an agent’s prose description of its intent. A rule can constrain a function’s typed arguments, including individual positions inside a tuple. It cannot rely on a token symbol, a display label, or an optimistic simulation result. If the next action no longer has the authorized shape, the unattended run does not get to reinterpret the rule: it stops at the boundary.

Local means credential-free and same-user#

Ekubo Wallet detects Codex, Claude Code, Claude Desktop, Gemini CLI, Cursor, OpenCode, and Grok Build. Automatic setup adds a credential-free ekubo_wallet MCP entry containing only the absolute path of the bridge and a fixed client identifier. That path is fixed across releases, so updating the wallet does not rewrite the configuration of every connected agent. Where the harness supports remote MCP in the same configuration, it also adds the public Ekubo service at https://mcp.ekubo.org/mcp. It does not write a bearer token, refresh token, authorization header, client secret, or wallet key into an agent configuration file.

The harness starts that bridge over stdio. The bridge then connects to the wallet through same-user operating-system IPC: a private Unix socket on macOS and Linux or a current-user named pipe on Windows. The wallet verifies the local peer and gives it only the restricted agent API. There is no local HTTP listener, OAuth flow, bearer token, or client secret.

Claude Desktop receives only the local stdio entry. Add the hosted Ekubo service separately as an account-level custom connector through Customize → Connectors. There is no Claude Desktop plugin or MCP Bundle.

Harness providers can apply their own rules before a request reaches the wallet, so successful configuration does not guarantee that a provider will permit transaction submission. Once a call reaches the wallet, the same simulation, policy, and native-review boundary applies regardless of the harness.

We want to be precise about what that boundary does. It protects the connection from other operating-system users and keeps owner-only capabilities out of the agent API. It cannot defeat malicious software already running as the same operating-system user. “Local” is not a claim that a compromised computer is safe.

The hosted Ekubo companion is separate from local wallet custody. It receives the tool arguments sent by an agent and can temporarily store execution plans and other artifact bodies, which can identify a wallet address and intended action. It cannot read wallet keys, approve a request, install policy, or sign. The wallet independently fetches, integrity-checks, simulates, and policy-checks a referenced plan.

One wallet for agents and dapps#

The same application works with WalletConnect v2. Paste a pairing URI from a dapp and its requests enter the wallet’s native review path. Multiple sessions can be active at once, and the wallet handles account and chain requests, transactions, personal signing, typed data, and EIP-5792 requests.

WalletConnect pairings stay in memory. They do not silently persist or reconnect after the application restarts, and explicitly quitting the wallet disconnects every live session.

This makes adoption gradual. You can start by using Ekubo Wallet like a conventional desktop wallet, connect the dapps you already use, and authorize an agent only when a workflow benefits from one.

Built around a small custody boundary#

Desktop state lives in a SQLCipher database. Private keys use the operating system’s credential service. The wallet is the signing boundary; protocol services and agents prepare information for it but do not receive custody.

Each release provides a signed Apple-silicon macOS app and a signed, notarized and stapled DMG; an x64 per-user Windows installer; and x86-64 AppImage and DEB packages for Linux. The Windows installer is intentionally Authenticode-unsigned while Azure signing is pending, so Windows may show an unknown-publisher or SmartScreen warning. Updater artifacts and latest.json carry detached signatures. The app verifies an in-place update before shutting down to install it; DEB installations use the release-page fallback.

Ekubo Wallet has not been independently audited. Automated review is not an independent audit. Read the security model, start with limited funds, and install only the narrow authority a workflow actually needs.

Start with a job#

Download links, source, release notes, documentation, and community links are collected at wallet.ekubo.org. The Wallet documentation covers agent setup, the approval boundary, policy behavior, WalletConnect, and package formats in more detail.

Install the wallet, connect the agent you already use, and give it something that would otherwise take a careful afternoon:

Claim all fees from my ve33 votes, sell balances worth more than their gas, and max stake the STONX proceeds.

Ask before every transaction on the first run. Once you understand the exact calls, ask the agent to propose the narrowest policy that can repeat them. You install that authority once; the agent can then do the work unattended, and the wallet keeps deciding whether every exact action is inside the boundary.