Agent Wallet

What is the fundamental difference between an Agent Wallet and a regular EOA wallet? Why can't you just give the Agent your MetaMask private key?

On the surface both are 'an Ethereum address with a private key,' but the design logic is completely different.

Regular EOA wallet (MetaMask, hardware wallet) design assumption: a human reviews every transaction before signing — 'Is this transfer correct? Right amount? Right address?' The human is the last safety gate. Therefore EOA wallets have no built-in programmatic operation limits; the private key can authorize any amount, any address, any operation.

Agent Wallet design assumption: no human confirms each operation — the Agent executes fully autonomously. Therefore safety boundaries must be built into the code layer, not relying on human confirmation: spending limits hardcoded (operations over $100 must pause for human confirmation), destination address whitelist (Agent can only interact with whitelisted contracts), daily cumulative cap (preventing long-running Agents from accumulating large operations without human oversight).

Why you can't give the Agent a MetaMask private key: once the private key is held by the Agent, if the Agent's LLM reasoning is compromised by Prompt Injection, an attacker can have the Agent authorize any amount to any address — with no programmatic guardrail to stop it. This is equivalent to giving a credit card with no spending limit to a robot that might be hacker-controlled.

Correct approach: use a dedicated Agent Wallet with all operational boundaries enforced at the code layer, isolated from your main funds, containing only 'a few days of operating capital.'

What are the four mainstream Agent Wallet architectures, and which scenarios suit each?

Architecture 1: EOA + Code Guardrails (simplest) Use a regular EOA address, store the private key in backend (AWS Secrets Manager, encrypted environment variables), implement all safety boundaries in code (amount validation, whitelist, daily caps). Lowest cost, fastest deployment. Suitable for early-stage Agents and low-fund scenarios. Downside: private key concentrated in one place — if the backend is compromised, the key is exposed.

Architecture 2: MPC Wallet (Multi-Party Computation) Private key split into multiple 'shards' distributed across locations (e.g., 2-of-3: Agent holds one shard, your phone holds one, service provider holds one). Signing requires shard cooperation; any single shard leak cannot complete a signature. Privy and Turnkey offer commercial MPC wallet services. Suitable for medium-to-high fund Agents; solves private key concentration but introduces service provider dependency.

Architecture 3: Smart Contract Wallet (Safe / ERC-4337) Use smart contracts to implement multi-sig or conditional authorization logic. Agent operation requests are submitted to the contract, which executes according to preset rules (multi-sig required to exceed limits, only whitelisted contract interactions allowed). Highest security, rules transparent and on-chain auditable, but higher Gas fees and more complex deployment. Suitable for high-fund, institutional-grade Agents needing on-chain auditability.

Architecture 4: Coinbase AgentKit Custodial Wallet Coinbase MPC infrastructure custodies the private key; SDK provides standardized Agent wallet functions. Deepest Base chain integration; Paymaster lets Agents pay Gas in USDC without holding ETH. Suitable for rapid prototyping and Base chain strategies, but funds are Coinbase-custodied (counterparty risk).

How do you solve the Gas fee problem for Agent Wallets? What design patterns exist for Agents paying their own Gas?

Gas fees are the most easily overlooked but most UX-impacting problem for Onchain Agents. Poorly designed Agent Wallets require holding ETH/SOL on multiple chains for Gas, manual Gas replenishment, and make Gas consumption hard to predict. Four mainstream design solutions:

1. ETH Reserve (most basic): Agent Wallet holds a quantity of ETH (or the target chain's native token) as Gas reserve. Set low-watermark alerts (notify to top up below 0.01 ETH). Simple, but cross-chain deployments require maintaining Gas reserves on every chain — management cost scales linearly with number of chains deployed.

2. Paymaster (ERC-4337 Account Abstraction): Smart contract wallets (ERC-4337 pattern) support the Paymaster mechanism — a third-party Paymaster contract pays Gas on behalf of the Agent; the Agent only holds USDC, Gas fees are deducted in USDC (Paymaster backend-converts to ETH for miners). Coinbase Base and zkSync support Paymaster. This keeps Agent financials clean: only USDC needed, no Gas token management.

3. Relayer Service (gasless mode): Agent generates unsigned transactions, submits to a Relayer (e.g., OpenZeppelin Defender); Relayer pays Gas and broadcasts, deducting costs from Agent's USDC balance. Suitable for chains without ERC-4337 support (e.g., Solana via Jito).

4. Sponsorship (scenario-specific): Some DeFi protocols (e.g., Aave's GasZip) absorb Gas fees for user interactions with the protocol. Agent operations on these protocols can be zero-Gas, but limited to operations the specific protocol supports.

Practical recommendation: Base chain deployments should prioritize Paymaster (AgentKit has built-in support); multi-chain deployments use Relayer services for unified management; choose ETH reserve mode only for Ethereum mainnet with no desire for third-party dependency.

What if the Agent Wallet private key is leaked? What is the emergency response process?

A leaked Agent Wallet private key has more severe consequences than a regular wallet — the Agent may run 24/7, an attacker can immediately exploit the key, and you may have no real-time human monitoring in place. Complete emergency response process:

Step 1 (0-5 min): Immediately stop the Agent service process. Regardless of the reason for suspecting a leak, stop first — stopping the Agent service cannot reverse already-broadcast transactions, but prevents the Agent from broadcasting new ones. Use kill or stop the Railway/Cloud Run service instance.

Step 2 (5-10 min): Revoke all ERC-20 approvals. Even with the service stopped, if the Agent Wallet address has approve authorizations on any token contracts, attackers can still directly call the contract to transfer tokens. Use your main wallet to call approve(agentAddress, 0) on all previously authorized token contracts. Use revoke.cash to quickly query and batch-revoke.

Step 3 (10-30 min): Transfer remaining funds from the Agent Wallet to a new address. After stopping the service and revoking approvals, immediately transfer remaining funds in the Agent Wallet to a brand new, never-used address (not your main wallet — if the attacker is monitoring your transfer behavior, your main wallet may already be flagged).

Step 4 (30-60 min): Root cause analysis. Find 'how the private key leaked' in logs — was the backend compromised (code repository, environment variables), or did Prompt Injection cause the Agent to output the private key to an insecure location (an extremely rare but real attack scenario)? Root cause determines the remediation plan.

Step 5: Deploy with a new Agent Wallet. Do not reuse the original address — even after funds are transferred, the old address's operation history may let attackers infer your strategy logic.