version: "1.0.0" name: aa description: ERC-4337 v0.7 account-abstraction foundation. Custody-free utilities for computing userOpHashes, packing UserOperations into the EntryPoint wire format, and proxying bundler-RPC calls (Pimlico / Alchemy / Stackup). Triggers: ERC-4337, account abstraction, smart contract wallet, userop, user operation, bundler, paymaster, session key, EntryPoint, AA wallet, smart wallet, gas sponsorship.

ERC-4337 (Account Abstraction) skill

This skill exposes the shared primitives every ERC-4337 v0.7 smart-contract wallet needs:

Custody-free invariant

The plugin never signs a UserOp and never sees a smart-account owner key or session key. The hash returned by chaingpt_aa_userop_hash is the input to the user's wallet (MetaMask, hardware wallet, viem signer, SCW session-key module). The user signs externally and places the signature into the UserOp's signature field before submitting via the bundler.

A unit test asserts the surface contract: no tool input schema may contain a parameter that matches `/privatekey|ownerkey|sessionkey|mnemonic|seedphrase|signer/`. Future additions that try to accept a secret will fail the build.

Foundation vs. session-key flow

ERC-4337 session keys live inside the smart-contract wallet's validator module. Every major SCW provider has its own validator with its own session-key ABI:

Picking one provider here would lock the plugin into that vendor's surface. Instead, this skill ships the shared primitives (packing, hashing, bundler-rpc) that every v0.7 SCW needs, and per-provider session-key issuance / use is queued as follow-up PRs:

• chaingpt_aa_session_ (SHIPPED v1.21 — vendor-neutral Smart Sessions supersedes the per-vendor safe/kernel plan; Kernel/Safe7579 agent-side signing still queued) chaingpt_aa_safe_* — Safe enable-module + session-key enable
• chaingpt_aa_kernel_* — Kernel install-validator + session-key install
• (etc., one PR per provider)

Each follow-up will use chaingpt_aa_userop_hash + chaingpt_aa_estimate_userop from this foundation unchanged.

How a typical signed-userop flow uses these tools

1. Application code builds an unsigned UserOp:
     sender, nonce, callData, gas limits, gas fees, optional paymaster.
 
2. Estimate gas via the bundler (admin supplies the URL):
     chaingpt_aa_estimate_userop({ bundlerUrl, userOp, entryPoint? })
   → returns callGasLimit / verificationGasLimit / preVerificationGas.
   Fold those back into the UserOp.
 
3. Compute the hash to sign:
     chaingpt_aa_userop_hash({ userOp, chain, entryPoint? })
   → returns the 0x-prefixed userOpHash.
 
4. Sign the hash externally (this is the only step the plugin does NOT do):
     - SimpleAccount, Safe (default), Kernel default: ECDSA over personal_sign of the hash.
     - Some SCWs: EIP-712 typed-data signature (see your SCW's docs).
 
5. Set userOp.signature = the 65-byte ECDSA signature (or session-key-validator-specific encoding).
 
6. Submit via the bundler (you call this yourself, the plugin does not currently proxy eth_sendUserOperation):
     POST { method: 'eth_sendUserOperation', params: [userOp, entryPoint] }
   → returns userOpHash.
 
7. Poll inclusion:
     chaingpt_aa_userop_receipt({ bundlerUrl, userOpHash })
   → null until bundled, then the full receipt with tx hash + status.

Why we don't ship eth_sendUserOperation (yet)

Submitting a signed userop is the irreversible step. We deliberately leave it to the user's existing bundler-client code path so the plugin doesn't become the broadcast vector. The hash and the estimate are read-only. The receipt is read-only. The signed-submission stays in user code where it's already audited.

Bundler URL conventions

Pass the full URL to bundlerUrl. The plugin does not store it.

EntryPoint addresses

What this skill does NOT do (yet)

• Sign anything. The plugin returns the hash; you sign elsewhere.
• Submit `eth_sendUserOperation`. Done in user code with the signed UserOp.
• Per-provider session-key issuance. Safe / Kernel / Biconomy / Alchemy Smart Wallet are follow-up PRs that build on this foundation.
• Paymaster sponsorship issuance. The paymaster* fields are accepted as inputs; sponsoring a paymaster (calling Pimlico's pm_sponsorUserOperation or equivalent) is a follow-up.
• EIP-7702 (delegated EOAs). Different scheme; out of scope for v0.7.

Reference

• mcp-server/src/lib/erc4337.ts — primitives (uses viem v2.20+ audited AA module).
• mcp-server/src/tools/aa.ts — tool surface (4 tools).
• mcp-server/src/__tests__/aa.test.ts — 30 cases including the custody-free invariant test.