Smart Agent Wallet

That agents need wallets is already settled: an agent that cannot move money is just a recommendation engine, and the whole industry is racing to hand every agent one.

The neglected half is the reverse — wallets need agents just as much. The moment an agent can spend, the wallet behind it becomes the single largest risk in the system, and people were never equipped to verify what they sign. Even clear-signing standards like ERC-7730, which translate opaque calldata into readable intent — 0x414bf389… becomes "Swap 1,000 USDC for 0.42 ETH on Uniswap" — only show what a transaction claims to do. Knowing what it will actually do still means reading the target contract, tracing the downstream calls, and simulating the result: analysis no person can perform in the seconds before tapping "approve." Clear signing makes a transaction legible; it does not make it verified. Closing that gap is an agent's job — which is why the wallet needs one of its own.

This is the first post in a series on the agent-native wallet. It starts with what "smart" should actually mean, examines how the industry automates transactions today, and outlines a more ideal architecture: a wallet that reviews every transaction on the user's behalf.

What "smart" should actually mean

Wallets have been marketed as "smart" for years — smart accounts, session keys, gasless transactions. In practice, "smart" has come to mean little more than "more features." A more demanding definition is needed. A genuinely smart wallet should be three things at once, and none of them should be traded away for the others.

Secure by default. Security cannot be an advanced setting. The baseline assumption must be that any party — an app, an agent, a leaked key — may attempt to move funds, and the wallet's default posture is to verify before it signs. Automation should never require lowering that bar.

Versatile. One wallet should cover the full range of financial use cases, each with the account and controls that fit it. Long-term savings belong behind ultra-secure, multi-factor approval; everyday spending should clear automatically within sensible limits; active trading needs something in between. A smart wallet matches the right account and policy to each use case — ultra-secure for savings, auto-mode for daily spend, graduated approval for the rest — instead of forcing one global setting onto every dollar.

Intelligent. The wallet should hold full context of the user's financial activity and act as a personal financial assistant. It should understand the intent behind a transaction, recognize what is normal for this user, flag what is not, and reason about contracts and calldata the way an expert would. Context is what turns a passive vault into an active guardian.

Taken together, "smart" should describe a wallet that becomes more capable because it understands more — not one that becomes more dangerous because it asks fewer questions.

Two ways to automate a transaction today

If software is going to move money on a user's behalf, two patterns dominate. Both work, and both force a compromise.

1. Permissions (scoped session keys). Keep using the same account, but mint a key that can only do narrow, pre-declared things: call transfer, or spend no more than 10 USDC per day. ZeroDev's permission accounts and smart-contract delegation via ERC-7710 live here.

• Security: High — the key cannot do what the policy never allowed.
• Flexibility: Low — the tighter the rules, the safer it is, and the less it can do. The agent is confined to a policy written in advance, and anything that policy did not anticipate simply cannot be expressed.

2. Sub-accounts. Create a fresh, app-specific account that the app controls, and fund it with only the amount that would be acceptable to lose. Coinbase's sub-accounts and hierarchical accounts take this approach.

• Security: Low — whatever is deposited is at the app's mercy.
• Flexibility: High — inside that account the app can act instantly, with no approval loop.

The two options share a shape: either the agent is constrained in advance, or the amount it can lose is constrained. Neither lets an agent be genuinely capable and genuinely safe at the same time. The only real choice is which compromise to accept.

The wallet we have now

That compromise gets paid over and over, because every agent and every app ships its own account model, its own signer, its own onboarding.

A yield agent means onboarding into a ZeroDev account. An x402-style pay-per-call agent means a Privy wallet. An AI commerce agent arrives with a Turnkey wallet. Each one asks the user to fund it, trust it, and learn its rules. A person's financial life fragments across a dozen embedded wallets, none of which can see the others.

And as the underlying models grow dramatically more capable, the field stays stuck on the same axis: a capable app versus a secure one. The intelligence improved; the trade-off did not move.

This is where the framing breaks down. Verification has been pushed outward, into every app. Yet the most capable verifier available — software that can read a contract, decode calldata, and reason about intent better than most users ever could — could just as easily sit on the user's side of the transaction.

Why should trust be delegated to each app, when an agent on the user's side could review every transaction directly?

Smart Agent Wallet

Smart Agent Wallet has two core components: a Signer and a Guardian Agent.

Every transaction and signing request — regardless of which agent or app originated it — flows through the Guardian Agent before anything is signed. The Guardian inspects each request the way a careful smart-contract engineer would:

• decode the calldata — what function is this, with what arguments?
• read the target contract — is it what it claims to be?
• run a simulation — what does state actually look like after this executes?

It then signs in one of two modes:

• Auto mode — the request matches a pattern the user has already approved, so it proceeds without interruption.
• Approve mode — anything novel, large, or suspicious is surfaced to the user, accompanied by the Guardian's plain-language read of what the transaction does and why it was flagged.

The Signer stays deliberately simple — it can be an ordinary EOA — and signs only what the Guardian approves. Security does not come from a clever signer; it comes from a Guardian that performs real analysis on every request.

This inverts the earlier trade-off. Instead of constraining the agent in advance or capping the blast radius, the wallet reviews intent at the moment of signing — the one moment when full information about a transaction is actually available.

A wallet that is a portfolio of agents

Because verification now lives in the Guardian, the wallet can treat every third-party agent — whatever account model it uses — as a plugin. Agents become composable, and each one is granted exactly as much trust and capital as it warrants.

A realistic configuration:

• ~80% in a plain EOA as the core. A yield agent is installed against it but holds no account of its own; it can only propose moves toward higher yield, and each proposal requires explicit approval before the Guardian will sign. Maximum capital, maximum caution.
• ~15% in a session account operated by a stock agent, which buys and sells tokenized equities automatically within that budget. The session account bounds the downside while the Guardian still inspects each call.
• A small balance assigned to a card agent, able to draw up to a weekly limit — but only while spending patterns look normal. Anything anomalous escalates to approval.
• A chain-abstracted account for a commerce agent that settles purchases across chains without the user ever thinking about gas or which network the funds are on.

The result is one identity, one review layer, and many agents — each on a leash sized to the trust it has earned. Instead of a drawer of disconnected embedded wallets, the user has a single wallet with full context of their entire financial life and a Guardian that understands all of it.

Build agents, not apps

The deeper shift is about who does the work, and how often a human has to be in the loop at all.

For a decade, the unit of consumer software has been the app — an interface a person opens, learns, and operates step by step. Even when the money never leaves the user's own account and the app is just something to connect to, the human is still the one driving: reading each screen, making each decision, signing each action. The app keeps the user in the loop by design.

The agent-native model inverts this. The agent does the work, the wallet's Guardian keeps that work safe, and the human steps in only when judgment is genuinely required. Every screen a person has to navigate, every routine approval they have to give, is the system failing to handle something it could have handled on its own.

Build agents, not apps. The best app is no app at all — the agent should carry both the work and the context of the user's financial life, pulling a human in only for the decisions that truly need one.

What's next

The next post examines plugins in depth: how a third-party agent installs into the Smart Agent Wallet, how the Guardian negotiates permissions with it, and what a healthy plugin ecosystem looks like once verification finally lives on the user's side.

This is the first post in a series on the agent-native wallet. The next installment covers plugins.

Building this: Mallow Wallet

This is the wallet I'm building at Mallow Wallet — an agent-native wallet with a Guardian that reviews every transaction, so agents can act without putting your funds at risk. If it's the wallet you'd want to use, or to build agents for, take a look at mallowallet.com.