AI Agents That Hold & Spend Crypto (2025): The Wallet-Native AI Wave

Why now: wallet-native AI as a 2025 breakout

The “AI agent” idea existed for years, but it lacked the payments layer. In 2025, three ingredients matured together:
(1) ERC-4337 smart accounts for programmable spending,
(2) cheap, predictable L2 fees after EIP-4844 (blobs) and calldata compression, and (3) production paymasters/bundlers
(conceptual ERC-4337 overview).
Combine this with LLM tool-use and webhooks, and agents can complete loops: read → decide → pay → receive → iterate — all with on-chain, auditable receipts.

EOA vs Smart Account (why bots prefer smart)

EOAs (Externally Owned Accounts) are controlled by a single private key. If your bot needs to act, you either embed that key (terrible) or proxy through a custodian (centralized).
Smart accounts flip this: the account is a contract with rules. Keys are permissions you issue, rotate, scope, and revoke.
See Safe’s smart account overview for a model widely used by teams.

Net: smart accounts turn “agent risk” into policy engineering. You’ll spend time modeling spend caps, method allowlists, and time windows — because that’s what keeps funds safe.

ERC-4337 in plain English: UserOps, Bundlers, EntryPoint, Paymasters, Session Keys

ERC-4337 defines a mempool and execution flow for UserOperations (UserOp) so smart accounts can act without an EOA.
The canonical contracts + examples live in the account-abstraction (EntryPoint) repo.
For an explainer on the components and typical architecture, see the Pimlico and
QuickNode overviews.

1. UserOperation — describes the intended call from a smart account (target, calldata, gas, signature).
2. Bundler — relays UserOps to the chain’s EntryPoint contract in a single transaction.
3. EntryPoint — validates UserOps (incl. paymaster logic) and executes them against smart accounts.
4. Paymaster — a contract that decides who pays fees and how (sponsor gas or charge ERC-20s).
5. Session key — an ephemeral key with limited scope/time that the account accepts for certain calls.

// Pseudocode: constructing & sending a UserOp (TypeScript-ish)
const userOp = {
  sender: smartAccount.address,
  callData: smartAccount.encodeCall(targetContract, targetCalldata), // ABI-encoded
  callGasLimit: "0x...", verificationGasLimit: "0x...",
  maxFeePerGas: "0x...", maxPriorityFeePerGas: "0x...",
  paymasterAndData: await paymaster.sign({ sender: smartAccount.address, policy: "TIP_V1" }),
  signature: await sessionKey.sign(getUserOpHash(userOp, entryPoint, chainId)),
};
await bundler.sendUserOperation(userOp);

You don’t have to implement everything from scratch. Most teams use SDKs that wrap the raw flow with sane defaults. Evaluate providers on audits, availability SLAs, and “escape hatch” features.

Agent patterns you can ship this quarter

There’s no “one true pattern.” Choose the one that matches your value-at-risk and UX constraints.

1) Off-chain brain, on-chain hands (session-key delegate)

Your LLM/rules engine runs off-chain. It holds a session key able to call the smart account only for specific methods (e.g., tip(), swap()) with tight limits.
The contract enforces caps and time windows. Great for consumer bots and Farcaster Mini Apps
(Farcaster docs).

2) On-chain policy engine (modules/guards)

Extend the account with allowlists, rate limits, oracle checks, and pause guardians. The agent submits an “intent”; the account validates deterministically.
See module/guard concepts in Safe docs. Ideal for higher-value treasuries.

3) Fully on-chain agent (autonomous service)

A contract keeps state, holds funds, and reacts to keepers/schedulers. Decisions are rules-based on-chain (the “AI” part — models — typically stays off-chain for cost/privacy).
This is robust for subscriptions, streaming, and simple trading strategies where determinism is a win.

Three practical demos/tools (copy & adapt)

Demo #1 — Tip-Jar Agent: Mini-app triggered micro-payments (daily caps)

A Farcaster Mini App button calls your API. Your agent validates the upstream request (signature + reputation), then tips the creator in USDC on an L2.
The smart account policy restricts the agent to calling only tip(to, amount) on a known contract; budget is capped at $10/day; the session key expires in 7 days.
Sponsor gas with an ERC-20 paymaster so new users don’t need native ETH (Farcaster,
paymaster architecture).

