Wallets

EOAs can authorize delegated code execution from smart-contract code. This is not automatically "one and done" - the delegation can stay active until it is replaced or explicitly cleared.

How it works:

1. The wallet signs a message that says which contract code the EOA can use.
2. A special EIP-7702 transaction submits that signed message.
3. The EOA can then run that contract logic (batching, sponsorship, permissions) as if it were account logic.
4. This is not automatically "one and done" - the delegation can stay active until it is replaced or explicitly cleared.
5. If the transaction later fails, the delegation update itself can still remain.

What this enables:

• Batch 10 token approvals into one transaction
• Gas sponsorship / meta-transactions for EOA users
• Session keys with limited permissions
• Custom authorization logic
• Eliminates "approval fatigue" (approve + execute → one step)

Status (Feb 2026): Deployed on mainnet. MetaMask, Rainbow adding support. Still early for production agents — use standard EOAs or Safe until tooling matures.

Safe (Gnosis Safe) Multisig

Key Addresses (v1.4.1, deterministic across chains)

Same addresses on Mainnet, Arbitrum, Base, and all major chains.

Safe for AI Agents

Pattern: 2-of-3 Safe

• Owner 1: Agent's wallet (hot, automated)
• Owner 2: Human's hot wallet (hot, manual)
• Owner 3: Human's cold wallet (cold, recovery)
• Threshold: 2 (agent can queue transactions and human can execute or vice versa)

Benefits: If agent key is compromised, human removes it. Human can always recover funds. Agent can batch transactions.

🚨 NEVER COMMIT SECRETS TO GIT

This is the #1 way AI agents lose funds and leak credentials. Bots scrape GitHub in real-time and exploit leaked secrets within seconds — even from private repos, even if deleted immediately. A secret committed to Git is compromised forever.

This happens constantly with AI coding agents. The agent generates a deploy script, hardcodes a key, runs git add ., and the wallet is drained before the next prompt. Or the agent pastes an Alchemy API key into scaffold.config.ts and it ends up in a public repo.

This applies to ALL secrets:

• Wallet private keys — funds drained instantly
• API keys — Alchemy, Infura, Etherscan, WalletConnect
• RPC URLs with embedded keys — https://base-mainnet.g.alchemy.com/v2/YOUR_KEY
• OAuth tokens, bearer tokens, passwords

Prevention

# .gitignore (MUST exist in every project)
.env
.env.*
*.key
*.pem
broadcast/
cache/

# Verify before every commit
git diff --cached --name-only | grep -iE '\.env|key|secret|private'
# If this matches ANYTHING, stop and fix it

# Nuclear option: scan entire repo history
git log --all -p | grep -iE 'private.?key|0x[a-fA-F0-9]{64}'

If You Already Committed a Key

1. Assume it's compromised. Don't hope nobody saw it.
2. Transfer all funds immediately to a new wallet.
3. Rotate the key. Generate a new one. The old one is burned forever.
4. Clean Git history with git filter-repo or BFG Repo Cleaner — but this is damage control, not prevention. The key is already compromised.

Safe Patterns for AI Agents

# Load key from environment (NEVER hardcode)
cast send ... --private-key $DEPLOYER_PRIVATE_KEY

# Or use encrypted keystore
cast send ... --keystore ~/.foundry/keystores/deployer --password-file .password

# Or use hardware wallet
cast send ... --ledger

Rule of thumb: If grep -r "0x[a-fA-F0-9]{64}" . matches anything in your source code, you have a problem. Same for grep -r "g.alchemy.com/v2/[A-Za-z0-9]" or any RPC URL with an embedded API key.

CRITICAL Guardrails for AI Agents

Key Safety Rules

1. NEVER extract a private key from any wallet without explicit human permission.
2. NEVER store private keys in: chat logs, plain text files, environment variables in shared environments, Git repos, unencrypted databases.
3. NEVER move funds without human confirmation. Show: amount, destination (checksummed), gas cost, what it does. Wait for explicit "yes."
4. Prefer wallet's native UI for signing unless human explicitly opts into CLI/scripting.
5. Use a dedicated wallet with limited funds for agent operations. Never the human's main wallet.
6. Double-check addresses. Use viem.getAddress() or equivalent for checksum validation. A single wrong character = permanent loss.
7. Test on testnet first. Or use local Anvil fork.
8. Implement spending limits. Require human approval above threshold. Use Safe multisig for high-value operations.
9. Log all transactions (never keys). Keep audit trail.
10. Assume keys will be compromised. Design so a compromised agent key doesn't mean total loss.

Storage Options (Worst to Best)

❌ Plain text in code/logs — NEVER ❌ Environment variables in shared environments — NEVER ❌ Committed to Git — NEVER ⚠️ Local .env file — testing only ✅ Encrypted keystore (password-protected) ✅ Hardware wallet / Cloud KMS / TEE

Safe Transaction Pattern

async function sendSafely(publicClient, walletClient, to, value) {
  const checksummedTo = viem.getAddress(to);
  const { account } = walletClient;
  const gas = await publicClient.estimateGas({ account, to: checksummedTo, value });
  const fees = await publicClient.estimateFeesPerGas();
  const totalCostUSD = Number(viem.formatEther(value + gas * fees.maxFeePerGas)) * 2000;

  if (totalCostUSD > 10) {
    // human approval
  }

  const hash = await walletClient.sendTransaction({
    account,
    to: checksummedTo,
    value,
    gas: (gas * 120n) / 100n,
    maxFeePerGas: fees.maxFeePerGas,
    maxPriorityFeePerGas: fees.maxPriorityFeePerGas,
  });
  const receipt = await publicClient.waitForTransactionReceipt({ hash });
  logTransaction({ hash, to: checksummedTo, value, block: receipt.blockNumber });
  return receipt;
}

Further Reading

• Safe docs: https://docs.safe.global/
• EIP-7702 spec: https://eips.ethereum.org/EIPS/eip-7702
• ERC-4337 spec: https://eips.ethereum.org/EIPS/eip-4337