solidity-account
Generate ERC-4337 compliant smart contract accounts with customizable signature validation, token reception, and upgradeability options for Ethereum applications.
Instructions
Make an account contract that follows the ERC-4337 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the account contract | |
| signatureValidation | No | Whether to implement the ERC-1271 standard for validating signatures. This is useful for the account to verify signatures. | |
| ERC721Holder | No | Whether to implement the `onERC721Received` function to allow the account to receive ERC721 tokens. | |
| ERC1155Holder | No | Whether to implement the `onERC1155Received` function to allow the account to receive ERC1155 tokens. | |
| signer | No | Defines the signature verification algorithm used by the account to verify user operations. Options: - ECDSA: Standard Ethereum signature validation using secp256k1, validates signatures against a specified owner address - EIP7702: Special ECDSA validation using account's own address as signer, enables EOAs to delegate execution rights - Multisig: ERC-7913 multisignature requiring minimum number of signatures from authorized signers - MultisigWeighted: ERC-7913 weighted multisignature where signers have different voting weights - P256: NIST P-256 curve (secp256r1) validation for integration with Passkeys and HSMs - RSA: RSA PKCS#1 v1.5 signature validation (RFC8017) for PKI systems and HSMs - WebAuthn: Web Authentication (WebAuthn) assertion validation for integration with Passkeys and HSMs on top of P256 | |
| batchedExecution | No | Whether to implement a minimal batching interface for the account to allow multiple operations to be executed in a single transaction following the ERC-7821 standard. | |
| ERC7579Modules | No | Whether to implement the ERC-7579 compatibility to enable functionality on the account with modules. | |
| info | No | Metadata about the contract and author | |
| upgradeable | No | Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades. |
Implementation Reference
- Executes the tool logic: constructs AccountOptions from inputs and generates formatted Solidity account contract code using OpenZeppelin's wizard library.
async ({ name, signatureValidation, ERC721Holder, ERC1155Holder, signer, batchedExecution, ERC7579Modules, info, upgradeable, }) => { const opts: AccountOptions = { name, signatureValidation, ERC721Holder, ERC1155Holder, signer, batchedExecution, ERC7579Modules, info, upgradeable, }; return { content: [ { type: 'text', text: safePrintSolidityCodeBlock(() => account.print(opts)), }, ], }; }, - Zod input schema for validating tool parameters like name, signer type, modules, etc.
export const accountSchema = { name: z.string().describe('The name of the account contract'), signatureValidation: z .literal(false) .or(z.literal('ERC1271')) .or(z.literal('ERC7739')) .optional() .describe(solidityAccountDescriptions.signatureValidation), ERC721Holder: z.boolean().optional().describe(solidityAccountDescriptions.ERC721Holder), ERC1155Holder: z.boolean().optional().describe(solidityAccountDescriptions.ERC1155Holder), signer: z .literal(false) .or(z.literal('ECDSA')) .or(z.literal('EIP7702')) .or(z.literal('Multisig')) .or(z.literal('MultisigWeighted')) .or(z.literal('P256')) .or(z.literal('RSA')) .or(z.literal('WebAuthn')) .optional() .describe(solidityAccountDescriptions.signer), batchedExecution: z.boolean().optional().describe(solidityAccountDescriptions.batchedExecution), ERC7579Modules: z .literal(false) .or(z.literal('AccountERC7579')) .or(z.literal('AccountERC7579Hooked')) .optional() .describe(solidityAccountDescriptions.ERC7579Modules), info: commonSchema.info, upgradeable: commonSchema.upgradeable, } as const satisfies z.ZodRawShape; - packages/mcp/src/solidity/tools/account.ts:8-45 (registration)Registers the 'solidity-account' tool on the MCP server with name, prompt, schema, and handler function.
export function registerSolidityAccount(server: McpServer): RegisteredTool { return server.tool( 'solidity-account', makeDetailedPrompt(solidityPrompts.Account), accountSchema, async ({ name, signatureValidation, ERC721Holder, ERC1155Holder, signer, batchedExecution, ERC7579Modules, info, upgradeable, }) => { const opts: AccountOptions = { name, signatureValidation, ERC721Holder, ERC1155Holder, signer, batchedExecution, ERC7579Modules, info, upgradeable, }; return { content: [ { type: 'text', text: safePrintSolidityCodeBlock(() => account.print(opts)), }, ], }; }, ); } - packages/mcp/src/solidity/tools.ts:17-28 (registration)Central registry mapping that includes the registerSolidityAccount function for the 'Account' kind, used by registerSolidityTools.
function getRegisterFunctions(server: McpServer): SolidityToolRegisterFunctions { return { ERC20: () => registerSolidityERC20(server), ERC721: () => registerSolidityERC721(server), ERC1155: () => registerSolidityERC1155(server), Stablecoin: () => registerSolidityStablecoin(server), RealWorldAsset: () => registerSolidityRWA(server), Account: () => registerSolidityAccount(server), Governor: () => registerSolidityGovernor(server), Custom: () => registerSolidityCustom(server), }; } - packages/mcp/src/server.ts:25-25 (registration)Top-level call to register all Solidity tools, including 'solidity-account', in the MCP server creation.
registerSolidityTools(server);