// Sketch: minting a session key with policy (TypeScript-ish)
const sessionKey = await smartAccount.createSessionKey({
  allowedCalls: [{ to: TIP_CONTRACT, selector: selector("tip(address,uint256)"), maxValue: parseUnits("2", 6) }],
  limits: { maxCallsPerDay: 5, expiresAt: Math.floor(Date.now()/1000) + 7*24*3600 },
});
await paymaster.registerPolicy(smartAccount.address, { token: USDC, dailyBudget: parseUnits("10", 6) });

Demo #2 — Autonomous Subscriber: Monthly settle-up for API usage

Users connect an AA wallet and consume metered API calls (AI, data, compute). On the 1st of the month, your agent aggregates usage and submits a single
UserOp to settle(user): pull stablecoins from the user (via permit or prior allowance), split revenue to providers, renew next month’s credits.
Gas is sponsored only for this method and only within budget (Stackup paymasters,
Pimlico ERC-20 Paymaster).

// Solidity-ish: minimal settle logic
function settle(address user) external {
  uint256 due = usage[user].toPay;
  require(due > 0, "nothing due");
  USDC.safeTransferFrom(user, address(this), due); // use permit if possible
  distributor.split(due);                          // share with providers
  usage[user].toPay = 0;
  emit Settled(user, due, block.timestamp);
}

Demo #3 — Risk-Boxed Trader: DCA & rebalancing with circuit breakers

The agent rebalances a small basket daily. The account enforces: max notional/day, whitelisted router, TWAP/price-deviation checks, and an owner-callable pause.
Use price feeds from Chainlink and a 30-minute TWAP from
Uniswap v3’s oracle.

// Pseudocode: submit intent validated on-chain
const trade = { to: ROUTER, data: router.swapExactTokensForTokens(...), value: 0 };
await smartAccount.executeWithRules(trade, {
  maxNotionalUSD: 200,
  oracle: CHAINLINK_FEED,
  maxDeviationBps: 150,
  maxSlippageBps: 60,
  allowPairs: [USDC/WETH, USDC/USDT]
});

Security model: preventing “agent drained my wallet”

Fees & economics: who pays, how much, and when?

Agents die when fees surprise users. Production teams converge on two models:

1. Sponsor model — the app’s paymaster covers gas for allowed methods, then monetizes via subscriptions, rev-share, or spreads (reference architecture).
2. ERC-20 gas model — accounts pay fees in USDC (or similar), while the paymaster handles conversion and settlement. Cleaner for B2B invoices and accounting.

Agent design playbook (Do/Don’t + production checklist)

Do / Don’t

Tooling & SDKs (comparison snapshot)

Diagrams: ERC-4337 agent flow & policy decision tree

A) 4337 Agent Transaction (SVG)

B) Policy Decision Tree (ASCII)

         +-- allowed contract? -- Yes --> +-- allowed selector? -- Yes --> +-- spend within cap? -- Yes --> EXECUTE
         |                                 |                                 |
Session ->|                                 |                                 +-- No --> REJECT (cap exceeded)
 Key      |                                 +-- No --> REJECT (method)
         +-- No --> REJECT (contract)                                                     ^     
                                 +-- within time window? -- No --------------+-----------+ 
                                                                              |
                                                         REVOKE or require owner approval

Implementation stack: front end, backend, contracts

// Example: front-end "create session key" UX sketch (React + viem-ish)
const scope = {
  calls: [{ to: TIP_CONTRACT, selector: "0xdeadbeef", maxValue: parseUnits("2", 6) }],
  ttl: 7*24*3600, maxCallsPerDay: 5
};
const { address: smart } = useSmartAccount();
const onCreate = async () => {
  const key = await smart.createSessionKey(scope);
  setSessionKey(key);
};
// Render policy summary + revoke button

Operations & SLOs: monitoring what matters

