aa
Skill7 starsChanged 53 days agoMITView on GitHub
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.
- Reads credentials
Files
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 enablechaingpt_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.Signed user-operation submission
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 signed operations.
chaingpt_aa_submit_useropis shipped; the account owner signs externally. - 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'spm_sponsorUserOperationor 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 (5 foundation tools).mcp-server/src/__tests__/aa.test.ts— 30 cases including the custody-free invariant test.
In this repository23 other files it gives its agents.
- agent-walletSkill
- baseSkill
- bridgeSkill
- chaingptSkill
- dashboardSkill
- debugSkill
- defiSkill
- deploySkill
- driftSkill
- hackathonSkill
- hyperliquidSkill
- playgroundSkill
- polymarketSkill
- researchSkill
- scheduled-autonomySkill
- securitySkill
- solanaSkill
- strategySkill
- tradeSkill
- tronSkill
- trustless-agentsSkill
- updateSkill
- x402Skill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

