aa

ERC-4337 (Account Abstraction) skill

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

Tool	Purpose
chaingpt_aa_userop_hash	Compute the v0.7 userOpHash the signer signs.
chaingpt_aa_pack_userop	Pack a UserOp into the EntryPoint wire-format PackedUserOperation + emit the bundler-RPC JSON shape.
chaingpt_aa_estimate_userop	Proxy eth_estimateUserOperationGas to an admin-supplied bundler URL.
chaingpt_aa_userop_receipt	Proxy eth_getUserOperationReceipt to check if a userop was bundled and what the on-chain receipt looks like.

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:

Provider	Validator	Session-key issuance
Safe + Zodiac	safe-protocol-kit modules	enableModule + setSessionKey
Kernel (ZeroDev)	EIP-7579 modular validators	installValidator
Biconomy	K1Validator + sponsorship	issueSessionKey
Alchemy Smart Wallet	Modular Account v2	installPlugin
SimpleAccount (canonical reference)	single owner — no session keys natively	(none — add a session-key validator)

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

Provider	Pattern
Pimlico	https://api.pimlico.io/v2/<chain>/rpc?apikey=YOUR_KEY
Alchemy AA	https://<chain>.bundler.alchemy.com/<API_KEY>
Stackup	https://api.stackup.sh/v1/node/<API_KEY>
Particle	https://bundler.particle.network/?chainId=<id> (with auth header)

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

EntryPoint addresses

Version	Address (deterministic across chains)
v0.7	0x0000000071727De22E5E9d8BAf0edAc6f37da032 (this foundation targets v0.7)
v0.6	0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 (read-only inspection only)

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.