• SLIs: UserOp inclusion latency, revert rate by cause, paymaster budget utilization, policy breaches blocked, revoke MTTR.
• Dashboards: top actions by volume/value; fails by policy; oracle deviation alarms; MEV sandwich detection; gas per action trend.
• Chaos drills: disable paymaster, rotate session key, spike gas, simulate replay, block oracle; verify graceful degradation.
• SLOs: p95 inclusion < 2 blocks (L2), p99 success > 99%, revoke MTTR < 60s, data export T+1.

Compliance & accounting: KYC, receipts, refunds

Agents aren’t “compliance-free.” For consumer flows, keep caps low and provide receipts. For enterprise, map addresses to entities, export monthly statements,
and log fiat equivalents at execution. Support refunds with an on-chain refund() under a clear policy (time windows + thresholds).

• CSV export: timestamp, tx hash, PolicyID, USD value (oracle + price source), counterparty, status.
• Use stablecoin gas to simplify accounting; reconcile against your paymaster invoices.
• Separate user funds vs agent treasury; consider Safe for custody of reserves.

What is a wallet-native AI agent?

Software that controls a smart account under strict on-chain policy, able to spend/receive crypto autonomously using session keys and paymasters — without exposing the owner key.
It’s “wallet-native” because payments are first-class, cryptographic, and revocable at the account itself.

How it works (step-by-step)

1. Create a smart account; set an owner key (or multisig/guardians).
2. Mint a session key for the agent with method allowlists, spend caps, TTL.
3. Agent composes a UserOp and signs with the session key.
4. A bundler submits to EntryPoint; the paymaster decides fee policy.
5. The account enforces policy and executes/rejects; events are emitted for audit.

Best tools & docs for builders

• Specs & repos: EIP-4337, EntryPoint repo
• Paymasters/bundlers: Pimlico, Stackup
• Session keys: Alchemy, thirdweb
• Oracles & MEV: Chainlink, Uniswap v3 oracle, Flashbots
• Front end: wagmi, viem; Passkeys WebAuthn
• Schedulers: Cloudflare Workers
• Macro: a16z State of Crypto 2025

Is it safe for agents to hold funds?

Yes, when the smart account is the policy enforcer. Treat the AI as untrusted: strip URLs, limit tool-use, validate intents on-chain.
For consumer flows, set low daily caps; for treasuries, require guardian approval and timelocks.

What about fees?

On L2s, sponsored flows reduce friction to cents per action. ERC-20 gas via paymasters simplifies accounting and removes “I need ETH” support tickets.
Your primary costs often become oracle + DEX fees, not gas.

FAQ

What is a wallet-native AI agent?

Software that controls a smart account under strict on-chain policy. It spends/receives crypto autonomously using session keys and paymasters —
the owner key remains offline. See Safe docs.

How do agents pay gas if users don’t hold ETH?

With paymasters. Apps sponsor gas or accept ERC-20 for fees; the paymaster settles under the hood.
Start with Pimlico ERC-20 Paymaster or Stackup.

Can agents trade?

Yes, but use a risk box: small notional limits, oracle/TWAP checks, slippage caps, pause switch. See Uniswap v3 oracle and
Chainlink for price references, plus MEV resources at Flashbots.

What chains are best to start?

EVM L2s with robust 4337 infra, stable fees, and liquid stablecoins. You want low inclusion latency and strong oracle coverage. Align closely with the ERC-4337 spec.

What about passkeys and login?

Pair AA wallets with WebAuthn passkeys for passwordless UX (WebAuthn, passkeys.io).
Users authenticate with device biometrics while the smart account enforces policy on-chain.

Further reading & references (official docs & reputable guides)

• Specs & repos: EIP-4337 • EntryPoint repo
• Concepts (AA): Pimlico ERC-4337 overview • QuickNode guide
• Paymasters & bundlers: Pimlico ERC-20 Paymaster • Stackup paymasters
• Session keys: Alchemy • thirdweb
• Oracles & MEV: Chainlink price feeds • Uniswap v3 oracle • Flashbots • MEV Blocker
• Front-end tooling: wagmi • viem
• Farcaster Mini Apps: Official docs
• Passkeys/WebAuthn: W3C WebAuthn • passkeys.io
• Macro: a16z State of Crypto 2025 • interactive dashboard